Tracking missing capabilities
Contents
One of the most valuable signals an MCP server owner can get is: the agent wanted to do something I don't currently support. Without that signal, gaps in your tool surface are invisible — the agent either gives up silently or hallucinates a tool name.
reportMissing is the SDK's hook for capturing those gaps.
Enabling
With this on, the SDK registers a virtual tool called get_more_tools on your server. The tool is advertised to the agent through tools/list like any other tool, with a description that tells the agent to call it whenever the user's request can't be satisfied by the available tools.
What gets captured
When the agent invokes get_more_tools, the SDK:
- Emits its own dedicated
$mcp_missing_capabilityevent — not a$mcp_tool_call. - Stamps
$mcp_intentwith the agent's reasoning describing what the user was trying to do. - Returns a benign response to the agent so it can continue its turn.
That gives you a queryable feed of unmet asks per server:
Complementary signal: advertised but uncalled
reportMissing tells you what's missing. The $mcp_tools_list event tells you what's advertised but ignored — tools the agent saw but never invoked.
Together, the two queries answer "what tools should I build?" and "what tools should I cut?".
{/ TODO: ProductScreenshot of an insight showing the top unmet asks from get_more_tools, grouped by client /}
Caveats
get_more_tools is just another tool from the agent's perspective. Well-behaved agents that read tool descriptions will use it; clients that ignore the tool list won't. The signal is opt-in on the agent side as much as on yours.
get_more_tools emits a dedicated $mcp_missing_capability event rather than a $mcp_tool_call, so it never pollutes your tool-call volume, error-rate, or intent-source queries. Query it directly via event = '$mcp_missing_capability'.
The point is to feed a roadmap, not to collect data for its own sake. If you're not planning to triage unmet asks, leave it off.