AgentCore Gateway semantic search returns MCP tools, but discovered tools are not callable

Summary

Codex can call an Amazon Bedrock AgentCore Gateway's semantic-search tool and receive valid MCP tool definitions, but those discovered tools are not added to the current session's callable tool surface.

The search response includes the target tool name, description, and input schema. Attempting to call the returned name from the same Codex session fails because no callable function was registered. A direct call through the app-server mcpServer/tool/call method succeeds, proving that the gateway connection, OAuth session, target tool, and arguments are valid.

Environment

• Codex CLI: 0.152.0
• Platform: macOS 26.6.1, arm64
• Model: gpt-5.6-sol
• MCP transport: Streamable HTTP
• MCP gateway: Amazon Bedrock AgentCore Gateway with semantic search enabled
• MCP protocol header: 2025-11-25
• Authentication: OAuth

Reproduction

1. Configure an AgentCore Gateway with semantic search enabled as a remote MCP server.

2. Start a fresh Codex session.

3. Ask Codex to invoke a gateway target tool that is not included in the initial model-facing tool list.

4. Codex calls the gateway's x_amz_bedrock_agentcore_search tool with an exact query.

5. Observe that the result contains a valid tool definition, for example:

   {
     "tools": [
       {
         "name": "example-target___invoke",
         "description": "Invoke an example target operation.",
         "inputSchema": {
           "type": "object",
           "properties": {
             "input": { "type": "string" }
           },
           "required": ["input"]
         }
       }
     ]
   }
   

6. Attempt to invoke example-target___invoke from the same session.

Actual behavior

The discovered tool is not registered in the in-session callable-tool namespace. In code mode, both the raw name and expected namespaced variants resolve to undefined, and attempting to invoke it produces a not a function failure.

The same behavior reproduces in separate fresh sessions.

Control test

Using Codex's local app-server with the same existing MCP configuration and OAuth credentials:

1. Initialize the app-server.

2. Create an ephemeral thread with thread/start.

3. Call:

   {
     "method": "mcpServer/tool/call",
     "params": {
       "server": "example-agentcore-gateway",
       "threadId": "<ephemeral-thread-id>",
       "tool": "example-target___invoke",
       "arguments": { "input": "test" }
     }
   }
   

The call succeeds and returns the target tool's response.

This isolates the failure to the model-facing discovery/binding layer rather than the gateway, target, authentication, or MCP transport.

Expected behavior

After x_amz_bedrock_agentcore_search returns valid tool definitions, Codex should provide a supported way to invoke those discovered tools in the current task. Possible designs include:

1. dynamically registering the returned definitions in the current tool surface; or
2. exposing a validated generic MCP call broker that accepts the server, discovered raw tool name, and arguments.

The second option may be more vendor-neutral and avoids permanently mutating the server's cached tools/list catalog.

Why this is distinct from related reports

• #19425 concerns tools returned by the initial MCP tools/list not being exposed.
• #21503 concerns ranking misses for tools already present in Codex's deferred-tool index.
• #37417 concerns ignoring the standard notifications/tools/list_changed refresh signal.

Here, the gateway's callable search tool works and returns schemas inline, but Codex has no path from those returned schemas to a subsequent MCP tool call. No tools/list_changed notification is involved.

Documentation

AWS documents x_amz_bedrock_agentcore_search as the semantic discovery mechanism for AgentCore Gateway and states that its response returns tools relevant to the query:

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-mcp-semantic-search.html

Suggested implementation direction

Treat tool definitions returned from a recognized MCP discovery result as scoped, untrusted discovery data. Validate the selected name and arguments against the returned schema, preserve normal MCP approval policy, and route the call through the existing MCP connection manager/app-server tool-call path.

A regression test should cover: search returns a tool schema, the model selects it, Codex routes the raw tool name through the originating MCP server, and approval rules still apply.

▎ Additional context: the reason the discovered tool isn't in the callable surface is that the session registers only the first tools/list page — in the legacy protocol mode the nextCursor returned by the server is not followed (the 2026-07-28 mode would paginate, but its server/discover negotiation doesn't complete against this class of server). So any paginating MCP server exposes only its first page of tools to codex today. Either following cursors in legacy mode or making discovered tools invocable (this issue's proposal) resolves it; the latter is preferable for large catalogs since registering hundreds of schemas is expensive in context.

Start with the existing MCP connection manager and app-server mcpServer/tool/call path, then trace how semantic-search results are handled and how callable tools are registered. Add a regression test covering a returned tool schema, routing through the originating server, and approval enforcement; done means the discovered tool can be invoked in the current session without changing unrelated MCP behavior.