wheel-size-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.1
Disambiguation3/5
Several tools have overlapping purposes, such as ws_search_by_rim and ws_find_vehicles_for_rim both finding vehicles for a rim, and ws_search_by_tire and ws_find_vehicles_for_tire both finding vehicles by tire size. The detailed descriptions help differentiate the algorithms, but the three parallel families (search, find, check) could still confuse an agent when choosing the right tool.
Naming Consistency4/5
All tools share a ws_ prefix and follow a verb-noun pattern (list_, search_by_, check_, find_). Minor deviations like calculate_upsteps and get_spec_metadata don't break the overall predictability, and the find_ family's use of '_for_' is consistent.
Tool Count3/5
With 21 tools, the set is on the heavy side. Many are specialized variants (HF tire versions, drill-down tools) that could potentially be consolidated, though each does serve a distinct purpose in the wheel/tire fitment domain.
Completeness4/5
The tool set provides thorough coverage of vehicle navigation, fitment searches, direct check tools for specific vehicles, plus/minus sizing calculations, and e-commerce package finding. The only notable gap is the inability to list all modifications for a model without specifying year or generation, but the navigation workflow handles this via ws_list_years.
Average 4.5/5 across 21 of 21 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on July 4, 2026
- 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.json to 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'can be called freely without user initiation' yet the annotation title says 'user-initiated only' – a direct contradiction that misleads the agent about when the tool can be invoked. This is an annotation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and each of its four sentences adds functional detail or usage nuance. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, example usage, parameter tuning, and invocation policy. Combined with an output schema and 100% parameter schema coverage, it is fairly complete, though it does not address edge cases or provide explicit alternatives among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 8 parameters, but the description adds meaningful semantics by explaining the plus/minus concept and specifically advising to tighten do_max for 'without changing the overall diameter' requests, which goes beyond the schema's raw limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Calculate plus/minus sizing alternatives for a wheel/tire combo' – a specific verb and resource. This distinguishes it from sibling search/check tools and effectively communicates the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case ('Given OEM wheel specs...') and provides guidance on parameter tuning ('Tighten do_max...'). It also notes it can be called freely without user initiation, but does not explicitly contrast with sibling tools 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds valuable context about the output shape (tire sizes with generation counts) and the behavior of diameter_range, which goes beyond the raw 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, focused sentences with the main action front-loaded. No fluff, and every sentence adds value: what it does, what it returns, and a usage example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 16 parameters and the presence of an output schema, the description adequately covers the core purpose and output. It explains the key optional behavior (diameter_range) and the primary use case. It lacks explicit mention of required parameters, but those are clearly indicated in the schema, so this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description only highlights diameter_range, but the schema already explains it ('Widen rim diameter search ±N inches'). This meets the baseline but does not add deeper meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Find compatible tire sizes for a given rim specification,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like ws_find_vehicles_for_rim. The return value (tire sizes with generation counts) is also stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Useful for tire product recommendations on wheel product pages,' providing a clear context for when to use it. However, it does not explicitly list alternatives or cases where other tools (e.g., ws_find_vehicles_for_rim) would be more appropriate.
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, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: it matches only tire dimensions and intentionally omits bolt pattern/backspace filtering, which is useful beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by clarifying details and a use-case example. Every sentence adds value without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only search tool, a complete output schema, and full schema parameter coverage, the description is sufficient. It clearly explains the scope and the e-commerce use case, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter carrying its own description. The description adds minimal new parameter semantics—it only reinforces that the three required tire dimensions are the focus. This is adequate but does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Find vehicle generations that use a specific tire size.' It clearly distinguishes itself from sibling tools by noting it is the 'simplest classified search' and that it matches tire dimensions only, with no bolt pattern or backspace filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does 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: when you have a tire size and want to find compatible vehicles. It hints at alternatives by explicitly excluding bolt pattern and backspace filtering, which contrasts with rim-focused sibling tools, though it does not name specific alternatives.
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?
Description mentions return content (slugs and names) but output schema likely covers this. Annotations already declare readOnly and idempotent, so description adds little beyond workflow context; no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded purpose, then alternative and next step; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, optional parameters fully described in schema, output schema present, and annotations covering safety, the description provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so description needn't explain them; it adds workflow context but no param specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all vehicle manufacturers (makes) and returns slugs and names, distinguishing itself from sibling list tools like ws_list_years and ws_list_models by describing its role as a starting point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is a common starting point but not the only one, naming ws_list_years as an alternative entry point, and instructs to use ws_list_models after obtaining a make slug.
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 destructiveHint=false. The description adds non-redundant behavioral context: the result shape (slugs, names, year ranges), the ability to filter by year, and a suggested next step. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the core purpose, then add filtering and next-step guidance. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only catalog tool with a full input schema, output schema, and rich annotations, the description plus schema fully covers when and how to use it. The next-step hint completes the workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions, so the baseline is 3. The description adds a clarifying example for the year filter and emphasizes 'make' but does not materially enhance lang/region semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and object: 'List models for a given make.' It clarifies the output (model slugs, names, production year ranges) and positions the tool within the ws_list_* family, distinguishing it from makes/years/generations endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context with a concrete year-filter example and explicitly recommends downstream tools ('use ws_list_years or ws_list_generations next'). It stops short of describing exclusions or direct alternative list-model tools, but the workflow guidance is strong.
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?
Beyond the readOnly and idempotent hints, the description discloses the prerequisite dependency on a prior search and outlines the return data (per-vehicle rows with OEM wheel specs and fitment deltas). This adds valuable behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded main sentence and a bulleted list of prerequisites. Every sentence earns its place, and the section on what it returns is clear and without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and complexity, the description covers the essential workflow: prerequisites, parent search references, and return data. It does not explain every parameter or pagination, but the 100% schema coverage and output schema fill the gaps. Slight room for more detail on how 'trims' differ from 'modifications' but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds value by instructing the caller to reuse the same rim parameters and tolerances as the parent search, which is not stated in the schema. This ties the many parameters together logically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Drill down into individual trims for a generation from ws_find_vehicles_for_rim.' It identifies the specific verb ('drill down'), the resource ('individual trims for a generation'), and distinguishes itself from the parent search tool by referencing it directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: call ws_find_vehicles_for_rim first to obtain make, model, and generation slugs, and use the same rim parameters and tolerances as the parent search. This gives clear context on when to use the tool, though it does not mention alternatives or exclusions.
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, destructiveHint=false, and idempotentHint=true, which cover the safety profile. The description adds meaningful behavioral context beyond those: it returns 'per-vehicle rows with OEM wheel specs and fitment deltas' and positions the tool as completing the e-commerce chain. This enriches the annotation data without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear one-sentence summary followed by a PREREQUISITES bullet list and a return-value summary. It is appropriately sized for a tool with 21 parameters and a defined workflow, but it could be slightly tighter—some phrasing (e.g., 'Completes the e-commerce chain') is rhetorical rather than purely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and rich annotations present, the description doesn't need to enumerate return fields. It covers the key contextual aspects: prerequisites, parameter inheritance, return content, and the place in the workflow. It might benefit from a brief note on pagination or error conditions, but those are not essential given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that make/model/generation slugs must come from the parent search and that rim/tire parameters and tolerances should be the same as the parent search. This guidance helps the agent correctly populate parameters that would otherwise be ambiguous even with schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Drill down into individual trims for a generation from ws_find_vehicles_for_package,' which clearly identifies the tool's specific verb ('drill down'), resource ('individual trims'), and its relationship to the sibling tool. It also distinguishes it from the parent search tool by describing the downstream step in the fitment workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states prerequisites ('call ws_find_vehicles_for_package first'), tells the user to extract make/model/generation slugs from parent results, and instructs to 'Use the same rim AND tire parameters and tolerances as the parent search.' This gives clear, actionable when-to-use guidance and also implies when not to use the tool (e.g., if the parent hasn't been called or if you lack generation results).
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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by explaining that it 'considers both physical wheel fitment (backspace) and tire size compatibility simultaneously' and suggests using sort='fitment' for closest matches, which goes beyond schema details and provides useful insight into tool 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the first sentence stating the core purpose, the second paragraph adding a key behavioral differentiator and sort tip, and the third providing usage context and an alternative. Every sentence adds value, and the structure is front-loaded, making it easy for an agent to quickly grasp the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 100% parameter description coverage, the description does not need to explain return values or every parameter. It covers purpose, usage context, sibling distinction, and behavior, which is sufficient for an agent to select and invoke the tool correctly. The e-commerce use case and the alternative guidance make it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, so the baseline is 3. The description does not add new parameter semantics beyond what the schema already provides; for instance, the sort='fitment' hint is already described in the schema's sort parameter enumeration. Thus no extra value beyond the schema is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find vehicles compatible with a rim + tire package.' It also distinguishes from siblings by noting it is the 'Most precise classified search' and explicitly contrasts with ws_find_vehicle_modifications_for_package, making the verb+resource+scope specific and non-ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: 'For e-commerce combo/bundle product pages.' and an alternative: 'To drill into a specific generation, use ws_find_vehicle_modifications_for_package.' This clearly tells the agent when to use this tool versus a sibling, satisfying the when/when-not/alternatives criterion.
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, idempotentHint, and destructiveHint. The description adds the concrete output fields (generation slugs, names, platform codes, production spans) and the hierarchical relationship to ws_list_modifications, exceeding the baseline for annotation-covered safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, return values, alternative context, and next step. Front-loaded with the core action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, clear annotations, complete schema, and presence of an output schema, the description covers purpose, return data, usage context, and follow-up action, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on parameter semantics beyond what the schema provides, but it doesn't need to since the schema is explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists generations for a make/model, with specific return values (slugs, names, platform codes, production spans). It distinguishes itself from ws_list_years by noting it's an alternative for models with many generations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use as an alternative to ws_list_years for multi-generational models, and follow up with ws_list_modifications using the generation slug. This gives both when-to-use and workflow 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context such as the ±2.7 hp tolerance for horsepower, the constraint that year or generation is required, and the note that returned slug leads to fitment data. No contradictions 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose, then returns data, constraints, and an example. Every sentence contributes meaningful guidance without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 12 parameters, 2 required, and an output schema, the description covers the essential decision points: what the tool returns, required inputs, filtering options, and the next step. It is sufficient for an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying horsepower filtering ('exact ±2.7 hp' and the min/max relationship), and emphasizing the year/generation requirement. This enriches the agent's understanding of how to combine parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'List modifications (trims) for a specific vehicle.' It clearly states the returned data (trim names, engine specs, production years) and distinguishes itself from sibling ws_search_by_vehicle by pointing to that tool for fitment data after obtaining a slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'One of year or generation is required' and provides a concrete filtering example for horsepower. It also names the next logical tool (ws_search_by_vehicle) for fitment data. It does not explicitly state when not to use the tool compared to other listing tools, but the context 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 readOnly=true, idempotent=true, destructive=false. The description adds valuable context about the return format (slugs and display names) and the fact that it returns 'all' regions, which is not obvious from annotations. It doesn't contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clean sentences: the first states the core purpose, the second explains the output format and usage. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, output schema present, strong annotations), the description is complete. It tells the agent exactly what it returns and how to use it downstream. No significant gaps for a catalog tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. The schema is empty and fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all market regions where vehicles are sold' with a specific verb and resource, and explicitly distinguishes this from sibling list tools by focusing on region slugs and display names. It is unambiguous and helpful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance that region slugs from this tool are used to filter results in other tools, implying when to call it. It doesn't explicitly name alternative tools, but the context of sibling list tools makes the intended usage 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral context by explaining that calling without params yields global data and that it can serve as a navigation root, which is beyond the structured annotations. It does not mention auth or rate limits, but these are not expected given 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs: main purpose, two usage scenarios, and a next-step pointer. Every sentence earns its place, with no filler. The structure is front-loaded with the core function and then provides clear usage instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 optional parameters, an output schema, and safety annotations, the description is complete. It explains both primary invocation modes, and the existing output schema covers the return format. The description, schema, and annotations together provide sufficient context for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some meaning by explaining the 'with make only' pattern and the global no-param case, but it does not elaborate on individual parameters (especially region, which is only in the schema). Since the schema already describes each parameter, the description adds minimal extra semantic value beyond call semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List available years, optionally filtered by make and model.' This clearly states the tool's function and distinguishes it from sibling list tools by focusing on years as the output. It also mentions two distinct call patterns (global and filtered), reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Can be called without params to get all years globally' and 'Can also be called with make only to get years for that brand', framing it as an alternative starting point for navigation. It also directs the user to ws_list_modifications after obtaining a year, indicating next steps in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, lowering the bar, but the description adds meaningful behavioral context: results are broader than the OEM database (any physical fit), and warns that spacers or special bolts/nuts may be required and that rims must be verified against brake calipers and wheel arches. These are non-obvious behaviors not captured by 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized for a complex tool: a clear opening sentence, a contrast with a sibling, return-value summary, usage tip, practical caveat, and a pointer to follow-up tool. Every sentence earns its place, and the front-loading makes it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (16) and the presence of an output schema, the description covers all necessary context: purpose, differentiation from ws_search_by_rim, result contents, real-world usage, safety caveats, and a next-step pointer. The output schema handles return values, so the description's focus on functional context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage with descriptions for all 16 parameters, so the baseline is 3. The description adds only limited extra semantics, such as explaining that fitment deltas (frontspace/backspace) relate to geometric calculations and highlighting sort='fitment', but it doesn't systematically elaborate on required parameters or tolerance options. It does provide some conceptual context (frontspace/backspace) that helps interpret bs_push/fs_poke and rim_bst_to/from, but not enough to push above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Find vehicle generations compatible with a given rim via geometric backspace calculations.' It clearly distinguishes from ws_search_by_rim by explaining the difference between direct 1:1 matching and advanced 2D geometric filtering, and states what the tool returns (make/model/generation, fitment deltas, load capacity). This is unambiguous and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: it contrasts with ws_search_by_rim, describes when this broader fitment search is appropriate, gives a concrete e-commerce use case ('This wheel fits: BMW X5, Audi Q7...'), and directs users to ws_find_vehicle_modifications_for_rim for drilling into a specific generation. Also provides a sort tip ('Use sort='fitment' to put the closest matches first').
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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a meaningful behavioral guardrail with 'only call when a user explicitly requests... Do not call in autonomous loops,' which is not present in annotations. It also clarifies the HF tire sizing convention. It doesn't discuss pagination or auth, but those are covered by schema and 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the purpose, the second paragraph explains the sizing format and points to an alternative, and the final paragraph delivers a critical usage constraint. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema, annotations, and output schema, the description is complete enough. It covers purpose, usage context, size format, alternative tool, and an explicit user-initiated constraint. There is no additional context needed for this read-only search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds value by explaining the HF sizing format ('overall diameter x section width R rim diameter, all in inches') and giving the concrete example 31x10.50R15, which helps the agent understand how the three required parameters relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find vehicles compatible with a high-flotation (LT) tire size.' It clearly distinguishes this tool from ws_search_by_tire by explicitly stating that metric sizes should use the other tool. The reference to trucks, SUVs, and offroad vehicles further contextualizes the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: only when a user explicitly requests a tire compatibility search. It also gives a direct alternative: 'For metric sizes (e.g. 225/45R17) use ws_search_by_tire instead.' It explicitly warns against autonomous loops, which is a clear usage boundary.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it specifies that only ONE region is accepted (unlike other tools), explains the setup values ('symmetric' vs 'staggered'), and notes that year is not required when modification is provided. These details enrich the agent's understanding of the tool's behavior 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening purpose statement, labeled prerequisite sections, and a final usage warning. Every sentence serves a purpose—no fluff. It is longer than average, but the complexity of the tool (10 parameters with conditional dependencies) justifies the length. The front-loaded purpose and clear formatting make it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 2 required, multiple conditional combinations) and the presence of an output schema, the description covers all necessary ground: prerequisites, parameter combination rules, a region limitation, return value highlights (OEM specs, symmetric/staggered), and explicit user-initiation constraint. The presence of an output schema means return values need not be exhaustively described. It is fully 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.
Parameters4/5
Does 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. However, the description adds critical cross-parameter semantics that the schema cannot convey: the required combination of modification OR region, year OR generation (with year skipped when modification is given), and the single-region restriction. This adds significant interpretive value beyond the schema definitions, though individual parameter meaning is already fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Get wheel and tire fitment data for a specific vehicle.' This clearly distinguishes it from sibling tools like ws_search_by_rim and ws_search_by_tire. The title 'Search (user-initiated only)' reinforces the scope of when it should be used, and the description explicitly states its role as a Search method, making 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it details the required parameter combinations (modification OR region, year OR generation, with exceptions), requires prerequisite slugs from list tools, and clearly states 'Do NOT guess these values.' It also gives an explicit exclusion: 'only call when a user explicitly requests fitment information. Do not call in autonomous loops.' This goes beyond simple context and provides clear when-to-use and when-not-to-use guidance, distinguishing it from alternatives.
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, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: it auto-detects the mode based on provided parameters and lists the specific parameter combinations for each mode. This goes beyond the schema and annotations by explaining the tool's operating logic, though it could further detail what computed geometry includes or how hints are derived.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It leads with the purpose, then uses a bulleted list to specify auto-detect modes, followed by usage guidance and a note on free callability. Every sentence adds value, and the formatting improves scannability. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 optional parameters, multiple modes), the description provides complete context: what it computes, how to use it, when to use it, and that it is freely callable. The output schema exists, so return values are documented elsewhere. The description fully compensates for the ambiguity caused by having no required parameters and multiple modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds significant meaning by explaining how parameters interact: rim mode, tire mode, hf_tire mode, and package mode. For example, it clarifies that section_width is in mm for metric tires but inches for HF tires, and that rim_offset is optional. This mode logic is essential for correct invocation and is not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get computed geometry, population stats, and hints for a wheel/tire spec.' This is a specific verb+resource with clear scope. It distinguishes itself from sibling search/check tools by explicitly positioning it as a pre-processing utility, and the auto-detected modes further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use before search or classified calls to understand whether a spec is common or unusual, what tolerances to use, and what to expect.' It also notes it can be called freely without user initiation, which is a clear usage guideline. This is highly actionable and distinguishes it from sibling tools that perform searches or fitment checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral detail: it states the tool does NOT calculate physical fit based on wheel housing geometry, and explains that it relies on direct mapping of existing fitments. This is beyond the annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured: purpose, methodology, parameter usage, then an IMPORTANT usage note, and finally a sibling alternative. Every sentence adds value, though the parameter explanation could be condensed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, an output schema, and detailed annotations, the description covers purpose, methodology, limitations, parameter combinations, and explicit usage constraints. It appropriately leaves return format details to the output schema and achieves a complete picture for this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter descriptions, and the description adds valuable combinatorial semantics: exact values vs. min/max range pairs, with the requirement that 'one of exact or range is required per dimension.' However, this rule is explicitly applied to diameter and width, not clearly extended to offset or centre bore, leaving a minor ambiguity despite the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Find vehicles compatible with given rim specs via direct 1:1 wheel pair matching.' It uses a specific verb ('find'), identifies the resource ('vehicles compatible with rim specs'), and explains the matching method, distinguishing it from other 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'only call when a user explicitly requests a rim compatibility search. Do not call in autonomous loops.' It also names an alternative, ws_find_vehicles_for_rim, for e-commerce contexts, making the when-to-use and when-not-to-use very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the user-initiated-only constraint and warns against autonomous loops, which is behavioral information beyond the annotations' readOnly/idempotent hints. It also describes the response structure (facets and summary) and how to use facets for refinement, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections with a main purpose, response explanation, important usage warning, and alternative tool mention. While it is relatively detailed, each part serves a distinct purpose and provides necessary guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, output schema, sibling alternatives), the description covers the core functionality, response usage, and selection criteria. It adequately orients the agent to when and how to use the tool, and the output schema covers return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 14 parameters with descriptions, so the baseline is 3. The description adds context by specifying that metric sizes are required and by explaining how facet values can be echoed as filters, which complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds vehicles compatible with a given metric tire size, using a specific verb and resource. It explicitly distinguishes from sibling tools like ws_search_by_hf_tire for high-flotation tires, and the title indicates user-initiated search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this is a Search method that should only be called when a user explicitly requests a tire compatibility search, and warns against autonomous calls. It also names the alternative tool for high-flotation tires, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: an empty result means 'no documented fitment,' the year parameter is filtered MCP-side against production ranges with each row echoing its range, and the API has no year parameter. These details go beyond the annotations and help the agent correctly interpret responses and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it states the primary purpose first, then gives an example, then explains empty results and year filtering, and concludes with a usage warning. Every sentence earns its place; no redundant filler. At about 120 words, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, an output schema, and the presence of sibling tools, this description is exceptionally complete. It covers scope (inch-based HF only), edge-case semantics (empty result), year filtering behavior, and the exact alternative tool for metric sizes. The existence of an output schema means return-value details are not required, so the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: it explains the inch-based nature of the tire dimensions, gives a concrete mapping (e.g., '31 for 31x10.50R15'), and details how the year parameter behaves (MCP-side filtering against production ranges). This enriches the parameter definitions enough to earn a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether a high-flotation (LT) tire size fits a specific vehicle.' It includes a concrete example ('do 31x10.50R15 tires fit my 2000 Chevy Blazer?') and explicitly distinguishes from the sibling tool ws_check_tire_fitment_for_vehicle by noting 'Inch-based HF sizes only — for metric sizes use ws_check_tire_fitment_for_vehicle.' This gives clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs alternatives: 'Inch-based HF sizes only — for metric sizes use ws_check_tire_fitment_for_vehicle.' It also provides an important usage constraint: 'only call when a user explicitly requests a fitment check. Do not call in autonomous loops.' This fully clarifies the intended invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: an EMPTY result means no documented fitment, year is filtered MCP-side with each row echoing its production range, and each row is a modification/trim where the rim appears. It adds meaningful context without contradicting the readOnlyHint and idempotentHint 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into short paragraphs, immediately front-loading the core purpose. Every sentence serves a purpose: example, empty-result semantics, year-filter behavior, and usage guidance. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still explains the meaning of results (modifications with fitment, empty result semantics) and edge cases (near-misses due to year). With 12 parameters and several sibling tools, the description is sufficient for an agent to select and call this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that the 'year' parameter is filtered against start_year/end_year and that rows echo the range for near-miss explanation. It also provides a concrete example of how parameters combine, though it does not delve into each parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Check whether specific rims fit a specific vehicle', a specific verb+resource combination, and illustrates with a concrete example question. It distinguishes itself from sibling tools by explicitly recommending this over ws_search_by_rim + ws_search_by_vehicle and from tire fitment tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Prefer this over ws_search_by_rim + ws_search_by_vehicle comparison when the user names a specific vehicle.' It also gives a clear exclusion: 'only call when a user explicitly requests a fitment check. Do not call in autonomous loops.' This provides excellent decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it returns modifications/trims, empty result means no documented fitment, metric sizes only, and the MCP-side year filtering with production range echo. No 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but every sentence earns its place: functional summary, concrete example, return behavior, API caveat, sibling comparison, and a usage warning. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema, the description covers all necessary behavioral aspects: return semantics, empty result interpretation, year filtering logic, and the user-initiated constraint. An agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context beyond the schema, such as explaining that 'year' is filtered MCP-side against production ranges, and clarifying metric size expectations. This meaningfully helps the agent understand parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Check whether a specific tire size fits a specific vehicle (make + model, optionally year)' and gives a concrete example question. It also distinguishes from siblings by recommending this over ws_search_by_tire + ws_search_by_vehicle when the user names a specific vehicle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Prefer this over ws_search_by_tire + ws_search_by_vehicle comparison when the user names a specific vehicle.' It also includes an exclusion: 'only call when a user explicitly requests a fitment check. Do not call in autonomous loops.'
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:

[![wheel-size-mcp MCP server](https://glama.ai/mcp/servers/driveate/wheel-size-mcp/badges/card.svg)](https://glama.ai/mcp/servers/driveate/wheel-size-mcp)

Score Badge

Copy to your README.md:

[![wheel-size-mcp MCP server](https://glama.ai/mcp/servers/driveate/wheel-size-mcp/badges/score.svg)](https://glama.ai/mcp/servers/driveate/wheel-size-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/driveate/wheel-size-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server