@aiwerk/mcp-server-wheel-size
Server Quality Checklist
Latest release: v0.3.3
- Disambiguation4/5
The tools are organized into clear categories (list-*, search-*, classified) with distinct purposes. Most tools are easily distinguishable, though a few like list-classified-rims and search-classified-rims could cause confusion due to similar names and overlapping descriptions.
Naming Consistency4/5The vast majority follow a consistent lowercase-hyphenated verb_noun pattern (list-*, search-*). Minor deviations like wheel-upsteps and wheel-spec-metadata break the pattern slightly, but they are still intuitive and readable.
Tool Count2/5With 32 tools, the server is over the 25-tool threshold. While the domain is complex, the high number of granular list-* tools could likely be consolidated into fewer, more flexible tools without losing functionality.
Completeness4/5The tool surface covers the full lifecycle of wheel/tire fitment queries: reference data enumeration, vehicle-specific lookups, reverse searches by rim/tire, upsizing suggestions, and aftermarket product searches. Minor gaps exist, such as no direct search by generation, but these are workable.
Average 4.1/5 across 32 of 32 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, providing the core safety profile. The description adds no further behavioral context such as pagination, rate limits, result shape, or external data dependencies. It goes beyond annotations only by clarifying the vehicle compatibility scope, but that is more purpose than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action and scope. It efficiently lists required and optional parameters, though the list is long and could be better structured. Overall it is concise and earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should ideally convey return value expectations or pagination behavior; it does not. However, it clearly covers the tool's purpose and required inputs, which is adequate for a search tool with 17 parameters, but lacks completeness around response format and operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 only restates the required/optional parameters without adding new semantic details; all meaningful parameter explanations are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds aftermarket rim products compatible with a specific vehicle make/model/generation, which is a specific verb+resource+scope. It implicitly differentiates from sibling search-modifications-by-rim by requiring vehicle details (make/model/generation) plus rim specs, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required and optional parameters, implying the tool should be used when those details are available for a vehicle-specific rim search. However, it does not provide explicit when-to-use versus when-not-to-use guidance or name alternative sibling tools for other search scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat safety information. It adds the scoping detail that results are 'aftermarket tyre products' and that it returns listings matching the size, which is helpful but not deep. No contradictory information is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, and efficiently covers required and optional parameters alongside return type. No wasted words or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with fully documented inputs, but there is no output schema, and the description only says 'Returns tyre product listings' without describing the return fields or pagination behavior. It also omits the 'classified' aspect from the name, leaving some ambiguity relative to sibling tools. Adequate for a straightforward search but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a detailed description including units, examples, and constraints. The description merely restates which parameters are required/optional, adding no additional semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and resource ('aftermarket tyre products'), with a specific scope (by tyre size specification). It does not explicitly differentiate from sibling tools like 'search-by-tire' or 'search-modifications-by-tire', but the resource and required parameters make its purpose understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs to find aftermarket tires based on size dimensions, as it lists required and optional parameters. However, it provides no explicit guidance on when to choose this tool over related search tools (e.g., 'search-classified-packages' or 'search-by-tire'), nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the read-only nature. The description adds that the tool requires vehicle make/model/generation and optional tolerance/fitment parameters, but it does not explain how compatibility is determined, what openWorldHint means, or potential edge cases. This adds some context but lacks deeper behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core purpose, then listing requirements and usage. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 19 parameters and no output schema, the description covers the primary purpose and required parameters but omits return format, pagination behavior, and explanation of openWorldHint. It is minimally viable but leaves notable gaps for a high-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, every parameter is already well-documented in the schema. The description merely lists the required parameters and points to search-classified-packages for optional ones, which does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find wheel+tyre package products compatible with a specific vehicle make/model/generation,' which pairs a specific verb with a defined resource and scoping criteria. It distinguishes this tool from siblings like search-modifications-by-rim or search-by-rim by focusing on wheel+tyre packages and requiring vehicle identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit usage context: 'Use when you need to verify package compatibility for a particular trim level.' It also references search-classified-packages for optional parameter meanings, which is helpful. However, it does not explicitly state when not to use it or name alternatives for vehicle-less or single-component searches, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds value by emphasizing that section_width is in INCHES (a notable unit difference from standard by_tire tools), but it does not disclose other behaviors like pagination mechanics, error handling, or return format beyond what the schema and annotations imply. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one purpose sentence plus a quick-reference list of required/optional parameters. It is front-loaded with the key action and resource. The required/optional list is slightly redundant with the schema but serves as a convenient summary without being verbose or rambling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters and no output schema, the description provides the essential purpose and input requirements. It does not explain the return payload or pagination defaults, but limit/offset semantics are in the schema. The phrase 'specific trim variants' gives a basic expectation of results. It is sufficient for a well-utilized search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters already having useful descriptions (e.g., slugs from list-makes, units, constraints). The description repeats the required/optional split and the INCHES note but adds no new information beyond the schema, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Find') and a clear resource ('specific trim variants of a known make+model') that is uniquely tied to an HF tyre size. This distinguishes it from siblings like search-by-hf-tire (which likely does not require make/model) and search-modifications-by-tire (which may use standard metric units).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists the five required parameters and three optional ones, giving clear invocation context. It does not explicitly name alternative tools or state when not to use this tool, but the 'known make+model' prerequisite strongly implies the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-world assumptions. The description adds that it returns 'rim product listings with SKU data' and notes fitment tolerances, but does not disclose behavioral details like default sort or pagination beyond what the schema already provides. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the main action and then systematically lists required and optional parameters. There is no wasted language; every part contributes to understanding what the tool does and what to pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters and no output schema, the description names all required and optional inputs and states the high-level return type. It does not differentiate from the sibling search-classified-rims tool or clarify the 'classified' aspect, but given the rich schema and overall clarity, it is largely complete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already fully documented. The description adds a high-level summary of required vs optional and groups tolerance parameters, but this is a redundant overview rather than new semantic meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('aftermarket rim products'), scoped by 'compatible with a given rim fitment spec.' It distinguishes itself from sibling list tools that enumerate individual parameters (e.g., list-rim-diameters, list-rim-bolt-patterns) by focusing on product listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists required and optional parameters, making it clear the tool is used when a fitment spec is known and compatible rim products are needed. It does not mention alternatives or when not to use it, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be safe. The description adds that results are in inches and that it helps discover validation values, but it does not disclose potential pagination, ordering, or other runtime behavior. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first declares the action and filters, the second gives the primary use case. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered list tool with no output schema, the description adequately covers its purpose, filters, and the reason to call it. It doesn't explain the return format, but for a discovery tool returning rim diameters, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all parameters with detailed explanations, units, and cross-references (e.g., region codes from list-regions, section width units). The description adds no new parameter information beyond what the schema already provides, so baseline 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists all rim diameters available for HF tyres, with optional filters. It clearly distinguishes from sibling tools like list-rim-diameters and list-tire-rim-diameters by specifying 'HF tyres' and also names a downstream use case (search-by-hf-tire).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool to discover valid rim_diameter values for search-by-hf-tire, providing a clear context. It does not enumerate alternatives or when not to use, but the HF-type specificity and optional filters imply its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat safety. It adds scoping context ('given make/model/year/generation') and clarifies the returned data type ('trim/engine modifications'), but discloses no additional behaviors such as pagination or ordering. This is a reasonable level of added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with the main verb, and no redundant or generic phrasing. Every word contributes to the tool's purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list tool: it states the resource, the required input parameters, and a workflow hint. It does not explain return value structure or error conditions, but these are less critical given the tool is a read-only list with fully described parameters and annotations. Missing explicit sibling differentiation in the workflow context slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, each with a clear description and examples. The description itself adds minimal parameter-level meaning beyond indicating that they collectively identify a vehicle generation. Baseline 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource+scope: 'List all trim/engine modifications for a given make/model/year/generation.' This precisely distinguishes it from sibling list tools like list-makes or list-models, which return different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for drilling into specific engine variants before querying fitment data' provides clear context for when to use this tool, but it does not explicitly name alternatives or exclusions. This is clear context without a full when/when-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds limited behavioral context beyond that: the unit (inches), the 'all' scope, and the optional filters. It doesn't mention return format, pagination, or edge cases (e.g., no results), but with annotations covering safety, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence front-loads the action and scope; the second gives a directed usage hint. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description covers the necessary elements: what it lists (rim diameters in inches), optional filters, and usage context. It doesn't elaborate on return structure, but given the tool's simplicity and sibling relationships, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are described in detail (region codes, bolt pattern format). The description confirms they are optional filters but does not add new semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all rim diameters in inches, distinguishing it from sibling tools like list-rim-widths and list-rim-bolt-patterns by naming the specific resource (rim diameters) and unit (inches). It also frames the use case around discovering valid values for search-by-rim, which reinforces its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use it to discover valid rim_diameter values before calling search-by-rim, providing a concrete use case and relationship to a downstream tool. It doesn't explicitly contrast with alternatives like list-rim-widths, but the guidance is clear enough for an agent to know when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results are in inches and are filtered by compatibility with section width and aspect ratio. However, it does not disclose behavior such as what happens with missing parameters (all are optional in the schema) or the structure of the returned list, leaving some gaps for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action ('List all rim diameters'), and every clause adds value—the compatibility condition and the reference to search-by-tire justify its inclusion. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description still communicates the unit (inches) and the compatibility concept. It references related enumeration tools ('Get codes from list-regions') via the schema, not the description, but the description's purpose is sufficiently complete for a mildly complex list tool. It could mention the optional nature of parameters or more detail on the output format, but the description is reasonably complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the schema carries the bulk of parameter meaning. The description adds only that section width and aspect ratio are inputs used for compatibility, but does not elaborate on region (which is omitted from the description entirely) or value formats beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List') and clearly defines the resource: 'all rim diameters (in inches) compatible with a given tyre section width and aspect ratio.' It also explains its downstream purpose ('discover valid rim_diameter values for search-by-tire'), which disambiguates it from sibling tools like list-rim-diameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear usage context: 'Use this to discover valid rim_diameter values for search-by-tire.' It implies when to use the tool (when needing compatible rim diameters for a tire size) but does not explicitly exclude alternatives or contrast with similar tools like list-rim-diameters or list-hf-tire-rim-diameters, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds the behavioral context that the tool returns all available years and that these values serve as inputs to other tools, which is useful. However, there is no extra detail on pagination, rate limits, or data format, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second explains downstream usage. It is front-loaded with the primary action and contains no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one well-documented parameter and no output schema, the description provides the essential context: what it returns (all model years) and how to use the results. It lacks explicit return-format details, but the tool's simplicity makes this a minor gap. Overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'make' parameter, including examples and a pointer to list-makes for valid slugs. The description only says 'given a manufacturer,' which adds no meaningful semantics beyond the schema. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all model years for a given manufacturer, using a specific verb ('List') and resource ('model years'). It distinguishes itself from sibling list-* tools by its focus on years and explicitly ties its output to downstream tools (list-models, list-generations, search-by-model).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool's output ('Use the year values returned here as the "year" input') for three specific sibling tools, which provides clear context on when to invoke this tool. It does not explicitly state exclusions or alternative approaches, but the downstream usage guidance is strong for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only behavior is known. The description adds scope context ('For pickup trucks and off-road vehicles') but does not disclose additional behavioral traits such as pagination semantics, potential partial matches, or how open-world results should be interpreted. It neither contradicts annotations nor enriches them substantially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences that front-load the core purpose, then provide the required format and parameter split. Every sentence earns its place, with no fluff or repetition of schema details. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with well-documented schema parameters and no output schema, the description is almost complete. It explains the HF size notation, required fields, and optional params. It could mention that results are vehicle compatibility matches, but the purpose statement already implies this. The lack of return-value details is acceptable given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a detailed description including units, requiredness, and examples. The description reinforces the unit warning and format, but adds no semantics beyond what the schema already provides. Per the rubric, baseline 3 is appropriate when schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all vehicles compatible with a given high-flotation (HF) tyre size.' It also specifies the exact input format (OD x SW R RD) and explicitly differentiates from standard tire searches by emphasizing inch-based section width, making it distinguishable from sibling tools like search-by-tire.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context: it's intended for pickup trucks and off-road vehicles, and it clearly indicates required vs optional parameters. It also warns about the unit difference ('INCHES, not mm!'), which implicitly distinguishes from standard by_tire tools, though it doesn't explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that it returns product listings with SKU and compatibility data, which is useful behavioral context. However, it does not disclose other behavioral traits such as pagination defaults, result ordering, or what happens when no matches are found, so it only partially contributes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and followed by a compact parameter list and return summary. Every sentence earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 16 parameters, the description does a good job of covering the essential context: what the tool does, what parameters are required/optional, and what it returns. The lack of an output schema is partially mitigated by the return description. It could be more complete by explaining the fitment compatibility logic or default behaviors, but given the rich schema and annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 groups parameters into required and optional lists and adds units, but the schema already describes each parameter in detail. The description adds marginal value by summarizing the parameter categories but does not introduce meanings beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds aftermarket wheel+tyre package products (rim+tyre combos sold together) compatible with a given fitment spec. The verb 'Find' plus the specific resource ('wheel+tyre package products') and scope ('compatible with a given fitment spec') precisely define the tool's purpose and distinguish it from siblings like search-classified-rims and search-classified-tires.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the tool as searching for wheel+tyre packages, which implicitly differentiates it from rim-only or tire-only search tools. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds useful context about the imperial size format, 'all' scope, and optional region filtering, though it does not detail return shape or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the core action front-loaded. The imperial format explanation is relevant, and the use-case sentence is direct. The bit about pickup trucks and off-road vehicles is slightly extra but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one well-documented optional parameter and no output schema, the description covers purpose, units, optional filter, and downstream use. It could be more explicit about the return format, but this is a minor gap given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the region parameter is described as 'Market region code (e.g. "usdm", "eudm"). Get codes from list-regions.' The description adds only 'optionally filtered', which is already inferable from the parameter being optional, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all overall diameter values (inches) for high-flotation (HF) tyres, optionally filtered by region' with a specific verb, resource, units, and optional scope. The HF qualifier clearly distinguishes it from sibling tools like list-rim-diameters and list-hf-tire-rim-diameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover valid overall_diameter values for search-by-hf-tire', giving a clear downstream use case. However, it does not mention exclusions or directly compare to related list tools beyond the implicit naming distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds that the return value is a slug used as input elsewhere, which is helpful context but not a deep behavioral disclosure (e.g., no mention of pagination, ordering, or potential variations). This meets the minimum bar but does not exceed it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero redundancy. The first sentence states the action and inputs; the second explains the output's usage. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with strong schema coverage and annotations, the description is sufficient. It clarifies the output (slugs) and downstream consumers, making the tool's role in the broader API clear. No output schema is needed given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'make' and 'year' parameters fully described including examples and how to obtain valid values. The description itself only restates the parameters ('for a given make and year') without adding new semantic 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('vehicle models for a given make and year'), and explicitly distinguishes from siblings by noting the slugs are used as the 'model' input for other tools. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need model slugs for a specific make and year, especially before using list-generations, list-modifications, or search-by-model. It does not explicitly state exclusions but contextualizes its place among sibling tools effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations convey read-only and open-world. Description adds behavioral context: returns vehicle compatibility info, focuses on fitment spec search. This extends beyond annotations, though no rate-limit or pagination notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loaded purpose. Minor redundancy with schema in listing params, but overall efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-param tool with no output schema, description covers purpose, differentiator, and parameter categories. Could include an example or default behaviors, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description only restates required/optional param names, adding no new semantics beyond schema. Thus no uplift.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Search aftermarket rim products by fitment spec'. Explicitly distinguishes from sibling: 'Similar to list-classified-rims but includes vehicle-fitment matching.' This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Names alternative tool (list-classified-rims) and explains the difference (vehicle-fitment matching). Lists required parameters, but no explicit exclusion of when not to use. That said, the sibling comparison is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds behavioral context: it returns 'all body generations' (no filtering) and provides an example slug format ('b9'), which is helpful for understanding the output without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence states the primary purpose, and the second explains the output format and downstream usage. No filler, redundant information, or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, return format with an example, and downstream consumers. For a read-only list tool without an output schema, it provides sufficient context. It does not mention edge cases like no matching generations, but the overall scope is adequate given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully descriptive (100% coverage), with each parameter explaining how to obtain valid slugs. The description adds an example generation slug but does not add per-parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all body generations for a given make/model/year combination' with a specific verb ('List'), resource ('body generations'), and scope. It also distinguishes itself from sibling tools by explaining the output are generation slugs used as input for downstream tools like list-modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: it returns generation slugs needed for list-modifications and classified tools. It does not explicitly list alternatives or exclusions, but the downstream usage makes the purpose evident among many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows it's safe. The description adds important behavioral context: the unit is inches (not mm), which is a known quirk for HF tyres, and clarifies the filtering options. It also states it lists 'all' section widths, though it doesn't describe return format or any pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function and filters, the second provides a critical unit caveat. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with thorough schema descriptions, the description covers the purpose, unit quirk, and optional filters. It doesn't explicitly state the return format or whether the list is exhaustive, but with good annotations and schema, this is adequate. A minor gap is not indicating the output structure (e.g., list of numbers).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameter descriptions in the schema are detailed and self-sufficient (100% coverage). The description adds no additional parameter-specific semantics beyond the schema; the unit note applies to the output value, not the parameters. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource and scope: 'all section widths (in inches) for HF tyres, optionally filtered by overall diameter and region.' It explicitly distinguishes from standard tyre tools by noting the unit difference, which differentiates it from sibling list-tire-section-widths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage context: this is for HF tyres and mentions the optional filters. The note 'unlike standard tyre tools where it is in mm' signals that this tool is the HF-specific variant when working with HF tyre sizes. However, it doesn't explicitly name the alternative sibling tool or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds the exact bolt pattern format (stud-count × circle-diameter in mm), the optional-filter behavior, and its role as a discovery tool. This provides useful context beyond the annotations without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence states function and optional filters; second clarifies format and use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and helpful annotations, the description covers purpose, value format, and primary use case. It doesn't mention return shape details or filter combination semantics, but the schema and annotations cover most needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters are fully documented in the schema with units, constraints, and guidance. The description only mentions 'rim dimensions and centre bore range' at a high level, so it adds no parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all bolt patterns (PCD) in the database, optionally filtered. It specifies the output format with an example and explicitly distinguishes itself from sibling list tools by focusing on bolt patterns and linking to search-by-rim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using this tool to discover valid bolt_pattern values before calling search-by-rim, giving a clear when-to-use. It doesn't provide explicit when-not-to-use guidance, but the named alternative and sibling context suffice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds behavioral context by explaining it lists all 'available' CB values, describes the filtering semantics, and defines what CB is. It does not contradict annotations, though it omits details like result format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no fluff. Every sentence adds value: the first states the function and filters, the second explains the metric and its downstream use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers purpose, filter options, the definition of CB, and the intended usage scenario. Parameter details are handled by the rich schema. A slight gap is the lack of return format, but for a simple list tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already having a detailed description. The tool description only groups filters conceptually ('rim dimensions, offset range, bolt pattern') without adding syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all centre bore (CB) values available, optionally filtered by rim dimensions, offset range, and bolt pattern' – a clear verb+resource with scope. It also explicitly distinguishes the tool by saying 'Use this to discover valid cb values for search-by-rim', differentiating it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage directive: 'Use this to discover valid cb values for search-by-rim'. It does not explicitly mention when to avoid alternatives or compare to sibling tools, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds behavioral context by explaining the meaning of offset values (positive = hub-centric, negative = deep dish) and the available filters, going beyond annotation-provided facts without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the operation and filters, the second defines the key term. There is no wasted language, and the most actionable information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with no required parameters and no output schema, the description adequately covers purpose, filters, and domain terminology. It could explicitly state the return format (e.g., a list of numbers), but the context is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters have detailed descriptions. The tool description merely references rim diameter, width, and bolt pattern without adding new meaning; the schema already explains each parameter's type, format, and constraints. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all rim offset (ET) values available' with optional filters. It distinguishes from sibling list tools (e.g., diameters, widths, bolt patterns) by explicitly focusing on rim offsets and providing a domain-specific definition of ET.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this to discover valid rim_offset values.' It also implies filters for other attributes, but does not explicitly name alternatives or when-not-to-use cases, though the sibling tools are evident from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, lowering the bar. The description adds useful context: results in inches, optional filtering, and its role in the search flow. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences: the first delivers the core function and filter options, the second provides actionable workflow guidance. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional parameters and no output schema, the description is proportionate and covers purpose, filters, and usage. The lack of output format detail is acceptable given the tool's simplicity and the annotations covering read-only/open-world semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have rich descriptions in the schema (units, examples, constraints), so schema coverage is 100%. The tool description only summarizes that filters are optional, adding no new parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all rim widths (in inches) available' with optional filters. It also ties the tool to a specific workflow ('discover valid rim_width values for search-by-rim'), which distinguishes it from sibling list tools like list-rim-diameters and list-rim-bolt-patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover valid rim_width values for search-by-rim,' giving a clear when-to-use context. However, it does not explicitly mention alternatives or when not to use the tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds contextual details about filtering behavior and the formula for aspect ratio. No contradiction; provides value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, and every sentence earns its place—no fluff or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, it covers purpose, filtering, and usage context. Does not describe response format but that remains predictable for a list utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have detailed descriptions with examples and sibling references. The description does not add further param semantics beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specifically states it lists all tyre aspect ratios with optional filters, distinguishing it from sibling list tools. Includes a clear definition of aspect ratio with an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case: 'Use this to discover valid aspect_ratio values for search-by-tire' and points to list-regions/list-tire-section-widths for parameter enumeration. Lacks explicit exclusion of alternatives but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful behavioral context by enumerating the exact return fields (tyre size, rim spec, PCD, CB, OEM/aftermarket) and clarifying the empty-data-array edge case, which is not an error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with clear front-loading: purpose first, then return format, then edge-case clarification. Every sentence carries meaningful content with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with no output schema, the description sufficiently covers output fields and edge-case behavior. The detailed parameter schema complements it well. Minor omission is lack of pagination/limit info, but it's not a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions provide 100% coverage with rich detail—examples, slugs, and cross-references to list tools. The tool description itself adds no extra param-level semantics beyond restating the inputs, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and resource ('wheel/tyre fitment specs'), and specifies exact inputs (make, model, year, region). It also declares itself 'the primary tool for fitment lookups,' distinguishing it from siblings like search-by-rim and search-by-tire.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly positions the tool as the primary fitment lookup, implying it should be used when vehicle details are known. It does not explicitly name alternatives or when-not conditions, but the sibling context and the phrase 'primary tool' provide clear enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful behavioral context by clarifying that it is a reverse lookup and that results are vehicle make/model/year/trim combinations. It does not describe edge cases, ordering, or completeness, but with annotations present, the added value is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, each earning its place: purpose, example, parameter list, and output shape. It is front-loaded with the primary purpose and uses no filler. The structure makes it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 6-parameter schema with full descriptions and no output schema, the description covers the essential return shape (vehicle combinations) and parameter grouping. It does not detail pagination, sorting, or the meaning of openWorldHint, but those are secondary. Overall, it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is already explained. The description consolidates the three core parameters as a tyre size (section_width, aspect_ratio, rim_diameter) and gives a concrete example, which is helpful. However, it does not add meaning beyond the schema's own descriptions; it mostly restates what is already there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Find all vehicles compatible with a given standard tyre size.' It explicitly calls this a 'Reverse lookup' and gives a concrete example ('which cars fit 245/45R18?'), immediately distinguishing it from sibling tools like search-by-model, search-by-rim, and search-by-hf-tire. The output (vehicle make/model/year/trim) is also stated, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the intended use case (reverse lookup of vehicles by tyre size) and lists required vs optional parameters. It does not explicitly mention when not to use this tool or name alternative tools, but the context is strong enough that an agent would understand when to choose this over siblings. The example further clarifies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no additional behavioral details such as pagination, return format, or rate limits, which is acceptable given the annotation coverage but adds no extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core purpose front-loaded in the first sentence and usage context in the second. Every sentence serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 18-parameter search tool, the description provides a clear high-level purpose and when-to-use instructions. However, without an output schema, it does not describe what the results contain, which would enhance completeness but is not critical for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all 18 parameters, including examples and constraints. The description only restates required parameters and optional categories, adding no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it finds specific trim/modification variants for a known make+model compatible with a given rim spec, using the specific verb 'Find'. It clearly distinguishes from the sibling 'search-by-rim' by noting it is 'More granular than search-by-rim'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct when-to-use guidance: 'Use when you already know the vehicle and want to check trim-level fitment.' It also names the closest alternative, 'search-by-rim', with a comparative relationship, making the choice clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is established. The description adds useful context by indicating the tool returns 'specific trim/modification variants' and that it is 'more granular' than the sibling, giving the agent a sense of output specificity without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences: purpose, required/optional params, and usage guidance. Each sentence earns its place, and the most important information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers the core purpose, required/optional inputs, and usage context. It does not describe result format or pagination details, but this is partially mitigated by schema descriptions and the simple search tool nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add param explanations. The description simply restates the required parameters with units (e.g., 'section_width (mm)') without adding semantics beyond the schema, which meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find'), a clear resource ('specific trim/modification variants'), and a precise scope ('of a known make+model compatible with a given tyre size'). It also differentiates from siblings by noting 'More granular than search-by-tire', which helps distinguish it from closely related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context ('Use when you already know the vehicle') and names an alternative tool ('More granular than search-by-tire'). It does not explicitly state when not to use this tool or mention other alternatives like search-modifications-by-rim, but the guidance is sufficient for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that suggestions maintain overall tyre diameter within 'acceptable tolerance' and includes the set of returned fitment terms, which goes beyond the read-only annotation. It does not quantify the tolerance or cover error conditions, but with annotation coverage that's a reasonable level of detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three direct sentences, with the main action and scope in the first sentence and no filler. The usage note is valuable and the fitment-term list is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains both what is returned (fitment terms) and the constraint it satisfies. It is sufficient for an agent to select and invoke the tool, though it lacks details on failure modes or data availability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the schema with examples and constraints, so the 100% coverage baseline applies. The description adds context about region-specific suggestions and key fitment terms, but does not materially extend parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Get aftermarket wheel upsize suggestions', and clarifies scope by naming the returned fitment terms. This clearly differentiates it from sibling list/search tools by focusing on plus-sizing recommendations rather than raw data lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence explicitly says 'Use this to recommend wheel upgrades while preserving speedometer accuracy', providing a clear use case. However, it doesn't name alternatives or explicitly state when not to use it, so it stops short of full differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, so the bar is lower. The description adds valuable behavioral context: make availability varies by region and the same brand may have different slugs across markets. This goes beyond the annotations and helps the agent understand the variability of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the function, scope, and a key behavioral nuance (region-dependency). Every sentence contributes meaning without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema, the lack of an output schema, and the presence of annotations, the description is complete. It explains what the tool does, what it returns (slugs for 'make'), and how results vary by region. This is sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the one parameter 'region', and the schema description provides examples and a pointer to list-regions. The tool description does not add additional parameter details beyond what the schema already offers, so the baseline of 3 applies as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('vehicle manufacturers/makes'). It also specifies the scope ('available in a given market region') and distinguishes itself from sibling list tools by focusing on makes. The additional detail about returning slugs makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it returns slugs used as input for subsequent tools, and emphasizes that make availability is region-dependent. It does not explicitly list alternatives or exclusions, but the practical guidance about using region codes (in the schema) and the tool's role as a prerequisite for other queries is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond annotations, such as the unit (mm) and the optional region filtering, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first states the core function, the second provides a specific use case, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description fully covers what the tool does, the unit of results, the filter option, and a concrete use case. It is complete within its complexity class.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'region' is fully documented in the schema. The description adds only marginal value by mentioning the optional region filter, matching the schema; this is the baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tyre section widths in mm, with an optional region filter. It also distinguishes itself by noting it is for discovering valid section_width values for search-by-tire, setting it apart from sibling list tools like list-tire-aspect-ratios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for use ('Use this to discover valid section_width values for search-by-tire'), which is clear and actionable. However, it does not explicitly mention when not to use this tool or name alternatives, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint and openWorldHint, so the safety profile is already known. The description adds behavioral context by detailing what the tool computes (geometry hints, population stats, optional fitment hints) and that all fields are optional. It does not contradict annotations and adds value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each contributing: purpose, optionality, precise results guidance, return payload, and use cases. No fluff or repetition; front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 optional parameters and no output schema, the description explains what the tool returns (geometry hints, population stats, fitment hints) and when it's useful. The schema handles parameter semantics; the description covers the tool's role and output adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented with meaning and constraints. The description adds only high-level guidance ('Provide as many as known for precise results') and references hints=true but doesn't explain parameters beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get computed geometry and population statistics for a given wheel/tyre specification,' clearly identifying the verb (Get) and resource (computed geometry/population stats). It also enumerates specific return types (backspace, frontspace, clearance estimates, population stats) and optional fitment hints, distinguishing it from sibling list/search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases: 'Useful for explaining fitment math to users or validating a spec before ordering.' It also advises 'Provide as many as known for precise results,' giving parameter usage guidance. However, it does not explicitly name alternatives or state when not to use it, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds value beyond these by disclosing pagination support (limit, offset) and the specific return shape (vehicle make/model/year/trim combinations). This is useful behavioral context and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose, then requirements, options, pagination, and return type. Every sentence earns its place, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 17 parameters and no output schema, the description covers the essential contextual elements: required field, optional filters, range syntax, pagination, and return shape. The schema handles parameter-level details, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage, so the baseline is 3. The description adds meaningful organization by declaring bolt_pattern as required, grouping optional parameters (diameter, width, offset, centre bore, fastener, region), and noting range variants. This helps the agent understand parameter categories beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find all vehicles compatible with a given rim specification.' The phrase 'Reverse lookup: which cars fit these rims?' clarifies the tool's distinct purpose, and the return value specification ('vehicle make/model/year/trim combinations') differentiates it from sibling tools that search modifications or classified listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool (given a rim specification, find compatible vehicles) and what is required (bolt_pattern). It lists optional filters and pagination, giving a clear context. However, it does not explicitly mention any exclusions or alternative tools (e.g., search-by-tire), so it falls just 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds extra context by giving example region codes and noting their role as inputs to other tools. This goes beyond the annotations in a useful way, though it doesn't describe return format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the function with examples, the second gives usage context and directive. No fluff, fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations (readOnlyHint, openWorldHint), and a simple list-only purpose, the description is complete. It even anticipates the user's next step by noting dependent tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't add parameter-specific info because none exist, but it does clarify that the output (region codes) will be used as inputs elsewhere, adding context to the tool's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available market region codes' with specific resource and action. It provides concrete examples (e.g., 'eudm', 'usdm') and distinguishes itself from sibling list-* tools by focusing on regions as a distinct entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that region codes are required inputs for list-makes, search-by-model, and wheel-upsteps, and advises to 'Start here when region is unknown.' This gives clear when-to-use guidance and even names dependent tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIWerk/mcp-server-wheel-size'
If you have feedback or need assistance with the MCP directory API, please join our Discord server