aptos_debugging_helper_prompt

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits: it's a prompt tool for error recovery that redirects to an MCP-first approach, implying it guides rather than executes actions. However, it lacks details on what the prompt contains, how it redirects, or any constraints like rate limits or permissions. This is adequate but leaves gaps in understanding the tool's behavior.

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 highly concise and well-structured: it's a single sentence that front-loads key information ('ERROR RECOVERY PROMPT') and efficiently lists usage scenarios. Every word earns its place, with no wasted text, making it easy to scan and understand quickly.

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?

Given the tool's complexity (simple prompt with no parameters), no annotations, no output schema, and rich usage guidelines, the description is fairly complete. It covers purpose and usage well but lacks details on what the prompt outputs or how the MCP-first approach works. For a zero-parameter tool, this is sufficient, though not exhaustive.

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?

The tool has 0 parameters with 100% schema description coverage, so no parameters need documentation. The description doesn't add parameter semantics, which is acceptable here. A baseline of 4 is appropriate as it doesn't need to compensate for any parameter gaps, but it doesn't exceed expectations by providing extra context.

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 clearly states the tool's purpose as an 'ERROR RECOVERY PROMPT' for Aptos-related errors, stuck debugging loops, or when about to try generic blockchain solutions, with a specific action to 'redirect to MCP-first debugging approach.' It distinguishes from siblings by focusing on error recovery rather than development, building, or resource management. However, it doesn't specify the exact verb or resource beyond 'prompt,' making it slightly less specific than a perfect 5.

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 explicit usage guidelines: 'Use this immediately when encountering Aptos-related errors, stuck in debugging loops, or when about to try generic blockchain solutions.' It clearly states when to use the tool (in error scenarios) and implies when not to use it (in non-error or non-Aptos contexts), effectively distinguishing it from sibling tools that handle development, building, or resource operations.

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