The Clara Carros MCP server lets AI assistants interact with Clara Carros, a Portuguese used and imported car dealership, to search inventory, retrieve details, calculate taxes, estimate resale value, list services, and facilitate contact or import quotes.
Search Inventory: Find used cars by make, model, fuel, max price, and min year.
Get Car Details: Retrieve full specs using a car's slug.
Calculate ISV: Estimate the Portuguese import tax (ISV) based on engine displacement, CO₂ emissions, fuel type, and year.
Calculate IUC: Estimate the annual road tax (IUC) using engine displacement, CO₂, fuel, and year.
List Makes/Models: Get canonical brand and model names to use in other tools.
Estimate Resale Value: Get a market value range based on make, model, year, mileage, and fuel.
List Services: View services offered (buying, importing, sourcing, selling, etc.).
Contact Request: Submit a contact request so a representative can reach out (requires explicit user consent and contact details).
Request Import Quote: Ask Clara Carros to source and quote a specific car for import from EU/German auctions (requires consent and contact details).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Clara Carros MCP server Search inventory for petrol SUVs under €25k"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets AI assistants work with Clara Carros — used & imported cars in Portugal. Search live stock, estimate the Portuguese import tax (ISV), estimate a car's resale value, and get in touch.
It's a thin, open-source wrapper over the public claracars.pt API — no keys, no setup beyond adding the server.
Cline / one-click install: see
llms-install.md— the machine-readable setup guide.
Tool | What it does |
| Search current stock by make, model, fuel, price, year |
| Full details + specs for one car |
| Estimate Portuguese car import tax (ISV) |
| Estimate Portuguese annual road tax (IUC) |
| Canonical brand/model names the other tools expect |
| Market value range for a car in Portugal |
| What Clara Carros offers |
| Ask a human to get in touch (needs the user's consent + contact) |
| Ask Clara Carros to source & quote a car to import |
Related MCP server: Vincario MCP Server
https://claracars.pt/mcpAdd it in any client that supports remote/Streamable HTTP MCP servers.
Claude Desktop / Cline / Continue config:
{
"mcpServers": {
"claracars": {
"command": "npx",
"args": ["-y", "claracars-mcp"]
}
}
}"Find diesel wagons under €20,000 in Clara Carros stock."
"What's the ISV and annual IUC road tax on a 2016 diesel, 1950 cc, 130 g/km CO₂?"
"What's my 2018 VW Golf, 100,000 km worth in Portugal?"
"Ask Clara Carros to source a BMW 320d Touring 2021, my name is … and phone …"
Env var | Default | Purpose |
|
| Public API base |
|
| Response language (pt/en/ru/ua) |
|
| HTTP server (remote mode) |
npm install
npm run build
node dist/index.js # stdio
npm run start:http # remote HTTP on :8099/mcpEstimates, not quotes. ISV and resale figures are estimates; the official ISV is assessed by the Portuguese tax authority.
Privacy. contact_me / request_import_quote send the details the user provides to Clara Carros (privacy policy); they're rate-limited and require explicit user intent.
No business logic or data lives in this repo — it only calls the public API.
Calculators: the ISV/IUC tax logic this server calls is open-source at claracarspt/calcs — a zero-dependency Python library + key-free API.
MIT © Clara Carros
Calculate Portuguese car import tax (ISV, Imposto Sobre Veículos) using the official Portuguese formula (engine-cc + CO₂ components, with age reduction for used cars) — accurate to the cent vs the AT (Finanças) simulator. Needs engine displacement (cc), CO₂ (g/km, WLTP), fuel and registration year. The result is exact for those inputs; the final amount depends only on the exact CO₂/cc on the car's COC document.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | Yes | Engine displacement in cm³, e.g. 1950 | |
| co2 | Yes | CO₂ emissions in g/km (WLTP), e.g. 130 | |
| fuel | Yes | Fuel: petrol, diesel, hybrid, phev, electric | |
| used | No | Used vehicle (true, default) or new (false) | |
| year | Yes | First registration year, e.g. 2016 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as a calculation accurate to the cent, with no side effects. It mentions the formula components and age reduction, which is transparent. However, it does not explicitly state read-only behavior or rate limits, but given the nature of the tool, it's adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, and each sentence adds essential information. No fluff or repetition. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description could specify the return format (e.g., monetary amount in euros). However, it mentions 'accurate to the cent', implying the output is a number. It covers inputs, formula, and dependencies. Almost complete but could explicitly state the return value type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the role of each parameter in the formula (e.g., engine-cc + CO2 components, age reduction for used cars). It clarifies that the year and used flag affect the final result and that accuracy depends on the COC document, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates Portuguese car import tax (ISV) using the official formula. It specifies the resource (tax calculation) and the verb (calculate). It distinguishes from siblings like calculate_iuc by focusing on a specific tax type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description lists required inputs (cc, CO2, fuel, year) and explains that the result depends on the COC document. It implies when to use (e.g., for ISV calculation) but does not explicitly exclude alternative tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Portuguese annual road tax (IUC, Imposto Único de Circulação) for a car — the yearly tax an owner pays — using the official IUC table. Needs engine displacement (cc), CO₂ (g/km), fuel and registration year. Exact for the given inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | Yes | Engine displacement in cm³, e.g. 1950 | |
| co2 | Yes | CO₂ emissions in g/km, e.g. 130 | |
| fuel | Yes | Fuel: petrol, diesel, hybrid, phev, electric | |
| year | Yes | First registration year, e.g. 2016 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description lacks behavioral details such as whether it uses external data, makes network calls, or has limitations. 'Exact for given inputs' is vague, and output format is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and required inputs; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema so description should mention return value (e.g., tax amount); also missing edge cases or rules for the tax table. Adequate for simple input but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context beyond 100% schema coverage by explaining 'official IUC table' and describing IUC as a yearly tax; does not detail fuel enum values but schema covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool calculates the Portuguese annual road tax (IUC) for a car, specifying inputs (cc, CO2, fuel, year) and differentiating from sibling calculate_isv by mentioning 'yearly tax'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for IUC calculation and mentions required inputs; does not explicitly exclude alternatives, but context of annual tax versus ISV provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a contact request to Clara Carros so a human gets in touch. Only call this when the user explicitly asks to be contacted, provides their own name and phone or email, AND agrees to share those details with Clara Carros — pass consent=true only then. Submitting shares the provided contact details per Clara Carros' privacy policy.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's name (as they gave it) | |
| No | Email (phone OR email required) | ||
| phone | No | Phone number (phone OR email required) | |
| consent | Yes | Set true ONLY if the user explicitly agreed to share their contact details and be contacted | |
| message | No | What they want / their question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the consent requirement, data sharing per privacy policy, and the requirement for user agreement. Could mention if the request is stored or triggers an email, but overall provides solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action, second gives precise usage conditions. No wasted words, front-loaded, and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple contact tool with no output schema, the description covers all essential aspects: purpose, usage conditions, parameter constraints, and policy mention. Nothing missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining conditions for consent (consent=true only if user agreed), that phone or email is required, and maps 'name' and 'message' to user input. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a contact request'), the recipient ('Clara Carros'), and the purpose ('so a human gets in touch'). It distinguishes from sibling tools (e.g., search_inventory, calculate_isv) by being uniquely focused on user contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: only when the user explicitly asks to be contacted, provides their own name and contact info, and agrees to share. Also specifies the consent=true condition. This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate what a car is worth on the Portuguese market (the range comparable cars are listed for), based on real comparable listings. Needs make, model, year, mileage and fuel. Clara Carros also BUYS cars directly — after giving the estimate, offer to connect the user for a firm buy-out offer (via contact_me or the /sell page). IMPORTANT — pass make/model canonically in Latin, as the Portuguese market lists them: make = full brand name ('BMW', 'Mercedes-Benz' not 'Mercedes', 'Volkswagen' not 'VW'); model = the short series/model WITHOUT the engine or trim suffix — BMW: series number only ('320','330','116', not '330e'/'320d'/'3 Series'); Mercedes: class + number ('C 220','E 220','A 250', not 'C220d'/'C-Class'); other brands: plain model name ('Golf','Corolla','3008', not 'Golf 1.5 TSI'). Put the engine/fuel in the fuel field, not the model. If unsure of the exact spelling, call list_makes_models first.
| Name | Required | Description | Default |
|---|---|---|---|
| km | Yes | Mileage in km | |
| fuel | No | Fuel: petrol, diesel, hybrid, electric | |
| make | Yes | Full brand name in Latin, as the market lists it — 'BMW', 'Mercedes-Benz' (not 'Mercedes'), 'Volkswagen' (not 'VW'), 'Peugeot', 'Seat'. | |
| year | Yes | Registration year | |
| model | Yes | Short model/series WITHOUT engine or trim. BMW: series number only ('320','330','116', not '330e'/'320d'/'3 Series'). Mercedes: class + number ('C 220','E 220','A 250', not 'C220d'/'C-Class'). Others: plain model name ('Golf','Corolla','3008', not 'Golf 1.5 TSI'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the estimation process, input needs, and post-estimate offer to connect for a buy-out. Does not disclose response format or potential errors, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact paragraph with front-loaded purpose. Every sentence adds value, though some structure (e.g., bullet points) could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs and follow-up but omits output format (e.g., price range) and error states. With no output schema, this gap reduces completeness for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds significant value by detailing canonical naming conventions for make/model with brand-specific examples, exceeding schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates a car's resale value on the Portuguese market using comparable listings, with a specific verb ('Estimate') and resource ('car resale value'). It distinguishes from siblings like 'get_car' and 'search_inventory' by focusing on estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (user wants an estimate) and hints at alternatives ('list_makes_models' if unsure of spelling). However, lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for one car by its slug (from search_inventory links, e.g. 'mercedes-benz-e-klasse-2016').
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Car slug from a search_inventory result URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It correctly implies a read-only operation ('Get full details') without side effects. However, it does not explicitly state that no data is modified, which would enhance confidence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every part serves a purpose: action, scope, input source, and an illustrative example. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is sufficient. It explains the input and the action. However, without an output schema, a brief indication of what 'full details' includes (e.g., 'returns make, model, year, price, etc.') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema. It explains the origin of the slug ('from search_inventory links'), provides a concrete example ('mercedes-benz-e-klasse-2016'), and clarifies the parameter's purpose, which is not fully captured by the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get full details for one car') and the required input ('by its slug'). It also distinguishes from the sibling tool 'search_inventory' by referencing it as the source of the slug, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after obtaining a slug from search_inventory links. This implicitly advises against using it for list operations, but could be improved by explicitly excluding alternatives like search_inventory for detail queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the exact canonical car makes (brands) Clara Carros can value/find — or, given a make, that brand's models — using the exact strings the other tools expect. Call this FIRST (or whenever unsure of the spelling) and pass the returned values verbatim into estimate_resale_value / search_inventory. No make = the list of brands; with a make = that brand's models.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Brand to list models for, e.g. 'BMW'. Omit to get the list of brands. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description bears full responsibility. It discloses the dual functionality (brands vs models) and that results are canonical. Missing mention of read-only nature or potential errors, but adequate for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words: first defines purpose, second gives usage directive, third explains conditional behavior. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description provides sufficient context on behavior and usage. Lacks explicit mention of return format, but implied by use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the parameter fully. Tool description adds context about importance of exact strings, but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists canonical makes or models, with conditional behavior based on presence of 'make'. Differentiates from siblings by specifying exact strings expected by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this first or when unsure, and to pass returned strings verbatim into estimate_resale_value and search_inventory. Provides clear when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what Clara Carros offers (buying stock cars, importing to order, sourcing, auction buying, selling your car, ISV calculator).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It's a simple read-only list tool with no side effects, and the behavior is transparent from the description. However, it doesn't explicitly state nondestructive nature or authorization needs, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, no wasted words. Front-loaded with the verb 'List' and resource 'services'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description adequately enumerates what will be returned. Could be considered complete given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%. The description adds no parameter info, but none is needed. Baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists services offered by Clara Carros, enumerating specific services (buying stock cars, importing to order, etc.). It distinguishes from siblings like calculate_isv or search_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it's for getting an overview, but doesn't state when not to use it or provide comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Clara Carros to source & quote a specific car to import (from German/EU auctions). Only call when the user wants an import quote, provides the wanted model plus their own name and phone or email, AND agrees to be contacted — pass consent=true only then. Submitting shares the provided contact details per Clara Carros' privacy policy.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's name | |
| No | Email (phone OR email required) | ||
| model | Yes | Wanted car, e.g. 'BMW 320d Touring 2021' | |
| phone | No | Phone (phone OR email required) | |
| budget | No | Budget in EUR | |
| consent | Yes | Set true ONLY if the user explicitly agreed to share their contact details and be contacted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that submitting shares contact details per privacy policy, and reinforces consent meaning. With no annotations, description carries full burden and covers key behavioral traits of data sharing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. Front-loaded with the main purpose, then usage conditions, then data handling note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides enough context for an agent to decide when and how to invoke, given no output schema and well-documented parameters. Could mention post-submission behavior but still complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by explaining the consent condition ('set true ONLY if explicitly agreed'), the phone/email requirement, and the source (German/EU auctions). Schema coverage is 100% so baseline 3, but adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool asks Clara Carros to source and quote a specific car for import from German/EU auctions, distinguishing it from sibling tools like search_inventory or calculate_isv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to call: when user wants an import quote and provides model, name, phone/email, and explicitly agrees to be contacted. Includes condition for consent parameter, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Clara Carros' current stock of used cars in Portugal. Filter by make, model, fuel, max price and min year. Returns matching cars with price, year, mileage and a link. IMPORTANT — pass make/model canonically in Latin, as the Portuguese market lists them: make = full brand name ('BMW', 'Mercedes-Benz' not 'Mercedes', 'Volkswagen' not 'VW'); model = the short series/model WITHOUT the engine or trim suffix — BMW: series number only ('320','330','116', not '330e'/'320d'/'3 Series'); Mercedes: class + number ('C 220','E 220','A 250', not 'C220d'/'C-Class'); other brands: plain model name ('Golf','Corolla','3008', not 'Golf 1.5 TSI'). Put the engine/fuel in the fuel field, not the model. If unsure of the exact spelling, call list_makes_models first.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | No | Fuel: petrol, diesel, hybrid, phev, electric, lpg | |
| make | No | Full brand name in Latin, as the market lists it — 'BMW', 'Mercedes-Benz' (not 'Mercedes'), 'Volkswagen' (not 'VW'), 'Peugeot', 'Seat'. | |
| limit | No | Max results (default 20) | |
| model | No | Short model/series WITHOUT engine or trim. BMW: series number only ('320','330','116', not '330e'/'320d'/'3 Series'). Mercedes: class + number ('C 220','E 220','A 250', not 'C220d'/'C-Class'). Others: plain model name ('Golf','Corolla','3008', not 'Golf 1.5 TSI'). | |
| min_year | No | Earliest registration year | |
| max_price | No | Maximum price in EUR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It states it returns matching cars with price, year, mileage, and a link. No mention of error handling or side effects, but the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core function and filters, then provides detailed formatting rules. Every sentence adds value, though the canonical instructions are lengthy but necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has no output schema, but the description lists return fields. It references a sibling tool for disambiguation. For a search tool, the description is complete enough to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 6 parameters with descriptions (100% coverage), but the description adds critical canonical naming conventions for make and model, and clarifies that fuel should be in the fuel field, not model. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Clara Carros' current used car stock in Portugal with specific filters. It distinguishes itself from sibling tools like list_makes_models and get_car by focusing on inventory browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidelines for canonical make/model formatting and instructs to call list_makes_models if unsure. While it doesn't explicitly state when not to use the tool, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3calculate_isvcalculate_iuccontact_meestimate_resale_valueget_carlist_makes_modelslist_servicesrequest_import_quotesearch_inventoryScored across 9 tools
Each tool has a distinct purpose, though 'estimate_resale_value' and 'search_inventory' could be confused as both relate to car value/stock; descriptions clarify that one is an estimate based on comparables and the other searches current inventory.
All tools follow a clear verb_noun pattern with underscores (e.g., calculate_isv, search_inventory, contact_me), making naming predictable and easy for an agent to interpret.
Nine tools cover the core needs of a car services platform (tax calculation, valuation, inventory, contact, import quoting, service listing) without excess or deficiency.
The tool set covers major operations like tax calculation, valuation, inventory search, import quoting, and contact. A direct 'sell your car' tool is missing, but the flow via estimate_resale_value and contact_me covers it indirectly.
Vehicle valuations and market reports in Claude or ChatGPT. Pay per report, no subscription.
Automotive inventory search for AI assistants: vehicles, dealers, deals, and market data.
Search live US dealership inventory, get market prices, and send buyer inquiries. Free, no API key.
Vehicle data for AI: VIN decoder, automotive specs, stolen checks, valuation and way more.
