Find available model-range catalogues for Fiat, Lancia, Alfa Romeo, Abarth and commercial vehicles by filtering on sub-make code or catalogue name text.
List catalogues (model ranges). Filter by sub-make (F=Fiat, T=Fiat Commercial, L=Lancia, R=Alfa Romeo, C=Abarth) and/or text in the description.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Sub-make code: F, T, L, R or C | |
| query | No | Text in catalogue/model name, e.g. "PUNTO" |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral load. 'List' plus optional filters makes the read-only, idempotent nature clear, but there is no statement about return volume, ordering, pagination, or whether an empty filter set returns everything — gaps that matter for a catalogue enumeration.
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 compact sentence with the core action front-loaded and the filter semantics following. No filler; the parenthetical gloss and code legend both earn their place, though the phrase 'text in the description' is ambiguous (catalogue description vs. this tool's description).
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, so the description is the only place the return shape could be characterized — yet it never says what a catalogue record contains (code, name, model years?) or how many typically come back. For a simple two-parameter lookup this is adequate but leaves the agent guessing about the response.
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 would be 3, but the description adds genuine value beyond the schema: it decodes the sub-make enum (F=Fiat, T=Fiat Commercial, L=Lancia, R=Alfa Romeo, C=Abarth), which the schema lists only as bare codes. It also reinforces that the two filters are combinable ('and/or').
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 ('List catalogues') and immediately glosses the domain term as '(model ranges)', which an agent can't infer from the name alone. It does not explicitly differentiate itself from near-neighbour siblings like list_groups or list_subgroups, 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?
Usage is only implied: 'Filter by sub-make ... and/or text in the description' tells the agent the filters are optional and combinable, but says nothing about when to choose this tool over list_groups/list_subgroups or what happens when both filters are omitted (presumably a full listing, but that is inference).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.