Grandet

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real behavior beyond that: host is attribution-only and never selects the inference route, an unrecorded app connection permits a price-only recommendation but no compatibility claim, and presets are estimates. It does not describe pagination or result-size behavior beyond the brief view caveat.

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 content is dense and jumps between unrelated topics (ordering semantics, view modes, targetApp, host, matching, API keys) without clear front-loading, and some clauses ('legacy recommended/alternative/cheapest retain their old meanings') are opaque to a fresh reader. Few sentences are wasted, but structure is poor.

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 19-parameter tool with no output schema, the description covers identity/route selection, result shaping, and several defaults, while the schema fully documents the remaining fields. It falls short only on explaining the shape of returned listings beyond the view-mode trade-offs.

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 adds semantics not in the schema: exactly one of model/name must be supplied, host never selects the route, targetApp should be omitted for a multi-protocol app unless specified, and view defaults to compact. These clarify selection intent rather than repeating field text.

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 — comparing Grandet model prices within a single unit of account and reading listings for ordering/conditions. It is clearly distinguishable from grandet_list_apps and grandet_resolve_model, though the title's 'cheapest' framing is not echoed as crisply in the body.

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?

Explicit conditions throughout: send targetApp only when the user names where the API will be used; use grandet_list_apps only when application facts are needed; do not request API keys; with no target, compare directly. It names the alternative sibling and the when-not cases.

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, non-open-world), so the bar is lower. The description still adds useful behavior: the exact shape of the returned evidence (stated benefit, six requirements, deadline, original observation, claim link), the need to page through results, and the payload tradeoff between compact and full views — none of which the annotations convey.

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?

Five tight sentences with no filler, front-loaded with purpose and return shape before the interpretive rules and pagination/view notes. The view sentence largely restates the schema's own size figures, which is the only mild redundancy.

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 13 parameters, no output schema and no required fields, the description usefully stands in for the missing output schema by describing return content, and it flags pagination. It does not touch several parameters (asOf, releaseSet, targetApp, skillBuild), but the 100% schema coverage carries those, leaving no material gap for 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 description coverage is 100%, so the baseline is 3. The description goes beyond the schema by clarifying that unknown requirements do not satisfy userCanMeet=no_card and that application categories describe the program rather than the user's eligibility — semantic nuances the enum text alone does not carry.

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 first sentence states a specific verb and resource set: "Find current official free tiers, application-based credits and relay free groups," and the second sentence enumerates the returned fields (benefit, requirements, deadline, observation, claim link). This clearly separates it from grandet_find_cheapest_api and grandet_list_apps, though it never names those siblings explicitly.

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 real conditional guidance for result interpretation (userCanMeet=no_card needs an explicit no-card condition; application categories describe programs, not user eligibility) and tells the agent to follow pagination. However, it never says when to prefer this tool over grandet_find_cheapest_api or grandet_list_apps, so tool-selection guidance is left to inference.

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 bar is lower, and the description adds genuinely useful epistemic context: labels are source claims, glossary terms explain them, and neither verifies quality. It also flags pagination behavior. Return shape is left unstated, but no output schema exists to compensate, so this is a minor gap.

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 tight sentences with the purpose front-loaded, followed by the caveat and the usage note. Every sentence carries information, though the caveat sentence is slightly dense and could be phrased more directly.

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 read-only, no-required-parameter lookup with a fully documented schema and no output schema, the description covers purpose, an important semantic caveat about what glossary results mean, and pagination. It is complete enough to invoke correctly, with only return-format detail absent.

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 all five parameters (q, lang, page, limit, category) are already fully documented in the schema. The description only echoes that q or category are the query axes and that pagination exists, adding little beyond the structured fields. 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 verb and resource: 'Look up the published Grandet relay glossary.' It is clearly distinguishable from siblings like grandet_resolve_model or grandet_find_cheapest_api, though it never names or contrasts with them explicitly, which keeps it from 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?

