Belgian procedural indemnity (rechtsplegingsvergoeding) amounts, indexed to the CPI for any date.
Scored across 3 tools
Each tool has a distinct angle: calculate_rpv computes claim-specific amounts, get_indexation_status reports CPI/indexation, and get_rate_table returns the full bracket table. There is mild overlap since both calculate_rpv and get_rate_table return indexed min/base/max amounts, but the descriptions clarify the different purposes (single claim vs. whole table).
All three names use consistent snake_case with a clear verb_noun structure (calculate_rpv, get_indexation_status, get_rate_table). The verb varies appropriately with the action while the pattern stays predictable.
Three tools is reasonable for a focused calculator covering calculation, indexation, and rate lookup. It is on the lean side, but each tool earns its place with no redundancy.
The surface covers the core lifecycle: computing a claim's indemnity, understanding indexation, and viewing the full bracket table. Minor gaps exist (e.g. no court-type or bracket discovery), but agents can work around these.
Calculates the Belgian procedural indemnity (rechtsplegingsvergoeding / indemnité de procédure) for a claim: the minimum, base and maximum amounts in EUR, indexed for the given date. The result includes an explanation: the calculation steps (tariff, bracket, unindexed Royal Decree amounts, indexation), the judge's discretion under Article 1022 Judicial Code and, for a partly non-monetary claim, how the two tariffs compare. Use it to explain how and why the amount was reached.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional reference date (YYYY-MM-DD), usually the date of the judgment. Defaults to today. Uses the indexation in force on that date. | |
| amount | No | Amount in dispute in EUR. A number, or a Belgian-formatted string such as "2.500,50". Omit for a claim that cannot be valued in money. | |
| locale | No | Language of the card and the calculator link. Always set it to the language the user writes in (nl, fr, de or en; use "en" for any other language). Defaults to "nl". | |
| court_type | Yes | Court/procedure type: "general" = General rate (art. 2 KB 26/10/2007): all courts and tribunals, including labour courts for e.g. employment-contract disputes. "voorzitter" = President of the Labour Court, proceedings under arts. 579 and 1017(2) Judicial Code (occupational accidents/diseases, social security). "arbeidsrechtbank" = Labour Court (arbeidsrechtbank / tribunal du travail), proceedings under arts. 579 and 1017(2) Judicial Code. "arbeidshof" = Labour Court of Appeal (arbeidshof / cour du travail), proceedings under arts. 579 and 1017(2) Judicial Code. | |
| no_monetary_value | No | True when (part of) the claim cannot be valued in money. If an amount is also given, both the non-monetary amount and the amount bracket are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description usefully adds behavioral context unavailable in structured fields: the result carries calculation steps, the judge's discretion under Article 1022, and the two-tariff comparison for partly non-monetary claims. It stops short of noting error behavior for invalid dates or court types.
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 dense, front-loaded sentences: the first defines the computation and its outputs, the second defines the explanation content and the intended use. No filler, though the parenthetical enumeration of output components is slightly list-heavy.
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?
With no output schema, the description does the work of describing the return payload (amounts plus explanation), which is the key gap it needed to fill; parameter documentation is complete via the schema. Minor omissions remain: no stated error behavior, and no routing guidance against the two sibling lookup tools.
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 schema already documents date, amount, locale, court_type and no_monetary_value thoroughly, including enum meanings. The description adds only the framing that indexing follows the given date; it does not extend parameter meaning beyond the schema, so the baseline of 3 applies.
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?
States a specific verb and resource ("Calculates the Belgian procedural indemnity") and enumerates the concrete outputs (minimum, base, maximum in EUR, indexed for a given date). The purpose is unmistakable. It does not, however, contrast itself with the sibling tools (get_rate_table, get_indexation_status), so an agent must infer that this one computes rather than just returns tariff/index data.
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?
"Use it to explain how and why the amount was reached" gives a purpose for the explanation output but no when-to-use vs. when-not guidance, no prerequisites, and no mention of the sibling tools for raw tariff or index lookups. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the CPI indexation currently in force for the procedural indemnity amounts, the latest Belgian CPI (base 2004), the estimated date of the next indexation, and the monthly CPI of the last five years. A new multiplier is the CPI of the month that reaches the threshold divided by the start index 105.78, so it is at least next_indexation_minimum_multiplier; do not derive it from the current multiplier.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of the card and the calculator link. Always set it to the language the user writes in (nl, fr, de or en; use "en" for any other language). Defaults to "nl". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. With no output schema, the description carries the return-shape burden and does so well (current indexation, latest CPI, next indexation date, five years of monthly CPI), plus a non-obvious computational caveat about how the multiplier relates to next_indexation_minimum_multiplier.
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 the return contents; no filler. The second sentence is dense domain jargon (start index 105.78, threshold) that earns its place as a correctness warning but makes the description somewhat heavy for a read-only status call.
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 a no-argument read-only tool with no output schema, the description fully covers what is returned and adds the one dangerous misinterpretation to avoid. Nothing essential for correct invocation is missing, though it omits any freshness/pagination note about the five-year CPI series.
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% and the single locale parameter is fully documented with enum values and default, so the description correctly adds nothing. Baseline 3 for high coverage with no extra parameter 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 opens with a specific verb-and-resource statement ("Returns the CPI indexation currently in force") and enumerates exactly what data comes back, including base year and time span. It is clearly differentiated in substance from calculate_rpv and get_rate_table, but never names or contrasts those siblings explicitly, so it stops 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied ("call this to see the current indexation situation"); no when/when-not conditions or alternatives are stated. The closing warning ("do not derive it from the current multiplier") is a genuine domain guideline that constrains behavior, which lifts it above a bare 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns every bracket of the procedural indemnity table for a court type (min/base/max in EUR), indexed for the given date. Pass the amount in dispute when the user mentions one, so the card can highlight its bracket.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional reference date (YYYY-MM-DD), usually the date of the judgment. Defaults to today. Uses the indexation in force on that date. | |
| amount | No | Optional amount in dispute in EUR, to highlight its bracket. A number, or a Belgian-formatted string such as "12.500". | |
| locale | No | Language of the card and the calculator link. Always set it to the language the user writes in (nl, fr, de or en; use "en" for any other language). Defaults to "nl". | |
| court_type | Yes | Court/procedure type: "general" = General rate (art. 2 KB 26/10/2007): all courts and tribunals, including labour courts for e.g. employment-contract disputes. "voorzitter" = President of the Labour Court, proceedings under arts. 579 and 1017(2) Judicial Code (occupational accidents/diseases, social security). "arbeidsrechtbank" = Labour Court (arbeidsrechtbank / tribunal du travail), proceedings under arts. 579 and 1017(2) Judicial Code. "arbeidshof" = Labour Court of Appeal (arbeidshof / cour du travail), proceedings under arts. 579 and 1017(2) Judicial Code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint false, and idempotentHint, covering the safety profile. The description adds that results are indexed to a date and that the amount highlights a bracket, but omits auth, rate limits, or error behavior.
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 the return content and followed by a focused usage tip. No redundant or filler text.
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 read-only table lookup with a fully described schema and safety annotations, the description covers purpose, output content, and the indexation/amount context. It omits any reference to sibling tools, which could help an agent route correctly, but is otherwise sufficient.
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%, so the schema already documents all four parameters including enums for court_type and locale. The description only reiterates the amount parameter's purpose, adding no new syntax or edge-case guidance.
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?
States a specific verb ('Returns') and resource ('every bracket of the procedural indemnity table') with clear scope ('for a court type', 'indexed for the given date'). It implicitly differentiates from calculate_rpv by returning all brackets rather than a computed amount, but does not name siblings explicitly.
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 a parameter-level guideline ('Pass the amount in dispute when the user mentions one'), but offers no overall when-to-use guidance or comparison to calculate_rpv / get_indexation_status. Usage is implied by the purpose.
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.
calculate_rpv1 field changedInput schema / properties / locale / descriptionPrevious value: -"Language of the returned calculator link. Defaults to \"nl\"."New value: +"Language of the card and the calculator link. Always set it to the language the user writes in (nl, fr, de or en; use \"en\" for any other language). Defaults to \"nl\"."get_indexation_status1 field changedInput schema / properties / locale / descriptionPrevious value: -"Language of the returned link and card. Defaults to \"nl\"."New value: +"Language of the card and the calculator link. Always set it to the language the user writes in (nl, fr, de or en; use \"en\" for any other language). Defaults to \"nl\"."get_rate_table2 fields changedInput schema / properties / amountAdded value: +{
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ],
+ "description": "Optional amount in dispute in EUR, to highlight its bracket. A number, or a Belgian-formatted string such as \"12.500\"."
+}Input schema / properties / locale / descriptionPrevious value: -"Language of the returned calculator link. Defaults to \"nl\"."New value: +"Language of the card and the calculator link. Always set it to the language the user writes in (nl, fr, de or en; use \"en\" for any other language). Defaults to \"nl\"."calculate_rpvget_indexation_statusget_rate_tableAutomatic Brazilian monetary correction for AI: update any amount by IPCA, INPC, IGP-M, SELIC, TR an
Automatic Brazilian legal calculators: monetary correction and debt settlement (correction by IPCA,
Statbel — Statistics Belgium (be.STAT / bestat) open data MCP.
Netherlands court decisions (uitspraken en conclusies) — search by court, legal domain and date…
Add one secure layer between your agents and this server.