SuliHuli EV catalog

Search and rank EVs

search_models

Read-onlyIdempotent

Find electric vehicles by brand or model name, or list the whole catalog ranked for a use case, optionally only those with at least a given range. Use it first whenever you have a name but no slug, and for questions like 'which EVs go furthest' or 'best family EV'. Returns JSON: per model the slug (pass it to get_model or compare_models), brand, name, score out of 100 for the chosen preset (score_tier says whether every input is verified), official range in km with its test cycle (range_km_official + range_cycle: WLTP, EPA, CLTC or NEDC) and the comparable WLTP-equivalent figure, DC charging 10-80 % in minutes, battery kWh, each of these with its source and verification status, markets where it is sold, the number of known versions, the page URL and the cover photo with its credit. Prices are per market and per version: read them with get_model. Paged: total, page, total_pages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_models"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number, 1-based (default 1); see total_pages in the answer.
`limit`	No	Models per page (default 20, at most 50 without an API key).
`query`	No	Words of the brand and/or model name, any order, case-insensitive; every word must match, e.g. 'tesla 3', 'ioniq', 'bmw ix'. Omit to rank the whole catalog.
`preset`	No	What the ranking optimizes for (default everyday): everyday (a balanced daily driver — range, charging and practicality); long_range (maximum distance per charge for road trips); family (space, seats and practicality for a family); performance (acceleration and fast-charging capability); city (a short, easy-to-park car that still charges fast); winter (range that survives the cold — ranked on our own winter estimate).
`min_range_km`	No	Only EVs whose official range is at least this many kilometres on the comparable WLTP-equivalent basis (an EPA or CLTC figure is converted by its cycle factor). For miles, multiply by 1.609.

Output Schema

Name	Required	Description
`hint`	No	Why a page is empty and what to try.
`page`	No
`count`	Yes
`query`	No
`terms`	No	Terms the data is given under.
`total`	No
`models`	Yes
`preset`	No
`per_page`	No
`total_pages`	No
`min_range_km`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the remaining burden is low, and the description still adds real behavior: paging fields (total, page, total_pages), that score_tier signals whether every input is verified, that ranges are normalized to a WLTP-equivalent basis, and that prices are deliberately excluded. It doesn't restate permissions or rate limits (the 50-per-page key limit lives only in the schema), so it stops just short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence and the routing sentence are well front-loaded, but the middle of the description becomes a long comma-chained inventory of return fields, and an output schema already exists that covers most of it. Roughly half the text is enumerating data the structured fields already supply, which dilutes the useful parts.

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?

For a five-parameter, zero-required search tool with full schema coverage, an output schema, and read-only annotations, the description covers selection, ranking semantics, paging and the handoff to get_model/compare_models. The only redundancy is the return-field listing, which is completeness beyond what is needed rather than a gap.

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 purpose-level framing on top — omitting `query` ranks the whole catalog, `preset` is chosen by use case, and `min_range_km` filters on the comparable WLTP-equivalent figure rather than raw official numbers. It doesn't add syntax or format detail beyond the schema, which is the only thing keeping it from a 5.

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?

States a specific verb and resource ("Find electric vehicles by brand or model name, or list the whole catalog ranked for a use case") and implicitly separates itself from get_model/compare_models by noting that the returned slug is what you pass to those tools. An agent can tell exactly what this does versus its siblings without opening the schema.

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?

Gives an explicit routing rule: "Use it first whenever you have a name but no slug," plus example question shapes ('which EVs go furthest', 'best family EV') that match this tool rather than get_category_ranking. It also carves out a boundary — prices are per market/version and must be read with get_model — so the agent knows what not to expect here.

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

All SuliHuli EV catalog tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.