Droid Monster

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

Annotations already declare this a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds genuine behavioral context beyond them: the output is shaped as one row per published figure, and a robot that does not publish a figure is rendered null rather than omitted.

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?

Two short sentences, zero filler, and the structural behavior of the result is front-loaded. Nothing is repeated or padded.

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?

There is no output schema, but the description covers the essentials an agent needs: the comparison layout and the null semantics for missing figures. It does not describe ordering of figures or error behavior for invalid robot identifiers, which is a minor remaining gap for a simple read tool.

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 schema already documents the 'maker/model' string format and enforces minItems 2 / maxItems 4, and the description's 'two to four' merely restates that constraint without adding syntax or format guidance. With one parameter it does no harm, but it contributes little meaning beyond the schema.

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?

States the resource (robots) and the comparison semantics ('side by side, one row per figure'), which is enough to distinguish it from single-robot siblings like get_robot. The verb is implied by the name rather than stated, and no sibling is named explicitly, so it stops short of a 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?

'Two to four robots' implies the multi-robot comparison case, but there is no explicit when-to-use guidance and no routing to alternatives such as get_robot for a single robot or find_robots for discovery. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds meaningful context the annotations do not: what each result contains (part number, the source document that attests fit, and the series scope), which matters because there is no output schema. It does not disclose result counts, pagination, or behaviour when no fitting part exists.

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?

One sentence, front-loaded with the core resource, and every clause carries information. The nested parenthetical listing document types is slightly heavy for a single sentence but is not wasted text.

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 one-parameter lookup with no output schema, the description usefully compensates by enumerating the returned fields, including the provenance document. Gaps remain around result volume, pagination, and the empty-result case, which keeps it from a 5.

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?

There is a single parameter with 100% schema description coverage, and the schema already documents the 'maker/model' format with an example. The description implies the robot argument drives fit and series scoping but adds no syntax or matching behaviour (e.g. fuzzy vs exact) beyond the schema. Baseline 3 applies.

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 specific resource and its compatibility scope: spare parts that fit a given robot, with the parts scoped to a series. That is unambiguous and clearly distinct from siblings like find_robots, get_robot, or compare_robots, which operate on robots rather than parts. It lacks an explicit verb ('find'/'list') and never names a sibling, so it stops short of a 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?

There is no when-to-use guidance, no statement of prerequisites, and no mention of alternatives among the six sibling tools. An agent must infer from the resource alone that this is the right call when it needs parts rather than robot metadata.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is in result semantics: it discloses that only robots publishing every filtered figure match, that per-figure in-scope counts are returned, and that values compare in canonical units unless `unit` is supplied. That is genuinely useful non-obvious behavior; it stops short of covering paging or filter-count limits.

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?

Three sentences, front-loaded with the core action and examples, and each sentence carries information (filtering, matching semantics, unit handling). The clause 'so a short list is never mistaken for everything that can do the job' is slightly discursive but earns its place as a caveat.

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 7-parameter, no-output-schema tool, the description covers the essential filtering model, matching rule, unit conversion, and return-shape caveat. Gaps are minor: no mention of pagination defaults or the maxItems=8 filter limit.

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 schema description coverage at only 43%, the description carries real weight: it explains the filter min/max/equals model, the `unit` conversion parameter, attribute keys (tying them to list_attributes), and sorting. It leaves `limit`, `offset`, `order`, and the 8-filter cap to the schema, which are mostly self-explanatory defaults.

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?

States a specific verb and resource: filter robots by published figures, with concrete examples (payload ≥ 20 kg, reach ≥ 1300 mm). It is clear this is a numeric/figure-based lookup, but it never names search_robots or get_robot, so the agent must infer the boundary from the sibling list alone.

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?

Usage context is implied by 'optionally within a category or maker' and the figure-filtering examples, which suggests when this tool fits. However, there is no explicit when-not guidance and no mention of the obvious alternative (search_robots) for keyword-style lookups, so routing remains inferential.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description goes beyond them by disclosing the shape of the payload — canonical units, maker-published values, and provenance documents — which is genuinely useful behavioral context. It omits only edge cases such as unknown-robot handling.

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?

A single front-loaded sentence with a tight three-item list ('each spec in its canonical unit, the value as the maker published it, the document it came from'), each element carrying distinct information. Nothing is padding and nothing is buried.

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?

