gc_peer

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only lists action names without explaining behavioral implications: what spawn requires, what destroy does (destructive action?), what get vs list returns, rate limits, or side effects. For a multi-action tool with a destroy operation, this is a significant gap.

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 very brief (two lines). It's concise but borderline under-specified. The action list is useful but the overall description reads more like a stub or placeholder than an actual tool definition. Brevity here sacrifices necessary explanatory content.

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?

This is a 5-parameter tool with an enum action field, nested objects (config), and no output schema. No annotations back it up. The description covers essentially none of the behavioral complexity—what each action does, return values, prerequisites, or error conditions. For a multi-action tool, this is inadequate.

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?

Schema description coverage is 100%, so parameters are documented in the schema (action enum, config, message, peer_agent, session_id each have descriptions). The description itself adds no parameter information beyond naming the actions. With high schema coverage, baseline 3 is appropriate, though no additional value is added.

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 says it's a 'Legacy alias for gc_peer_conversation' and lists actions, but it doesn't explain what the tool actually DOES beyond being an alias. It doesn't describe the purpose of spawn/turn/get/list/destroy operations in any meaningful way. The reader must infer that 'gc_peer_conversation' is a peer conversation tool from the sibling list.

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?

No guidance is given on when to use this vs alternatives. While it names gc_peer_conversation as the replacement, it doesn't say when a user should prefer the new tool, clarify the relationship, or explain what peer conversations are used for. There's no when/when-not guidance.

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