MarketCode

Council tax band

council_tax_band

Read-onlyIdempotent

VOA council tax band for a property, from the official list.

Every band is DECLARED — read from the VOA list, never inferred by a model.
`band_source` states which, and a predicted band would arrive as a distinct
value rather than folded in, because a caller cannot tell the two apart
after the fact.

DO NOT PRESENT A BAND AS A BILL. Three fields come back null on purpose and
must not be filled in by estimating:
  * `annual_cost_gbp` — the per-band charge for each billing authority is a
    separate source we do not hold.
  * `effective_date` — the crawl records when the VOA refreshed the LIST,
    which is not when this property's band took effect.
  * `composite` — same reason; it lives on the per-property detail page.

`status` is `not_found` when the band exists in the VOA list but address
matching has not linked this UPRN to it. That is a matching gap on OUR
side, not evidence the property has no band — report it that way round.

England and Wales only: Scotland is the Scottish Assessors Association and
Northern Ireland is Land & Property Services, neither of which is in this
list. Free. Keyed on a UPRN, not an address: call `address_autocomplete` (free) to narrow, then `address_resolve` to get one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uprn`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With annotations already covering read-only, idempotent, and non-destructive behavior, the description adds substantial behavioral context: declared versus inferred bands, band_source semantics, three intentionally null fields, not_found matching-gap behavior, and coverage limits. These are exactly the details an agent could otherwise misinterpret.

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 purpose is front-loaded and most content is high-value warning material. It is longer than average, with several paragraphs and bullets, but nearly every sentence earns its place by preventing misuse or misinterpretation of returned fields.

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?

Given the tool's simplicity, one required UPRN parameter, and an existing output schema, the description is more than complete. It explains geography, workflow, null-field semantics, status behavior, and output meaning without needing to restate the output schema itself.

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 description coverage is 0%, so the description must carry parameter meaning. It does so by stating the tool is keyed on a UPRN rather than an address and describing how to obtain one via address_autocomplete and address_resolve. It does not specify UPRN format constraints, but it covers the essential meaning beyond the schema's integer type.

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 states a specific verb and resource: retrieves the VOA council tax band for a property from the official list. It clearly distinguishes itself from address-resolution siblings by instructing callers to use address_autocomplete and address_resolve to obtain the required UPRN.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly defines the geographic scope (England and Wales only, excluding Scotland and Northern Ireland), notes that the tool is free, and explains the correct workflow: use address_autocomplete to narrow and address_resolve to get a UPRN. It also warns not to treat a band as a bill and explains the not_found matching-gap semantics.

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

All MarketCode tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?