MCP transport: is instance-delete publishes an input_schema with an invalid property key, poisoning the entire tool list

[zbeekman]

AI Disclosure: I had Claude Cowork draft and debug most of this. I have given it a once over and it is consistent with my understanding/experience.

MCP transport: is instance-delete (and likely other delete/update tools) publish an input_schema with an invalid property key, poisoning the entire tool list

Repo to file against: IBM-Cloud/ibm-cloud-cli-release (the core MCP server implementation lives in the IBM Cloud CLI binary). Cross-reference IBM-Cloud/mcp if the maintainers prefer.

Summary

When an MCP host loads the ibmcloud_is_instance-delete tool definition published by ibmcloud --mcp-transport stdio, the tool's input_schema.properties contains at least one property key that does not match the JSON schema pattern ^[a-zA-Z0-9_.-]{1,64}$ required by Anthropic's Messages API. As soon as that tool is present in the loaded tool set, every subsequent API request fails with HTTP 400 — not just calls that target the delete tool — because the API validates the entire tools array on each request.

This effectively makes any session that loads the delete tool unusable until the session is rolled back to a point before the tool was added.

Observed error

API Error: 400 {
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "tools.9.custom.input_schema.properties: Property keys should match pattern '^[a-zA-Z0-9_.-]{1,64}$'"
  },
  "request_id": "req_011CZri2eLc7WoM3Vhu4sd9T"
}

The index (tools.9) corresponds to the position of ibmcloud_is_instance-delete in the loaded tool array at the moment the request was sent.

Reproduction

1. Start an MCP host (Claude Desktop / Cowork / any Anthropic-API-backed client) with the IBM Cloud MCP server configured via the standard ibmcloud --mcp-transport stdio recipe.
2. Cause the host to load the ibmcloud_is_instance-delete tool into the active tool set. In hosts with deferred/lazy tool loading this happens the first time the tool is referenced; in hosts that eagerly load all tools this happens immediately at startup.
3. Issue any chat request — even one that does not invoke the delete tool.
4. Observe: the Anthropic Messages API returns HTTP 400 with the input_schema.properties pattern-mismatch error above. Rolling back / removing the tool from the loaded set restores normal behavior.

Tools that load successfully in the same session (confirming the rest of the MCP is healthy):

• ibmcloud_is_instances — OK
• ibmcloud_is_instance (note: parameter is INSTANCE, uppercase) — OK

Impact

• Severity: high. Any session that loads the delete tool is dead-on-arrival for all further model calls, not only delete attempts.
• This blocks any automation that uses the IBM Cloud MCP to terminate VPC resources, and it creates a silent foot-gun: the failure cascades to unrelated tools in the same session, making diagnosis hard.
• Likely affects other *-delete, *-update, and similar tools that share the same schema-generation code path. Worth auditing every tool the MCP publishes against the pattern ^[a-zA-Z0-9_.-]{1,64}$.

Suspected root cause

The Anthropic Messages API requires every key under a tool's input_schema.properties to be a non-empty string of 1–64 characters drawn from [a-zA-Z0-9_.-]. Common ways IBM-Cloud-CLI-derived MCP tools could violate this:

• A property key containing a space (e.g. a help-text line used as a key).
• A property key containing /, :, =, <, >, or parentheses (common in CLI help synopses like --force=BOOL, <INSTANCE_ID>, or (optional)).
• An empty string key, or a key longer than 64 chars.
• A key derived from a multi-flag CLI synopsis (e.g. -f, --force) that didn't get split before being used as a property name.

Because ibmcloud_is_instance itself publishes a valid schema (its single INSTANCE property passes), the bug is almost certainly in whatever code path generates properties for commands that take flags in addition to a positional argument — i.e. delete/update commands rather than pure read commands.

Suggested fix

1. In the MCP schema-generation layer of the CLI, sanitize every property key before emitting it: strip leading --, split on ,, drop whitespace, replace any disallowed character with _, and truncate to 64 characters. Fail loudly (log + skip) on empty keys.
2. Add a startup self-check that regex-validates every published tool's input_schema.properties keys against ^[a-zA-Z0-9_.-]{1,64}$ and refuses to expose any tool that fails, so a malformed tool never poisons a live session.
3. Add a regression test that asserts ibmcloud_is_instance-delete (and a representative *-update tool) passes the Anthropic Messages API tools validator.

Workarounds for users until fixed

• Do not load ibmcloud_is_instance-delete (or other *-delete / *-update tools with the same bug) into MCP sessions. Delete instances via the IBM Cloud console or a local ibmcloud is instance-delete call instead of through the MCP.
• If a session has already been poisoned, roll back to a turn before the malformed tool was added; you cannot recover in-place because the tool list is part of every subsequent request.

Environment

• IBM Cloud CLI: ibmcloud 2.42.0 (178ee3978-2026-03-27T18:09:02+00:00)
• OS: macOS Sequoia 15.7.5 (Intel, MacBook Pro 16-inch 2019, 2.4 GHz 8-Core Core i9)
• MCP transport: stdio
• MCP host: Claude desktop app (Cowork mode) — but the error comes from the Anthropic Messages API, so any host that forwards the published tool list would hit it.
• Region reproduced in: us-east (not region-specific — the bug is in the tool schema, not the API response).

Related

• MCP transport: positional args mishandled in access-group-user-add and user-policy-create #225 — different MCP transport bug (positional-arg mapping). Mentioned only to note that the MCP transport layer has other rough edges; the two issues are independent.