consult_llm

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool queries an external LLM, requires specific input formatting (neutral questions with context), and mentions the web_mode alternative for browser-based services. It doesn't cover rate limits, authentication needs, or response format details, but provides substantial operational guidance.

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 well-structured with clear sections: purpose, input requirements, usage examples, and important guidelines. Each sentence adds value, though it could be slightly more concise by combining some guidance about question formulation. The information is front-loaded with the core purpose first.

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 (5 parameters, nested objects) and lack of annotations/output schema, the description provides substantial context about how to use the tool effectively. It covers the tool's purpose, input requirements, and behavioral expectations well. The main gap is the absence of information about return values or response format, but this is partially compensated by the detailed input guidance.

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 the schema already documents all parameters thoroughly. The description adds some context about the 'prompt' parameter (neutral, open-ended questions) and implies usage of 'files' for context, but doesn't provide additional semantic meaning beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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: 'Ask a more powerful AI for help with complex problems.' It specifies the verb ('ask'), resource ('more powerful AI'), and scope ('complex problems'), with no sibling tools to differentiate from. The description goes beyond the name 'consult_llm' by explaining what kind of consultation is provided.

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 guidance on when and how to use this tool: 'Provide your question in the prompt field and always include relevant code files as context.' It gives specific examples of use cases (code implementation, code review, bug analysis, architecture advice) and detailed instructions on question formulation (neutral, open-ended questions). Since there are no sibling tools, no alternative comparison is needed.

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