Skip to main content
Glama
Sign In

CarGene

by com.car-gene
OverviewDiscussionsAdmin

Search vehicles

search_vehicles
Read-onlyIdempotent

Find series by name, maker name, a generation's name, or a generation's chassis code. Series names match by normalized substring (width, case, kana), maker names by prefix, chassis codes by substring of the code as written (a slash-joined code is one string, not split). A generation matched by its name or chassis code is listed in matched_models. Returns {query, total, hits: [{series, maker, matched_models}], next_offset} where each series and model carries its public page url; pass the ids in the hits to the other skills. Hits are ranked and cut to fit the response size; when next_offset is not null, call again with offset set to it for the rest. Empty hits means nothing matched the query.

Input Schema

NameRequiredDescriptionDefault
queryYesSeries name, maker name, or chassis code. Width, case, hiragana/katakana, long vowel marks and hyphens are normalized away before matching.
offsetNoWhere to start in the list; pass next_offset from the previous response. Omit to start from the beginning.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Where to start in the list; pass next_offset from the previous response. Omit to start from the beginning.",
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observed

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/safe profile, and the description adds genuinely new behavior: per-field matching rules (substring for series, prefix for makers, substring for chassis, slash-joined codes treated as one string), ranking plus size-based truncation, pagination semantics, and what empty hits means.

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?

Front-loaded with the core purpose, then matching rules, then return shape and pagination. Every sentence carries information, though the dense run-on block of return-shape detail could be split for readability.

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 no output schema, the description carries the return-value burden and does so fully, specifying the response envelope, the url-per-entity field, ranking/truncation, and next_offset continuation. Nothing needed to call or consume this tool 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 baseline is 3, but the description adds meaning the schema does not: query is interpreted differently depending on whether it is a series name, maker name, or chassis code, and the exact match strategy per type. Offset semantics are left to 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?

States a specific verb (find/search) plus the resource (series, via maker/generation/chassis identifiers) and enumerates exactly which query forms are matched. It also positions itself as the discovery entry point ('pass the ids in the hits to the other skills'), which distinguishes it from detail-oriented siblings like get_vehicle.

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?

Gives clear operational guidance: call again with next_offset when it is non-null, and empty hits means nothing matched. It implies the tool feeds other skills but never explicitly names a sibling to use instead for detail lookups, so it stops short of full when-not/alternative routing.

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

All CarGene 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