calculateRun the Car import cost calculator calculator: Customs value (car + shipping); Import duty; Import VAT; DVLA first registration fee. Missing inputs fall back to their documented defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Vehicle price / value | |
| origin | No | Where the car was built | japan |
| classic | No | Over 30 years old and in original condition | 0 |
| shipping | No | Shipping and insurance to the UK |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavior disclosure burden. It transparently notes the default-fallback behavior and lists the calculation outputs, but it does not mention side effects, output format, or how invalid inputs are handled. This is moderate transparency for a calculator tool.
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 one concise sentence that front-loads the tool's purpose and ends with the key fallback behavior. The phrase 'calculator calculator' is a minor redundancy/typo that prevents a perfect score.
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?
The description is adequate for a simple calculation tool with all optional parameters and full schema coverage. However, since there is no output schema, the description could more explicitly state what the tool returns and in what shape.
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 coverage is 100%, so the parameter schema already documents all four inputs. The description adds some context by grouping them into calculation components, but it does not materially expand on the schema's meaning.
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 runs the car import cost calculator and enumerates what it computes: customs value, import duty, import VAT, and DVLA first registration fee. This distinguishes it from the enquiry-related siblings, though it does not explicitly contrast it with calculator_describe.
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 guidance is given on when to use this tool versus calculator_describe or the enquiry tools. The only usage hint is that missing inputs fall back to defaults, which is useful but not enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: calculate performs the calculation, calculator_describe documents it, enquiry_describe explains the enquiry flow, enquiry_fields provides the schema, and submit_enquiry performs the submission. The two describe tools are separated by subject and are not ambiguous.
Names are readable and consistently lowercase with underscores, but they mix conventions: calculate and submit_enquiry are verb-first, while calculator_describe, enquiry_describe, and enquiry_fields are noun-first metadata names. This is not chaotic, but the word-order inconsistency prevents a higher score.
Five tools is well-scoped for this Car Import Calculator site: one calculation action, one calculator metadata tool, and a two-step enquiry workflow supported by two metadata tools and one submission tool. No tool feels redundant, and the count is comfortably within the ideal range.
The implied domain is a car-import cost calculator with human-provider enquiries. The set covers calculation, calculator documentation, enquiry instructions, field schema, and the full two-step submission/confirmation flow, leaving no obvious dead-end or missing lifecycle step.