call_bridge_command

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the safety burden. It clearly discloses two key behavioral traits: it is dry-run by default, and mutating commands require allow_mutation=true. This meaningfully explains the execution model beyond the schema, though it does not detail side effects or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only three sentences with no redundant filler. The core action is front-loaded and the safety qualifier (dry-run default, mutation flag) follows naturally. The 'clean-room ToolsetRegistry-style adapter' sentence adds minor context but is not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no annotations, and no schema descriptions, the description is under-specified. It does not explain how to discover valid command names, what descriptor gates validate, how params should be structured, or what registry_path means. The output schema partially compensates, but the invocation path remains unclear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 7 parameters, the description needed to compensate but only touches on allow_mutation and dry_run. It does not explain command_name, params, params_json, allow_unknown, or registry_path, leaving most invocation details to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action (plan or execute) and a specific resource (one Ghost TCP bridge command through descriptor gates). It is distinct enough from generic siblings like call_tool and from discovery tools like search_bridge_commands, though 'descriptor gates' is jargon that is not fully explained.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context about dry-run behavior and mutation requirements, but it never says when to use this tool versus alternatives like describe_bridge_toolset or search_bridge_commands. There are no explicit exclusions or routing conditions to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.