Support layering custom MCP tool definitions on top of the toolkit's tools.json

[robgraessle]

Use Case

Summary

The Simulink Agentic Toolkit registers its MCP tools by passing --extension-file=<TOOLKIT_ROOT>/tools/tools.json to matlab-mcp-core-server. Third parties may want want to ship additional typed MCP tools that ride on top of the Simulink toolkit, without forking it or modifying its tools.json. Today, matlab-mcp-core-server only honors a single --extension-file (last-wins), so this is not possible with one MCP server process.

Please add a way for downstream extensions to contribute additional MCP tool definitions to the same MCP server.

Use Case

We are building a Vitis Model Composer (VMC) skills layer that depends on the Simulink Agentic Toolkit. Two of the operations we need would benefit materially from being typed MCP tools rather than skills that compose evaluate_matlab_code calls:

• Hub block configuration — uses the 4-argument vmchub_set_param(hubBlockPath, subsystemPath, parameterName, value) API. The first two args are both Simulink paths and are easy to swap; a typed JSON schema with named parameters eliminates an entire class of LLM error.
• SSR reconfiguration of AIE DSP blocks — encodes a topology transform (split/merge Selector/Mux subsystems around the DSP block, recompute port counts, preserve connections). This is algorithmic logic worth freezing into one tested call rather than re-deriving from prose on every invocation.

For now we are shipping these as skills that drive the Simulink toolkit's existing tools (model_edit, evaluate_matlab_code). When multi-extension support lands, we would graduate them to typed tools without disturbing the Simulink toolkit.

Current Behavior

matlab-mcp-core-server --help (v0.9.0) lists --extension-file as a single-valued flag with no documented mechanism for layering. Empirical probe:

$ ~/.local/bin/matlab-mcp-core-server \
    --extension-file=/tmp/probe-A.json \
    --extension-file=/tmp/probe-B.json \
    --matlab-session-mode=existing < /dev/null
Failed to read extension file "/tmp/probe-B.json". Check that file is valid.

Only file B.json was attempted. File A.json was silently overwritten with no warning. This is classic last-wins single-valued flag behavior.

Relevant Skill or MCP Tool

No response

Proposed Behavior

Any one of the following would unblock the use case:

1. Repeat-flag --extension-file — accept the flag multiple times, additive. Tools from all files are merged into the server's tool registry. Name collisions could be reported as warnings or errors.
2. --extension-files=A,B,C — comma-separated list with the same merge semantics.
3. --extension-dir=<dir> — load all *.json extension files from a directory, allowing a drop-in convention.
4. Toolkit-side merge — document a ~/.simulink-agentic-toolkit/extensions/ drop-in directory; the Simulink toolkit's setup skill merges all tools.json files into a single combined extension file at install time and points the MCP config at it. Keeps the request scoped to this repo without requiring matlab-mcp-core-server changes.

Approaches 1–3 require coordination with the matlab-mcp-core-server team. Approach 4 can be implemented entirely in the Simulink toolkit's setup skill.

Current Workaround

Workarounds Considered

• Run a second matlab-mcp-core-server process under a different MCP server name (e.g., vmc) sharing the user's MATLAB session via --matlab-session-mode=existing. We have not validated that the toolkit's session-sharing supports two attached server processes; if it doesn't, this path is closed. Even if it works, two server processes per user adds resource overhead and bifurcates the tool namespace (mcp__simulink__* vs mcp__vmc__*).
• Fork the Simulink toolkit's tools.json and add VMC tools to the fork. Rejected — couples VMC release cadence to the Simulink toolkit and creates merge debt.

Additional Context

Environment

Detail	Value
MCP Server Binary	~/.local/bin/matlab-mcp-core-server v0.9.0
SATK Version	development build (commit 635da42, "2026.04.24 release")
OS	Linux 4.18.0-553.el8_10.x86_64
MATLAB Version	R2025b (25.2.0.2998904)

Notes

• A short note in GETTING_STARTED.md documenting the current single-extension-file behavior would help downstream extension authors plan, even before any capability change.
• A documented stance on whether/how the project intends to support layered extensions would let us decide whether to wait or pursue the Approach 4 workaround in our own setup tooling.

[agoldsbo]

Thank you for the detailed use case. We are working on adding support for multiple extensions files in the MATLAB MCP Core Server. This will be part of a future release.