Skip to main content
Glama
Sign In

Cambio Uruguay

by io.github.eduair94
OverviewDiscussionsAdmin

Informe del mercado de autos usados

car_market_report
Read-onlyIdempotent

Informe del mercado uruguayo de usados (oferta publicada, no ventas). Secciones: overview (tamaño, precio/año/km medianos, modelos con más oferta), budgets (qué modelos se consiguen con cada presupuesto: pasá budgetUsd), depreciation (cuánto pierde por año cada modelo: pasá model), negotiation (cuántos bajan el precio y cuánto), seller_gaps (automotora vs particular), valuation (cuánto restan los km y suma la caja automática), rotation.

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": "car_market_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelNoModelo para depreciation, p. ej. "Onix" o "Chevrolet Prisma".
sectionNoDefault overview (budgets con budgetUsd, depreciation con model).
budgetUsdNoPresupuesto en dólares para budgets, p. ej. 12000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / budgetUsd / description
      Added value: +"Presupuesto en dólares para budgets, p. ej. 12000."
    • addedInput schema / properties / section / description
      Added value: +"Default overview (budgets con budgetUsd, depreciation con model)."
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds meaningful behavioral context by clarifying that the report reflects published supply, not actual sales, which materially affects interpretation of the data. It does not cover rate limits or output format, but with annotations already handling safety, this is solid.

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?

The purpose and data-source caveat are front-loaded, followed by a compact enumeration of report sections. It is a single dense sentence with some parenthetical clutter, but every section description earns its place by telling the agent what the report contains.

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?

With three optional parameters and no output schema, the description does a good job enumerating the available report sections and their contents. It does not specify the exact return format per section, but it gives enough context for an agent to choose the right section and parameters.

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 100%, and the schema already documents model, section, budgetUsd, and the overview default. The description mostly repeats the same section-to-parameter mapping already present in the schema, so it adds little beyond structured fields.

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?

The description clearly states that it produces a Uruguayan used-car market report based on published supply rather than sales, which is a specific verb/resource/scope. It does not explicitly differentiate itself from siblings such as search_used_cars, car_model_prices, or find_car_opportunities, so it falls short of 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 Guidelines3/5

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

It implies usage by mapping sections to parameters (budgets with budgetUsd, depreciation with model) and stating the default overview, but it never says when to choose this report over alternatives like search_used_cars or car_model_prices. The guidance is implicit rather than explicit.

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

All Cambio Uruguay 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