What happened?
step mcp add accepts any string as the server name — no charset or length validation. That name is then used verbatim as the model-facing tool-name prefix: packages/coding-agent/src/step/mcp.ts:461 builds
const name = `${server.name}__${sanitizeName(remote.name)}`;The remote tool name is sanitized; the server name is not, and the provider layer sends it through unchanged. A server added as my.server therefore registers tools like my.server__hello, which violates the tool-name charset both wire protocols require (OpenAI ^[a-zA-Z0-9_-]{1,64}$, Anthropic ^[a-zA-Z0-9_-]{1,128}$). Once such a server connects, every request fails with an API error that doesn't point at the config entry.
The MCP import path already enforces exactly this invariant — sanitizeServerName in packages/coding-agent/src/step/mcp-import.ts, with a comment saying the server name is "restricted to what a tool name may contain". step mcp add (in apps/cli/src/main.ts) is the one path that skips it. Long names can also push server__tool past the 64-char limit.
Steps to reproduce
step mcp add "my.server" -- npx -y some-mcp-server # accepted, stored as-is
step mcp list
cat ~/.stepcode/config.toml
Verified on 0.1.0 built from source (main @ cb5fc14): names like my server/x and my.server demo are accepted and written to config.toml unchanged, and createRemoteTool registers <name>__<tool> with the raw prefix. The TUI /mcp command and the plugin marketplace are not affected — step mcp add is the only unvalidated write path.
Expected behavior
step mcp add should reject (or sanitize with a notice, like the import path does) names outside [a-zA-Z0-9_-], or registration should sanitize the prefix defensively. I'd be happy to implement this — let me know which side you prefer.
Version
0.1.0 (built from source, main @ cb5fc14)
Note: I used an AI assistant to help polish the wording of this report; the repro steps and code reading are my own and were run locally.
What happened?
step mcp addaccepts any string as the server name — no charset or length validation. That name is then used verbatim as the model-facing tool-name prefix:packages/coding-agent/src/step/mcp.ts:461buildsThe remote tool name is sanitized; the server name is not, and the provider layer sends it through unchanged. A server added as
my.servertherefore registers tools likemy.server__hello, which violates the tool-name charset both wire protocols require (OpenAI^[a-zA-Z0-9_-]{1,64}$, Anthropic^[a-zA-Z0-9_-]{1,128}$). Once such a server connects, every request fails with an API error that doesn't point at the config entry.The MCP import path already enforces exactly this invariant —
sanitizeServerNameinpackages/coding-agent/src/step/mcp-import.ts, with a comment saying the server name is "restricted to what a tool name may contain".step mcp add(inapps/cli/src/main.ts) is the one path that skips it. Long names can also pushserver__toolpast the 64-char limit.Steps to reproduce
Verified on 0.1.0 built from source (main @ cb5fc14): names like
my server/xandmy.server demoare accepted and written to config.toml unchanged, andcreateRemoteToolregisters<name>__<tool>with the raw prefix. The TUI/mcpcommand and the plugin marketplace are not affected —step mcp addis the only unvalidated write path.Expected behavior
step mcp addshould reject (or sanitize with a notice, like the import path does) names outside[a-zA-Z0-9_-], or registration should sanitize the prefix defensively. I'd be happy to implement this — let me know which side you prefer.Version
0.1.0 (built from source, main @ cb5fc14)
Note: I used an AI assistant to help polish the wording of this report; the repro steps and code reading are my own and were run locally.