Skip to main content
Glama
Sign In

SuliHuli EV catalog

by com.sulihuli
OverviewDiscussionsAdmin

Compare EVs side by side

compare_models
Read-onlyIdempotent

Side-by-side comparison of two to four electric vehicles: range (each with its test cycle), charging, battery, price and the other specs, the leading value marked per row, a short verdict, the version each column stands for, sources and cover photo credits. Each model is compared on its named version, and every figure says which version it belongs to. Use it for 'X vs Y' and 'which should I buy' questions; get slugs from search_models first. Returns Markdown with the canonical comparison URL, plus the figures as structured fields.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slugs": "<slugs>"
    },
    "name": "compare_models"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugsYesTwo to four model slugs, e.g. ['tesla-model-3', 'hyundai-ioniq-6'].
slug_aNoShorter two-model form: first model slug (use with slug_b instead of slugs).
slug_bNoSecond model slug (with slug_a).

Output Schema

NameRequiredDescriptionDefault
urlNo
termsNoTerms the data is given under.
modelsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower, yet the description still adds real behavioral context: output is Markdown with a canonical comparison URL plus structured fields, every figure is tagged to a version, and a winner is marked per row. Nothing an agent needs to predict the response shape is missing.

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?

It is a single dense block, front-loaded with the purpose, then use cases, then the return shape. The spec enumeration is long but each item is an actual deliverable, so little seems removable; splitting into shorter sentences would improve scanability 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?

For a read-only comparison tool with 3 parameters, full schema coverage and an output schema, the description supplies the input-source step, the version-attribution rule and the return format. An agent can invoke it correctly on the first try without consulting anything else.

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 parameter docs already carry the baseline. The description goes beyond them by establishing that each column is bound to a named version and that figures are attributed to that version, which is semantic meaning not present in the slug strings.

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 states a specific verb and resource ('side-by-side comparison of two to four electric vehicles') and enumerates what is produced: range with test cycle, charging, battery, price, per-row leader, verdict, version per column, sources and photo credits. An agent can distinguish it from get_model and search_models without opening any 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 names the triggering question shapes ('X vs Y' and 'which should I buy') and gives an explicit prerequisite: obtain slugs from search_models first. It stops short of saying when NOT to use it (e.g. single-model lookups should go to get_model), so it is clear context rather than full routing guidance.

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 toolsInspect
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.

Resources