Skip to main content
Glama
driveate

TiresVote MCP

Official
by driveate
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search

tires_search_advanced
Read-onlyIdempotent

Search the TiresVote catalog for tire models by size, brand, season, and other specs instead of by name, then filter variants to find matching tires.

Instructions

Search tire models by filters instead of a name.

All filters are optional; every list maps to repeated query params (values inside one list are alternatives). Size fields (tire_widths, aspect_ratios, rim_diameters, speed_indices, load_indices, sizes, extra_load, mud_and_snow) constrain ONE variant — a model matches when a single variant satisfies them together; do not combine evidence from different variants. nordic_winter is a model-level attribute. sizes values are OR alternatives, not a required set: for a staggered pair, verify EACH size separately on the chosen model via tires_list_sizes.

Rows add has_modes: for each requested sizes value either the list of matched variant designations or null — a hint for verification, not proof (a null means 'no matched designation recorded', and {} means no sizes were requested). Per-size lists are capped at 8 designations (_truncated_sizes names the affected sizes) — tires_list_sizes returns a model's complete variant list. rating.score is CoreScore, rating.popularity is a separate metric.

Pagination: follow next_page while has_more; upstream caps how deep paging goes — a short listing does not prove absence, and a site_url link is a citation, not a fetch target. Responses cap at ~40 KB serialized (roughly 8–10k tokens) — lower per_page or narrow filters if a page overflows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoAPI page number (>=1). Default 1.
sizesNoFull tire size notations in original spelling, each up to 50 chars (an MCP-side bound), e.g. ['225/45R17'] or a staggered pair ['245/40R19','275/35R19']. Sent as repeated 't' params (at most 20). Multiple values are OR alternatives — a hit for one size does not prove the others exist on the model; verify each size via tires_list_sizes.
brandsNoBrand slugs, e.g. ['michelin']. Resolve via tires_list_brands. Sent as repeated 'b' params (at most 20 — an MCP-side bound).
regionsNoTiresVote market region slugs, e.g. ['eudm']. Resolve via tires_list_regions. Sent as repeated 'reg' params (at most 20 — an MCP-side bound).
seasonsNoSeason slugs: 'summer', 'all' (all-season), 'winter'. Sent as repeated 's' params.
orderingNoSort order, comma-separated without spaces; fields: 'popularity', 'score', 'slug', optional '-' prefix. Upstream default: '-popularity,-score,slug'.
per_pageNoResults per API page (1–20). Default 10.
extra_loadNoVariant attribute: true requires XL variants. Sent as 'xl'.
include_oeNotrue adds OE (original equipment) models to the results (live-verified include flag, sent as 'oe'); false matches omitting it.
tire_widthsNoTire widths in mm, 95–525, e.g. [205, 225]. Sent as repeated 'tw' params (at most 20 — an MCP-side bound). Combined with other size fields on a single variant.
load_indicesNoExact load indices 0–150, e.g. [91, 94] — each value matches exactly, not a minimum rating. Sent as repeated 'li' params (at most 20 — an MCP-side bound).
mud_and_snowNoVariant attribute: true requires M+S variants. Sent as 'ms'.
aspect_ratiosNoAspect ratios in %, 20–95, e.g. [45, 55]. Sent as repeated 'ar' params (at most 20 — an MCP-side bound). Combined with other size fields on a single variant.
nordic_winterNoModel attribute: true keeps models intended for Nordic winter. Sent as 'nw'.
rim_diametersNoRim diameters in whole inches, 10–32, e.g. [17]. Sent as repeated 'rd' params (at most 20 — an MCP-side bound). Combined with other size fields on a single variant.
speed_indicesNoExact speed indices, e.g. ['V','W','Y'] — each value matches exactly, not a minimum rating. Sent as repeated 'si' params (at most 20 — an MCP-side bound).
price_segmentsNoBrand price-segment slugs, e.g. ['premium','mid-range','economy']. Sent as repeated 'ps' params (at most 20 — an MCP-side bound).
runflat_filterNoNeutral RunFlat visibility flag, sent as 'rf' (live-verified): omit to keep the upstream default, which excludes RunFlat-flagged models; true adds RunFlat models; explicit false ALSO returns RunFlat models due to upstream variant matching — it is not an exclusion. For a strictly RunFlat-only list use tires_list_brand_tires(runflat=true).
automobile_typesNoVehicle classes: 'car' and/or 'suv'. Sent as repeated 'at' params.
production_yearsNoModel production start years, 1900–2028, e.g. [2020, 2021]. Sent as repeated 'y' params (at most 20 values — an MCP-side bound).
include_discontinuedNotrue adds discontinued models to the results (live-verified include flag, sent as 'np'); false matches omitting it. Omitted default excludes discontinued models.
performance_categoriesNoPerformance category slugs. Resolve via tires_list_performance_categories. Sent as repeated 'pc' params (at most 20 — an MCP-side bound).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantially more: single-variant constraint semantics, per-size designation caps (8) with a _truncated_sizes flag, the has_modes hint's limits ('hint not proof'), a ~40KB response ceiling, and the counter-intuitive runflat_filter behavior where explicit false still returns RunFlat models. This is real behavioral disclosure beyond structured fields.

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?

Purpose is front-loaded in one sentence, and the remaining dense paragraphs each carry non-obvious semantics an agent would otherwise get wrong. It is long and back-loaded with edge cases, but nearly every clause earns its place; only mild tightening is possible.

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 22-parameter filter tool with variant-level complexity, the description covers aggregation semantics, pagination depth caveats, the citation-vs-fetch distinction for the site_url link, and even interprets output fields (has_modes, rating.score vs popularity) despite an output schema being present. Nothing essential for correct invocation is missing.

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, but the description adds genuine meaning on top: list values are OR alternatives rather than a required set, size fields constrain a single variant jointly, nordic_winter is model-level while extra_load/mud_and_snow are variant-level, and sizes must be verified per size. It also flags that explicit false on runflat is not an exclusion.

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 opening line states a specific verb and resource ('Search tire models') and immediately scopes it ('by filters instead of a name'), which implicitly distinguishes it from the name-based sibling tires_search. An agent can tell the two apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operational context: all filters optional, how repeated params combine, and routes to alternatives for verification (tires_list_sizes for full variant lists, tires_list_brand_tires for strictly RunFlat-only). It stops short of an explicit 'use this when X, use tires_search when Y' statement, which is the only gap.

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

Deploy Server

Other Tools