Skip to main content
Glama

WOZ value objection check and OZB property tax

woz_objection_netherlands
Read-onlyIdempotent

Checks whether objecting to a Dutch WOZ value (the municipal home valuation) is worth it: compares the WOZ value with comparable sales by price per m², and shows what a lower value saves a year in eigenwoningforfait (Box 1) and OZB property tax, and the 6-week objection deadline. Without comparable sales it still gives the yearly OZB and how objecting works. Objecting is free; the decision (WOZ-beschikking) says the value and the date.

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": {
      "woz_value": "<woz_value>"
    },
    "name": "woz_objection_netherlands"
  }
}

Input Schema

NameRequiredDescriptionDefault
woz_yearNoThe year on the WOZ decision. Default 2026.
woz_valueYesWOZ value on the decision, in euros
comparablesNoComparable homes sold around the valuation date (1 January of the year before the WOZ year): price and living area. Two or more make the comparison usable.
ozb_rate_pctNoOZB owner rate of the municipality, % of the WOZ value (on the tax assessment). Default 0.1.
decision_dateNoDate on the WOZ decision, YYYY-MM-DD, for the deadline (optional)
living_area_m2NoLiving area of the home in m² (needed to compare with sales)
taxable_incomeNoBox 1 taxable income, to work out the tax rate on the eigenwoningforfait. Default: the 37.56% rate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

With annotations already declaring this as a read-only, idempotent, non-destructive tool, the description adds useful behavioral context: objecting is free, the WOZ-beschikking contains the value and date, and the objection deadline is six weeks. It also discloses the no-comparables fallback behavior. It does not describe every output field, but it goes beyond the annotations.

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 description is dense but front-loaded: it states the core purpose first, then elaborates on savings, the deadline, and the fallback case. Every sentence adds information relevant to calling or interpreting the tool. It is slightly long and run-on but well structured for a complex financial check.

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?

For a complex, multi-input financial calculation with no output schema, the description explains the main outputs: comparable-sales comparison, yearly savings in eigenwoningforfait and OZB, and the objection deadline. It also covers the no-comparables fallback. Some finer details of returned values and assumptions are left implicit, but the description is sufficient for an agent to understand what the tool will do.

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%, so the input schema already documents each parameter thoroughly. The description adds some meaning by noting that two or more comparable sales make the comparison usable and by tying the deadline to the decision date. Since the schema carries most parameter semantics, the baseline score of 3 is appropriate.

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?

The description names a specific verb and resource: checking whether objecting to a Dutch WOZ value is worthwhile. It distinguishes itself from the many other Dutch tax tools by focusing on WOZ valuation, comparable sales per m², OZB, eigenwoningforfait, and the objection deadline. An agent can identify the tool's domain 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?

The description makes clear when the tool applies: when someone has a WOZ decision and is considering objecting. It also explains the fallback when no comparable sales are supplied, still returning yearly OZB and objection information. It does not explicitly name when not to use it or name sibling alternatives, but 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources