Grandet

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

Annotations already establish a safe read-only, idempotent, closed-world operation, but the description adds real semantics beyond them: host is attribution-only and 'never selects the inference route', an unrecorded app connection yields only a price-only recommendation rather than a compatibility claim, and presets are estimates. These clarify what the tool will and won't assert.

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?

It is front-loaded with the purpose first, but the body is a run-on sequence of semicolon-joined fragments that reads like release notes ('legacy recommended/alternative/cheapest retain their old meanings'). Much of it earns its place, yet the opaque jargon and lack of grouping reduce scannability for an agent.

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 an output schema present, return values need not be explained, and for a 19-parameter tool the description covers selection rules, attribution semantics, and alternative-tool routing well. Gaps are minor: it never states the core comparison semantics between price units beyond the schema enum, and unit-comparison guidance is thin.

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 already 100%, so the baseline is 3, but the description adds constraints the schema does not spell out: 'Provide exactly one model or name selector', that client is a legacy alias of targetApp, that profile/protocol should be omitted for multi-protocol apps, and that targetApp is sent only when the user names an application. This meaningfully supplements the structured fields.

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 opening sentence states a concrete verb and resource ('Compare Grandet model prices within each unit'), and the tool is differentiated from grandet_list_apps by an explicit rule ('Use grandet_list_apps only when application facts are needed'). It does not, however, distinguish itself from the other siblings (grandet_resolve_model, grandet_quote_evidence, grandet_find_free_credits), and the 'find cheapest' purpose implied by the name is only indirectly conveyed.

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?

Dense but substantive routing rules: when to send targetApp, when to omit profile/protocol, when host is irrelevant, when to use view=compact, and an explicit alternative tool (grandet_list_apps) with its trigger condition. It gives clear context and several exclusions, though it lacks a clean statement of when NOT to use this tool versus the free-credits or evidence 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description earns credit above that by disclosing what a result contains (stated benefit, requirements, deadline, observation, claim link) and how pagination behaves, though it says nothing about rate limits or freshness guarantees of the catalogue.

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?

Front-loaded with the purpose and then moves straight into filter semantics and pagination with no filler sentences. Slightly dense and telegraphic in places, which costs it a perfect score, but every sentence carries information.

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 13-parameter, optional-argument search tool with an output schema present, the description covers purpose, the two non-obvious filter semantics and pagination — the items an agent is most likely to get wrong. Return-value explanation is redundant given the output schema, and no gaps materially block correct invocation.

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%, so the baseline is 3, but the description genuinely adds meaning beyond the schema: it explains that userCanMeet=no_card excludes explicit required/conditional card entries while unknown card requirements stay labelled unknown, and that application categories describe programs rather than user eligibility. That clarifies filter semantics the schema leaves ambiguous.

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') and a well-scoped resource ('official free tiers, application-based credits and relay free groups'), which is clearly distinct from grandet_find_cheapest_api and the resolver/glossary siblings. It doesn't name an alternative sibling explicitly, 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?

It gives conditional guidance for the no_card filter and tells the agent to 'Follow pagination', which is real usage direction, but never says when to choose this tool over grandet_find_cheapest_api or grandet_quote_evidence. Usage is implied rather than contrasted with alternatives.

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?

Beyond the annotations, the description discloses that glossary terms explain source claims but "do not verify quality," and that unknown terms return up to three related FAQ links. These are useful behavioral details not present in the schema or annotations. Auth, rate limits, and return format are not covered, but the output schema and annotations already handle much of that.

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 four short sentences and front-loads the core purpose. Every sentence adds useful information: purpose, epistemic caveat, query guidance, and unknown-term behavior. There is no redundant or filler 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?

Given the 100% schema description coverage, the rich annotations, and the presence of an output schema, the description covers the remaining gaps well. It explains purpose, the non-verification caveat, pagination, and unknown-term behavior without needing to restate optional attribution parameters.

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 parameter semantics are already well documented. The description reinforces q/category and pagination but adds no syntax or format details beyond what the schema already provides. A 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?

