Visibility is a route, not an authorization boundary
Use when: one MCP server should stay available, but a surface is inappropriate—for example, a long-running call should not be driven through Code Mode, or a large catalog should be deferred behind tool search. Also use this before claiming that hiding a tool removes its capability.
[mcp_servers.long_runner],
keep
the
existing
command
or
URL
and
add
omit_tools_from = ["code_mode"].
The
accepted
values
are
direct,
deferred,
and
code_mode;
combine
them
per
server.
Treat
this
as
exposure
routing
only.
If
dangerous_write
must
be
unavailable,
also
put
it
in
disabled_tools = ["dangerous_write"],
narrow
enabled_tools,
or
disable
the
server.
Start
a
clean
session
after
the
config
change
and
preserve
a
raw
request
or
harness
trace.
Acceptance
check:
expose
two
uniquely
named
canaries,
canary_read
and
dangerous_write.
With
only
code_mode
omitted,
pass
only
if
canary_read
is
absent
from
Code
Mode’s
exec
description
and
ALL_TOOLS,
remains
visible
through
the
permitted
direct
namespace
or
tool_search,
and
reaches
the
MCP
server
once.
Then
disable
dangerous_write;
pass
only
if
it
is
absent
from
direct,
deferred,
and
Code
Mode
catalogs
and
an
exact
attempted
call
does
not
reach
the
server.
Record
catalog
snapshots
and
server
call
counts
before
and
after.
Any
hidden-but-dispatchable
write
fails
the
authorization
gate.
_meta
from
Code
Mode
results,
and
adds
981
lines
across
41
files.
Tests
cover
every
surface
combination,
prefixed
and
unprefixed
names,
nested
and
direct
dispatch,
parallel
calls,
config
round-trips,
and
metadata
filtering.
The
commit
and
tests
are
primary
and
inspectable.
Caveat:
this
is
prerelease
Codex
behavior,
not
MCP
protocol
semantics,
and
omit_tools_from
is
server-wide
rather
than
per-tool.
The
implementation
deliberately
keeps
omitted
tools
registered
for
permitted
or
compatibility
paths,
so
catalog
absence
does
not
prove
denial.
Re-run
the
canaries
after
each
upgrade;
use
sandbox,
approval
policy,
and
server-side
authorization
as
independent
boundaries.