Site Pack

Building Regulations: notifiable, which route, which Parts? (England and Wales)

check_building_regs

Read-onlyIdempotent

For one or more kinds of building work in England or Wales: is it notifiable building work, exempt (small outbuildings, ground level conservatories and porches up to 30 m2), self-certifiable by a competent person scheme (FENSA, Certass, HETAS, OFTEC, CompetentRoofer), or must it go to the Building Safety Regulator (higher-risk buildings, England). Says whether a building notice is allowed or full plans are required (non-domestic, common parts of flats, within 3 m of a public sewer), and lists the Parts of Schedule 1 likely to apply with the reason for each (indicative). Returns verdict, notifiable, per-work reasons, routes, parts_likely_to_apply, must_confirm and sources. Example: {"work":["single_storey_extension","remove_load_bearing_wall"],"within_3m_of_public_sewer":false}.

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": {
      "work": "<work>"
    },
    "name": "check_building_regs"
  }
}

Input Schema

Name	Required	Description
`work`	Yes	All the kinds of work in the job.
`trade`	No	Optional. The builder's own business details (Nero Trade Profile v1). Used to prefill the contractor details in notices and CDM answers and to give a stable nero_trade_ref. Not stored by Site Pack.
`nation`	No	Defaults to england. Scotland and Northern Ireland return not_covered.
`building_type`	No	Defaults to house.
`floor_area_m2`	No	Outbuildings, conservatories and porches: internal floor area.
`higher_risk_building`	No	England: at least 18 m or 7 storeys with at least 2 homes (or a care home or hospital of that height).
`area_renovated_percent`	No	Re-roofing, re-rendering, wall insulation: share of that roof or wall area being renovated, %.
`distance_to_boundary_m`	No	Outbuildings of 15 to 30 m2: distance to the nearest boundary.
`mainly_non_combustible`	No	Outbuildings of 15 to 30 m2: built mainly of non-combustible materials?
`sleeping_accommodation`	No	Outbuildings: will anyone sleep in it?
`competent_person_scheme`	No	If the installer is a member of one (for windows, stoves, roofs).
`heated_from_house_system`	No	Conservatories: heated by extending the house heating?
`within_3m_of_public_sewer`	No
`separated_by_external_doors`	No	Conservatories and porches: separated from the house by external quality walls, doors or windows?

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.9/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 safety is covered; the description usefully adds that outputs are indicative, carry a must_confirm flag and cite sources, and that results are jurisdictional (higher-risk routing is England-only). It stops short of explaining the not_covered behaviour or how trade details feed into notices, which live only in the schema.

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 core question is front-loaded in the first clause and each subsequent clause adds a distinct decision (exempt, self-certifiable, BSR, notice vs full plans, Parts). It is dense but a single paragraph carries three separate determinations; trimming the parenthetical scheme list would tighten it further.

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 14-parameter tool with a nested trade object and no output schema, the description compensates by enumerating the returned fields (verdict, notifiable, reasons, routes, parts_likely_to_apply, must_confirm, sources) and flagging the indicative caveat. The only omission is any mention of the trade parameter's prefill/nero_trade_ref behaviour, which the schema does cover.

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 93%, so the schema already documents nearly every parameter including the sewer-distance, floor-area and boundary rules; the description largely restates those triggers (30 m2, 3 m of a public sewer). Its one genuine addition is a worked example showing how work and within_3m_of_public_sewer combine, which is why it holds the baseline rather than falling below it.

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?

States a specific verb-and-resource: for a given kind of work it determines notifiable status, exemption, competent-person self-certification, Building Safety Regulator routing, notice-vs-full-plans, and likely Schedule 1 Parts. This is clearly distinct from check_permitted_development and party_wall_notices, and the scope (England and Wales, one or more kinds of work) is explicit.

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

Usage Guidelines3/5

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

The opening clause establishes the context ('For one or more kinds of building work in England or Wales'), so usage is implied well enough to select the tool. However, it never states when to reach for this rather than check_permitted_development, cdm_duties or party_wall_notices, and gives no explicit exclusions; that routing is left to inference from sibling names.

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

All Site Pack 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.