annotations.readOnlyHint is dropped at registration, so bridged MCP tools are always exclusive

[ezzaldeeen]

what I observed

dsh-tools documents the classification rule:

ctx.tools.executionMode(exec) returns parallel only when the visible
definition's isConcurrencySafe(exec.arguments) classifier returns exactly
true; unknown, hidden, undeclared, invalid, or throwing classifications are
exclusive.

dsh-tool-fs declares isConcurrencySafe. @deepseek-ai/dsh-mcp-client never
does — the string doesn't appear in its published lib/index.js. So every
bridged MCP tool is classified exclusive by construction, and
maxParallelToolCalls can never apply to any of them.

MCP already carries the needed signal: tools/list returns
annotations.readOnlyHint, which means "no side effects". It appears to be read
off the wire and then discarded when the tool is registered on ctx.tools.

how I confirmed it

Our MCP server marks its read tools readOnlyHint: true and deliberately leaves
write tools unhinted (they do read-modify-write on one JSON file, so
serialising them is correct).

Asking the agent for three independent reads, I never saw more than one call in
flight — measured from session/update frames over ACP, counting tool_call
against terminal tool_call_update. Same result on models that batch tool calls
natively, so it isn't the provider.

suggested mapping

annotations.readOnlyHint === true → isConcurrencySafe: () => true

Everything else stays exclusive, matching the registry's fail-closed default.
readOnlyHint is advisory in the MCP spec, so this trusts the server — but
mounting a server is already an act of trust, and the blast radius is
concurrency rather than permission.

I'd expect this to be a small change in the executor/registration path
(createExecutor, and the ctx.tools.register(definition) call near it).

version

@deepseek-ai/dsh-mcp-client@0.1.0-rc.7. Read from compiled output, not source.