'Query q or category and follow pagination' gives procedural guidance on which parameters drive the lookup and how to page, but there is no statement of when to use this tool versus a sibling or when not to use it. Usage is implied rather than delineated.

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 useful interpretive context ('MCP capability alone does not prove an inference route or Skill installation') but no return format, pagination, or freshness 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?

Three sentences, each doing distinct work: what it reads, why the data matters, and when to invoke it. Front-loaded and free of filler, though the middle sentence could be tightened.

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?

No output schema exists, and the description conveys what the tool returns (an app list plus inference profiles) and why that matters before supplier selection. For a six-parameter, all-optional read tool, this is sufficient, with only return-shape details 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?

Schema description coverage is 100% with 6 well-documented parameters, so the schema carries the semantics. The description alludes to target app ID, protocol and configuration variant but adds no syntax, defaults, or interaction rules beyond what the schema already states.

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: 'Read the shared Grandet application list and inference profiles.' It also frames the resource's role (app profiles determine API compatibility), which lets an agent distinguish it from siblings like grandet_find_cheapest_api or grandet_resolve_model, though it never names those siblings.

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?

Gives an explicit gating condition: 'Use only when the target app ID, supported protocol or configuration variant is uncertain,' which doubles as a when-not-to-use signal. It stops short of naming which alternative to use when confidence is already high.

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 establish readOnly, idempotent, non-destructive behavior, so the bar is lowered. The description still adds real value beyond them: it warns that a missing row on one page is not proof of absence, tells the agent to paginate, and states the tool neither tests model quality nor spends money. That is genuine operational context, though it omits anything about return shape or when clarification is triggered (the latter is only implied by the schema).

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?

Four short sentences, front-loaded with the core operation, then usage constraint, pagination caveat, and scope exclusion. Every sentence carries distinct information with no repetition of the title or schema.

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 read-only inspection tool with no output schema but a rich 12-parameter input schema, the description covers purpose, usage boundaries, and pagination caveats adequately. It does not describe what a returned declaration row looks like, but the paged nature and clarification behavior are at least gestured at.

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% with 12 well-documented parameters, so the schema carries the semantic load and a 3 is the baseline. The description only echoes 'model and optional rowId' and adds no format, precedence, or interaction detail beyond what the schema already states.

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, scoped to a model and optional rowId. This is clearly distinguishable from the sibling tools (find_cheapest_api, find_free_credits, resolve_model), though it never names them explicitly. The scope of the operation is unambiguous.

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?

Gives explicit when-to-use ('Use only when a detail matters') and when-not-to-use ('not before every recommendation') guidance, plus operational advice to follow pagination rather than treating a missing row as absence. It stops short of naming a specific alternative sibling to use instead for other intents, so it falls short of a 5.

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 adds genuinely new behavior: the result is a paginated page of candidates rather than a ranked list, and substitution across model generations is disallowed. It does not mention rate limits or result size caps, but the added context is meaningful.

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 lookup purpose, then the scope caveat, then the matching rule. No sentence is redundant and none repeats structured fields verbatim.

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 correctly compensates by describing the return shape ('a page of candidates') and the matching expectation for consumers. It does not cover how ambiguity is reported or how many candidates a page holds, which leaves a small gap for an ambiguous-name resolution 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 description coverage is 100% with 7 well-documented parameters, so the schema already carries the parameter burden. The description adds only a light notion of 'name' ambiguity and paginated candidates, which the schema's own 'page' description largely covers. 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 states a specific verb and resource ('look up public model identifiers') plus the trigger condition ('when a requested name is ambiguous'). It also distinguishes itself from the sibling grandet_find_cheapest_api by explicitly disclaiming that role ('Results are a page of candidates, not a cheapest-provider ranking').

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 a clear when-to-use condition (ambiguous name lookup) and a disambiguation instruction ('Prefer an exact officialId match; do not silently substitute a different model generation'). It implies the boundary against the cheapest-provider sibling but never names it, so routing is inferable rather than explicit.

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