Repository navigation
Support overriding built-in tools #411
Description
I'm working on a feature using the SDK where I would like to register my own tools and handle their execution externally (e.g. forwarding tool calls to another piece of software and returning the results back).
While digging into the SDK, I noticed that the SessionOptions in the SDK already has externalToolDefinitions and externalToolDispatcher fields that seem to do exactly this, where they get merged into the tools array alongside the built-in CLI and MCP tools and the dispatcher callback is called when the model invokes them.
Would it be possible to surface these two fields on the public SessionConfig? It would just be passing them through to the internal session, so no new logic is required since the all the plumbing is already there.
interface SessionConfig {
// ... existing fields ...
externalToolDefinitions?: ExternalToolDefinition[];
externalToolDispatcher?: ExternalToolDispatcher;
}
Activity
github-actions commentedon Feb 9, 2026
Thanks for opening this issue! 👋
I've labeled this as an
enhancementfor thesdk/nodejs. This looks like a reasonable feature request to expose the existing internal fields for external tool handling on the publicSessionConfiginterface.The team will review your proposal and determine if this can be added to the public API surface.
patniko commentedon Feb 9, 2026
Hi @theblixguy - What's not sufficient about the existing tool registration capabilities within the SDK?
theblixguy commentedon Feb 10, 2026
@patniko Let's say I have an app called A that sends a prompt to the agent and it includes some tools that A can run (A doesn't expose an MCP, but it knows how to run them). I've noticed that Copilot will attempt to map them to its own built-in tools or just ignore them, whereas I'd like it to preserve them so I can pass the information back to A about what tools to run or try to run them myself. I looked at
SessionConfig.toolsbut in my case some of the tool names overlap with the CLI's built-in tools (things likeBash,Read,Editand let's say I can't control these names), so they collide and the CLI handles them itself instead of letting me dispatch them externally.SteveSandersonMS commentedon Feb 12, 2026
Thanks. It seems like what you need is to be able to override tools by name. If that's the case we can add support for that.
[-]Make `externalToolDefinitions` and `externalToolDispatcher` available on `SessionConfig`[/-][+]Support overriding built-in tools[/+]feat: auto-exclude built-in tools overridden by user-registered tools
feat: Support overriding built-in tools (Issue #411)
feat: Support overriding built-in tools (Issue #411)
bigunyak commentedon Mar 4, 2026
Is this new feature the reason why my Atlassian MCP overrode the built-in
fetchtool? So, every time I try to fetch a random web page, Copilot is now trying to fetch it through Atlassianfetchand fails with this error:patniko commentedon Mar 4, 2026
Shouldn't be unless you specified when you created a session that you want to let it override built-ins, @bigunyak. Will reopen while I confirm we have additional test coverage here. The intent is that built-in overrides only happen with declared tools rather than MCP tools since it conflicts with this scenario too much. cc: @SteveSandersonMS
bigunyak commentedon Mar 4, 2026
I didn't specify anything explicitly.
The only thing I did is added Atlassian MCP server with the following configuration.
{ "servers": { "atlassian": { "url": "https://mcp.atlassian.com/v1/sse", "type": "http" } }, "inputs": [] }The weird part is that I can't even disable the Atlassian's
fetchtool, it keeps re-enable itself. Some kind of clash is happening I believe.patniko commentedon Mar 4, 2026
Is this related to the SDK or VS Code? Would expect with an SDK you would use external tools to bind the tools. Those take precedence over any MCP tool.
Confirmed we did not introduce a regression in the SDK. MCP tools are namespaced to prevent collisions with any existing tools and we prioritize SDK declared tools appropriately. Feel free to file a separate issue in case others have a similar problem, but for now I can't repro this in the SDK. Closing this specific issue for now.