With no output schema, the description carries the burden of describing returns, and it does so accurately by enumerating the three content categories. For a one-parameter read tool this is close to sufficient; only error behavior for an unrecognized robot is left unstated.

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 a single parameter at 100% schema description coverage, the schema already defines 'robot' fully, including the maxLength and the 'maker/model' example format. The description adds no further parameter meaning, so the minimum-viable baseline of 3 is appropriate.

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 precisely what is returned for a single robot: every spec in canonical unit, the published value, and the source document. That is a concrete verb-by-implication plus resource, and 'on one robot' scopes it. It does not, however, contrast itself with the lookalike siblings find_robots or search_robots, so an agent must infer the distinction between detail-fetch and discovery.

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?

There is no when-to-use guidance, no statement that a known 'maker/model' identifier is required, and no routing to alternatives such as find_robots (resolve a name) or compare_robots (multi-robot). The singular 'one robot' hints at a detail lookup but the description never states the condition that selects this tool over its siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real content beyond that by describing the shape of each entry (units, allowed values, per-robot publish counts), which tells the agent what it will actually receive.

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?

Two compact sentences, no filler. The purpose and contents come first, with the parameter guidance tucked at the end, so the value proposition is front-loaded.

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?

With no output schema, the description carries the return-value burden and does so at a summary level. It is nearly complete for a one-parameter read tool, missing only a note on default behavior when category is omitted and what category values are acceptable.

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 coverage is 0% and the single category parameter is an unconstrained string with no enum, so the schema gives no semantics. The description supplies the meaning ('see only the figures that apply to it'), which compensates well for the gap, though it does not hint at valid category values or that omission returns everything.

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?

States a specific resource ('the figures we record'), enumerates what each entry carries (canonical units, allowed values, publish counts), and explicitly ties it to the sibling tool find_robots as the source of the keys it filters on. An agent can distinguish this from find_robots or search_robots without opening either schema.

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 ('the keys find_robots filters on') and gives the effect of the optional category parameter, but never states explicitly when to call this versus its siblings or what happens if you omit category. Usage is inferable rather than spelled out.

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

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

Annotations already declare this a safe, idempotent, non-open-world read, so the safety profile is covered. The description adds above that bar by disclosing the fixed coverage set (UR and ABB) and enumerating the response contents (title, causes, doc link), which the annotations cannot express.

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?

One front-loaded sentence that leads with the core meaning and ends with the scope limitation. Slightly awkward phrasing ('a link to the page of the maker's document') but nothing is wasted.

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?

There is no output schema, and the description compensates by stating what is returned (title, listed causes, documentation link). Combined with the annotations' safety profile and the schema's parameter docs, an agent has everything needed to call and interpret this tool.

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 coverage is 100% and both parameters carry descriptions with concrete examples ('C204A3', 'universal-robots'). The description only loosely adds that 'maker' is limited to UR and ABB, so the structured fields do the heavy lifting; baseline 3 is appropriate.

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?

States a specific verb+resource (look up a robot maker's error code) and immediately enumerates what it returns: the title, the likely causes, and a documentation link. The sibling tools (find_robots, get_robot, search_robots, etc.) all concern robots or parts, so there is no ambiguity an agent could trip over.

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 closing clause 'Currently Universal Robots and ABB' tells the agent exactly when this tool will and will not succeed, which is a real usage constraint. It does not name an alternative for unsupported makers, so it stops short of explicit when-not routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond that by disclosing the return payload: each robot's reference for other tools plus the count of specs held, which is genuinely useful for deciding whether to chain into get_robot.

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?

Two tightly packed sentences, front-loaded with what it does before what it returns. No filler, though the second sentence crams two return facts together.

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?

There is no output schema, and the description partly compensates by describing the return shape. However, for a search tool sharing a name-space with find_robots, the missing differentiation and undocumented limit parameter leave an agent under-informed despite the low overall complexity.

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 coverage is 50%: query is documented with an example but limit is not. The description adds meaningful semantics for query (name, maker, or kind of robot) beyond the schema's example strings, but says nothing about the limit parameter. This sits at the baseline for partial 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?

States a specific verb (find) plus resource (robots) and enumerates the searchable facets: name, maker, kind. That is clear on its own, but the definition never distinguishes itself from the sibling find_robots, which appears to do the same thing, so it falls short of a 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?

There is no guidance on when to use search_robots versus the near-identical find_robots, nor versus get_robot for direct lookup. The agent is left to guess between two similarly named siblings with no disambiguating condition.

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