get_node_template

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

Without annotations, the description fully takes on the transparency burden. It discloses a notable behavioral trait: the vendor label is a 'best-effort' extraction from the template's description, and that EVE-NG's API has no explicit vendor field. This informs the agent of potential data quality issues. However, it does not mention other behaviors like idempotency, authentication requirements, or error cases, though for a simple read operation this may be acceptable.

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: three short paragraphs – purpose, a critical behavioral note (vendor extraction), and the parameter definition. Each sentence serves a distinct purpose with zero redundancy. The primary purpose is front-loaded in the first line.

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 simple single-parameter lookup tool, the description covers the main return aspects (available images, default options, vendor label) and the parameter. The existence of an output schema (context signal) suggests return values are structured, but the description does not need to reiterate the schema. It provides enough context for an agent to understand what the tool returns and its caveats.

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 input schema has 0% description coverage (parameter 'template' only has a title). The tool description compensates fully by providing an 'Args:' section that defines the parameter as 'Template id' and gives concrete examples: 'e.g., "iol", "vios", "csr1000v".' This adds meaning beyond the schema and clearly informs the agent what values to use.

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: 'Get details (available images, default options) for one node template.' The verb 'get' and the resource 'node template' are specific, and the examples of what details are included (images, default options) differentiate it from siblings like list_node_templates which would list all templates without details.

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 implies usage by requiring a specific template id ('for one node template') and provides an 'Args' section with example template IDs. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'Use this when you need details for a specific template; for a list of all templates, use list_node_templates instead'). The guidance remains implicit.

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