pricewise-mcp

Overview Schema Source Related Servers Discussions Admin

Calculate ISV (registration tax)

calculate_isv

Read-onlyIdempotent

Compute Portugal's one-off ISV registration tax for a used passenger car imported from another EU/EEA state using its registration date, fuel, engine size, CO2 and declaration date.

Instructions

Compute ISV (Imposto sobre Veículos), Portugal's one-off registration tax, due when a used passenger car from another EU/EEA state is registered in Portugal ("legalizar um carro importado").

Inputs come from the car's documents: first-registration date (field B), fuel, engine cc (P.1) and CO2 g/km (V.7), plus the declaration date. If the user does not know engine_cc or co2_g_km, ask them; do not estimate. If the CO2 test standard (NEDC/WLTP) or a diesel's particle value is unknown, call anyway: the result assumes the costlier case and says so in flags.

Returns total_eur, its components and the legal sources. Always relay flags and disclaimer to the user: this is an illustration, not tax advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "vehicle": "<vehicle>",
      "declaration_date": "<declaration_date>"
    },
    "name": "calculate_isv"
  }
}

Input Schema

Name	Required	Description
`vehicle`	Yes	The car being registered.
`tax_year`	No	Year of the tax tables to use. Only years listed in the pricewise://tables resource are available (currently 2026).
`declaration_date`	Yes	Date the car is declared to the tax authority (ISO 8601). Sets the age reduction; never defaults to today so results are reproducible.

Output Schema

Name	Required	Description	Default
`flags`	Yes	Assumptions and caveats the caller should relay to the user.
`regime`	Yes
`sources`	Yes	Legal sources of the tables used.
`tax_year`	Yes
`total_eur`	Yes	ISV due, in euros, rounded half-up to the cent.
`disclaimer`	No		Illustration only, not tax advice. Computed from the 2026 tables of the Código do ISV and Código do IUC; confirm with the Autoridade Tributária e Aduaneira before relying on it.
`age_reduction`	Yes	Age reduction applied, 0.10 to 0.80.
`regime_factor`	Yes	Multiplier for the reduced hybrid regimes.
`minimum_applied`	Yes	True if the legal minimum replaced the computed value.
`declaration_date`	Yes
`co2_component_eur`	Yes	CO2 component after age reduction and regime factor.
`co2_standard_used`	Yes
`co2_standard_assumed`	Yes	True if the standard was guessed from the registration date.
`engine_component_eur`	Yes	Engine-size component after age reduction and regime factor.
`alternative_total_eur`	Yes	Total under the other standard, when the standard was unknown and both are possible.
`particle_surcharge_eur`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds real substance on top: conservative assumptions for unknown inputs, the presence of `flags`, and a mandatory disclaimer-relay obligation. It does not discuss the legal sources' structure, but the output schema carries the return shape.

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?

Front-loads the purpose, then inputs, then the unknown-value fallbacks, then the return/relay contract. No sentence is redundant and the quoted Portuguese phrase aids matching without padding.

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 an output schema present, return values need not be enumerated, yet the description still signals total_eur, components and sources, and it mandates relaying flags and disclaimer. For a tax computation whose fallback behavior matters, nothing an agent needs to call it correctly 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 the baseline is 3, and the description earns above that by tying parameters to real document fields (B, P.1, V.7) and stating that declaration_date sets the age reduction and must never default to today. It also establishes a policy for two parameters (ask, do not estimate) that the schema cannot express.

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?

Names a specific verb and resource ('Compute ISV ... Portugal's one-off registration tax') and pins the exact scenario: a used passenger car from another EU/EEA state being registered in Portugal. The scope is narrow enough that an agent can separate it from an annual-tax or price-estimation tool without opening the schema.

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 concrete when-to-use guidance for missing data: ask for engine_cc/co2_g_km rather than estimate, but still call when co2_standard or a diesel's particle value is unknown because the costlier case is assumed. It stops short of naming when to prefer a sibling tool over this one, so it is clear context without explicit exclusions.

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

Deploy Server