The description opens with a specific verb and resource: "Look up the published Grandet relay glossary." It also distinguishes the glossary from verification tools by explaining that terms explain site labels but "do not verify quality." This separates it from siblings such as grandet_quote_evidence or grandet_find_cheapest_api.

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 gives clear invocation context: "Query q or category and follow pagination." It also sets expectations for unknown terms, but it does not explicitly state when not to use the tool or name an alternative sibling. The purpose itself makes the appropriate use case clear.

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, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: app profiles determine API compatibility and 'MCP capability alone does not prove an inference route or Skill installation,' which shapes how the agent should interpret results. Return format is not described, but an output schema exists to carry that.

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 short sentences, front-loaded with the core action and followed by the usage condition and the interpretive caveat. No hedging, no repetition, and every sentence carries new information relevant to invoking the tool correctly.

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 0 required parameters, a complete output schema, and full annotation coverage, the description only needs to convey purpose and when to call it, which it does. The added note that MCP capability is not proof of an inference route closes the main interpretive gap an agent would face here.

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 every parameter including app, host, targetApp, lang, skillBuild, and skillVersion is already documented, with host explicitly marked as attribution-only. The description adds no parameter-level detail (e.g., how app vs targetApp interact) beyond what the schema states, so the baseline of 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 names a specific verb and resource: reading the shared Grandet application list and inference profiles. It is clearly distinguishable in intent from siblings like grandet_find_cheapest_api or grandet_resolve_model, though it does not explicitly name those alternatives. The phrase 'inference profiles' is slightly vague but is clarified by the surrounding sentences.

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?

It gives an explicit condition for use: 'Use only when the target app ID, supported protocol or configuration variant is uncertain,' which tells the agent when this lookup is warranted. It also supplies the rationale that app profiles, not MCP capability, determine API compatibility and Skill installation. It stops short of naming a concrete alternative tool to use when the app ID is already known.

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 genuinely non-obvious behavior: results are paginated, a missing row on one page is not proof of absence, and the call neither tests model quality nor spends money.

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 with no filler, front-loading the read operation before the usage caveat and the pagination warning. The opening clause is dense with undefined jargon, which costs a little readability, but nothing is redundant.

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?

An output schema exists, so return values need not be described, and the description still covers pagination semantics and the scope of what the call does not do. For a read-only 12-param tool the remaining gap is minor: no note on attribution-only params (host, lang, skillBuild) being optional.

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% across 12 parameters, so the schema already carries the heavy lifting and the baseline is 3. The description restates the model/rowId pairing and page-following rule but adds no format, precedence or default detail beyond what the schema documents.

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: reads one provider's paged public declarations for a model plus optional rowId. It is distinguishable from list/find siblings by its single-provider, single-row scope, though the term "declarations" is domain jargon that is never defined and the title's "quote evidence" framing isn't reconciled with it.

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?

"Use only when a detail matters, not before every recommendation" is an explicit when-to-use and when-not-to-use rule, which is rare and valuable. It stops short of naming the alternatives (grandet_find_cheapest_api, grandet_resolve_model) that an agent should prefer for discovery, so routing is implied rather than 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 readOnly/idempotent/non-destructive and a closed world, so the safety profile is covered. The description adds real context beyond that: output is a page of candidates rather than a ranked answer, and ambiguous matches should not be silently substituted across generations. It does not discuss rate limits or disambiguation fallbacks.

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 short sentences, zero filler, front-loaded with the purpose and immediately followed by the result-shape caveat and the matching rule. Every sentence earns its place.

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 an output schema present and full schema coverage, the description need not explain return values or parameters; it covers purpose, result shape, and disambiguation policy for a 7-parameter tool. A note on paging behavior/termination would have closed the remaining gap.

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 every parameter (name, host, lang, page, targetApp, skillBuild, skillVersion) is already documented in the schema, including which are attribution-only and when to send targetApp. The description adds no parameter-level detail, so the baseline of 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?

Specific verb+resource: 'Look up public model identifiers when a requested name is ambiguous.' It also explicitly distinguishes itself from the sibling grandet_find_cheapest_api by stating results are 'not a cheapest-provider ranking,' so an agent can route 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?

States the triggering condition ('when a requested name is ambiguous') and the resolution rule ('Prefer an exact officialId match; do not silently substitute a different model generation'). It implicitly excludes the pricing use case by naming the cheapest-provider sibling, but does not enumerate other alternatives or say when to stop paging.

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