Skip to main content
Glama

Bilkalkylen

Hitta bil efter behov

find_car
Read-onlyIdempotent

Ger en rangordnad shortlist av bilar utifrån behov (budget kr/mån, bagage, räckvidd, drivmedel, märken, mil/år) med total månadskostnad, kostnadsuppdelning och motivering. Använd först när användaren vill ha hjälp att välja bil.

Input Schema

NameRequiredDescriptionDefault
arNo
limitNo
markenNo
milPerArNo
drivmedelNo
prioritetNo
anskaffningNo
minRackviddKmNo
budgetPerManadNo
minLastutrymmeLiterNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this is a safe, idempotent, closed-world read, so the description doesn't need to repeat that. It does add real value beyond the annotations by describing the response shape: a ranked shortlist with total monthly cost, cost breakdown and justification. It omits ranking behavior with default/absent inputs and the meaning of the limit cap.

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 sentences, front-loaded with the capability and its return value, followed by the usage trigger. The parenthetical criteria list is dense but every item earns its place as parameter guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With ten optional parameters, no required fields, no output schema and zero schema descriptions, the definition should say more about how omitted criteria and limit/prioritet affect results. It adequately covers what comes back but leaves enough ambiguity that an agent must guess at default ranking behavior.

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 0%, so the description carries the burden, and it does map roughly six of the ten parameters to plain-language criteria (budget kr/mån, bagage, räckvidd, drivmedel, märken, mil/år). It leaves ar, limit, prioritet and anskaffning unmentioned, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Ger en rangordnad shortlist av bilar') and enumerates the decision criteria it ranks on, so the agent knows exactly what this produces. It does not explicitly differentiate itself from the sibling compare_cars, which is the main gap keeping it below a 5.

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?

'Använd först när användaren vill ha hjälp att välja bil' gives a clear triggering condition and even signals ordering ('först'), implying this precedes downstream tools. It stops short of naming the alternatives (compare_cars, total_cost) or stating 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources