Realtime Agent Using `function_call` Instead of `mcp_call` for Hosted MCP Tools

[mpbacklund]

Describe the bug

When using a hosted MCP server, realtime agents will occasionally attempt to perform a function_call instead of an mcp_call when invoking a tool from that server.

For example, I have a hosted MCP tool called metrics_get_data. When I try to invoke it, the following error occurs:

Error handling function call $t: Tool metrics_get_data not found

Inspecting the agent’s history shows that the tool was called as a function_call:

{
  "arguments": "{\"metricID\":\"iz270IOmPBgHJLwjKPdtX\"}",
  "itemId": "item_CRIzUATkoCK37YdpjH6b4",
  "name": "metrics_get_data",
  "output": null,
  "status": "in_progress",
  "type": "function_call"
}

However, metrics_get_data exists in the MCP tools list, not in the function tools list - yet the agent treats it as a function call.

Tool Lists (Sanitized)

MCP Tools

[
  { "name": "metrics_list" },
  { "name": "get_current_user" },
  { "name": "metrics_get_data" },
  { "name": "documentation_search" },
  ...
]

Function Tools

[
  { "type": "function", "name": "browserCreateHyperlink" },
  { "type": "function", "name": "browserNavigateToPage" },
  ...
]

Even though metrics_get_data clearly belongs in the MCP tool list, the agent’s request type is incorrectly set to function_call.

Debug Information

• Agents SDK version: 0.1.9
• Runtime environment: Node.js 18.17.1

Steps to Reproduce

1. Set up a hosted MCP server with several tools.
2. Provide that server to a realtime agent as shown below:

const agent = new RealtimeAgent({
  name: 'Cora AI Assistant',
  instructions: `You are an AI assistant. You have MCP tools and function tools available to you. Your available MCP tools are get_orders, create_order, ...`,
  tools: [
    hostedMcpTool({
      serverLabel: 'mcp',
      serverUrl: environment.mcpURL,
      requireApproval: 'never'
    }),
    // additional function tools here
  ],
});

3. Optionally, include a list of the available MCP tools in the system prompt.
4. Attempt to invoke an MCP tool (e.g., metrics_get_data).

In my testing, this error occurs roughly 50% of the time when MCP tools are listed in the system prompt. If tools are not listed in the system prompt the error does not happen as often, but still often enough to render our agent unreliable at best.

Expected Behavior

The realtime agent should correctly recognize and invoke tools based on their type:

MCP tools → mcp_call

Function tools → function_call

metrics_get_data should trigger an mcp_call, not a function_call.****

[seratch]

Thanks for sharing this feedback. I've shared the realtime api team as well. I'll update you when I get anything to share.

[IM594]

+1

[seratch]

Quick update on this: it seems this is a model side issue but we don't have anything to share on whether / when this can be improved.

[sebitokazu]

Hi, is there any update on this or has anyone found a workaround?

[tvanier]

Hi, I faced the same problem, splitting tools over multiple MCP servers seems to work better for me.
I modified my MCP server to register tools conditionally, something like

tools: [
  hostedMcpTool({ serverLabel: 'mcp-a',   serverUrl: 'https://example.com/mcp?toolsets=a' }),
  hostedMcpTool({ serverLabel: 'mcp-b-c', serverUrl: 'https://example.com/mcp?toolsets=b,c' }),
]

[shahsmitcs]

we are facing this as well, really would be helpful if there is a workaround

[mpbacklund]

we are facing this as well, really would be helpful if there is a workaround

I would take a look at this repository, which demonstrates a chat-supervisor pattern and sequential handoffs between multiple, specialized Realtime agents. The chat-supervisor pattern comes with a time tradeoff, but you also get a lot of advantages such as using models with larger context windows. Both of these patterns should successfully help you work around the problem, although it isn't ideal.

[shahsmitcs]

thanks! although there is a pretty significant latency penalty with the handoff pattern and we would like to avoid it if possible. In our usage, we see that the tool use is actually decently good for the realtime model except for this sporadic hallucination and function_call usage. I was hoping for some workaround such that we can continue using the realtime model and avoid it (e.g. listening for the function_call and then maybe manually forcing a response via response.create after inserting the tool args into the conversation, trying to see if someone has successfully implemented some scheme like this).

[fastfret888]

does anyone know if gpt-realtime 1.5 solved this?

[fastfret888]

This is indeed a model-side issue, but it can be solved by including this in your system prompt:

Tool Routing Rules

• You have access to two tool execution paths:
  1. Local function tools
  2. Hosted MCP tools
• Any tool whose name starts with mcp is a hosted MCP tool and must always be invoked through the MCP tool path, never the local function-tool path.
• Never treat an mcp* tool as a local function.
• Never simulate, rewrite, or approximate an mcp* tool call as a normal function call.
• If the correct tool for the task is an mcp* tool, call that MCP tool directly.

[wsk-builds]

I took another pass against current upstream/main and the existing thread. I may be missing some context from the API side, but I think a small raw-event trace would help narrow this down without guessing.

What I observed:

• The Realtime SDK appears to keep function_call and MCP item types on separate paths: function_call items are emitted as function calls, while mcp_call / mcp_tool_call items go through the MCP-specific handling.
• The thread already suggests this may be model/server-side behavior, but the raw Realtime events would make that boundary much clearer.

Would it be possible to share a minimal trace with:

• SDK version.
• Realtime model name.
• Transport: WebRTC, WebSocket, SIP, or Twilio.
• Hosted MCP tool config, including server label/url, approvals, and any allowed tool filters.
• The final session tools config that includes both hosted MCP tools and any local function tools.
• Raw response.output_item.* events for the bad tool call.
• Any raw MCP-specific events, if present.
• The final SDK-emitted event/history item showing function_call vs mcp_call.
• Whether this only happens for hosted MCP tools, and whether ordinary function tools continue to work correctly in the same session.

My read, based on the current SDK code:

• If the raw Realtime event itself is a function_call, the SDK may simply be forwarding the model/server output faithfully. In that case the fix likely belongs server/model-side, or as a workaround in tool naming, prompt routing, or hosted MCP server partitioning.
• If the raw Realtime event is actually mcp_call / mcp_tool_call but the SDK emits it as a function_call, then this would look much more like an SDK mapping bug.

Suggested next step:

• Add one failing raw event trace and, if available, one successful hosted MCP trace from the same session config. That should make it easier to classify this as SDK mapping vs server/model behavior.