Is your feature request related to a problem? Please describe.
I embed chrome-devtools-mcp in a browser-tool integration and want to extend selected tools while keeping the server's existing browser context and ToolHandler pipeline.
The programmatic factory added by #1038 / #1043 makes embedding possible. The next limitation is customization: in 1.8.0, createMcpServer returns the SDK server, but its context accessor, tool registration and mutex are internal. At current main (a918b7b4086bcb14105b80abab1deb882535f15e), McpServer.from exists, but McpServerOptions still has only logFile, and those facilities remain private.
Two concrete uses are adding a separate snapshot-export tool that uses the existing page context, and reporting current effective file roots without creating a browser connection. Mutating exported tool definitions or context methods globally couples the embedder to internals and makes independent server instances difficult to isolate.
Describe the solution you'd like
A supported, opt-in, per-server extension surface. The exact API should follow maintainer preferences; the needed capabilities are:
- Add or replace tool definitions before
ToolHandler construction. Custom definitions should still pass through the normal registration/validation pipeline, page-ID routing, declared file checks and the existing tool mutex. A transform over per-instance definitions is one possible design; global exports must not be mutated.
- Inspect the current context's lifecycle and effective-root information passively, through a limited view/getter or callback. Before context creation and after disposal it should report absence. Observation must not launch/connect to a browser; reconnects and root changes must update the view. A broad public mutable context is not required for this diagnostic use case. Custom tool handlers can use the context already passed by
ToolHandler.
Suggested acceptance checks: unchanged default tool catalog/results; two configured server instances do not affect one another; custom tools retain routing, root/file refusals and mutex behavior; passive diagnostics do not create a context; reconnect, root refresh and disposal do not expose stale state.
Describe alternatives you've considered
- Calling the returned SDK server's
registerTool: available today, but does not provide the existing context/ToolHandler pipeline by itself.
- Modifying exported definitions and context methods before startup: works for a pinned version, but relies on shared mutable internals.
- Copying registration/context management or opening another browser connection: duplicates lifecycle, permission and synchronization logic.
A small supported API would be preferable to a general plugin framework or a downstream server fork. This request does not require changing CLI tool defaults or weakening existing checks.
Additional context
Companion request: #2688 covers snapshot rendering. These capabilities can be designed and delivered independently.
Source inspected: server factory and registration, ToolHandler.
This builds on the completed embedding request #1038 rather than asking for another server factory. It is an API-design request, not a claim that a new implementation has been tested. Would this extension surface fit the supported embedding API, or is there an existing intended route I have missed?
Is your feature request related to a problem? Please describe.
I embed
chrome-devtools-mcpin a browser-tool integration and want to extend selected tools while keeping the server's existing browser context andToolHandlerpipeline.The programmatic factory added by #1038 / #1043 makes embedding possible. The next limitation is customization: in 1.8.0,
createMcpServerreturns the SDK server, but its context accessor, tool registration and mutex are internal. At current main (a918b7b4086bcb14105b80abab1deb882535f15e),McpServer.fromexists, butMcpServerOptionsstill has onlylogFile, and those facilities remain private.Two concrete uses are adding a separate snapshot-export tool that uses the existing page context, and reporting current effective file roots without creating a browser connection. Mutating exported tool definitions or context methods globally couples the embedder to internals and makes independent server instances difficult to isolate.
Describe the solution you'd like
A supported, opt-in, per-server extension surface. The exact API should follow maintainer preferences; the needed capabilities are:
ToolHandlerconstruction. Custom definitions should still pass through the normal registration/validation pipeline, page-ID routing, declared file checks and the existing tool mutex. A transform over per-instance definitions is one possible design; global exports must not be mutated.ToolHandler.Suggested acceptance checks: unchanged default tool catalog/results; two configured server instances do not affect one another; custom tools retain routing, root/file refusals and mutex behavior; passive diagnostics do not create a context; reconnect, root refresh and disposal do not expose stale state.
Describe alternatives you've considered
registerTool: available today, but does not provide the existing context/ToolHandlerpipeline by itself.A small supported API would be preferable to a general plugin framework or a downstream server fork. This request does not require changing CLI tool defaults or weakening existing checks.
Additional context
Companion request: #2688 covers snapshot rendering. These capabilities can be designed and delivered independently.
Source inspected: server factory and registration, ToolHandler.
This builds on the completed embedding request #1038 rather than asking for another server factory. It is an API-design request, not a claim that a new implementation has been tested. Would this extension surface fit the supported embedding API, or is there an existing intended route I have missed?