Skip to main content
Glama

Planning: permitted development or not? (England)

check_permitted_development
Read-onlyIdempotent

Checks a householder project in England against the permitted development limits in the GPDO 2015, Schedule 2, Part 1: single and multi storey rear extensions, side and wraparound extensions (Class A), loft dormers and hip to gable (Class B), rooflights (Class C), porches (Class D), outbuildings and garden rooms (Class E), and adding storeys (Class AA). Returns verdict (permitted_development, prior_approval_route, needs_planning_permission, needs_listed_building_consent, check_article_4_or_condition, needs_more_info, not_covered), answer, one line per limit in checks (status pass, fail or needs_input, with the limit and the rule's paragraph), the larger home extension prior approval route when a single storey rear extension is 3 to 6 m (attached) or 4 to 8 m (detached), flags for conservation areas, National Parks, National Landscapes, listed buildings and Article 4, must_confirm and sources. Example: 3.5 m single storey rear extension on a semi, 3.8 m high: {"project":"rear_extension_single_storey","house_type":"semi_detached","depth_m":3.5,"height_m":3.8,"eaves_height_m":2.8,"within_2m_of_boundary":true,"curtilage_coverage_percent":20,"materials_similar":true,"higher_than_existing_roof":false,"eaves_higher_than_existing":false,"beyond_principal_or_highway_side_elevation":false,"balcony_veranda_or_raised_platform":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": {
      "project": "<project>"
    },
    "name": "check_permitted_development"
  }
}

Input Schema

NameRequiredDescriptionDefault
tradeNoOptional. 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.
nationNoDefaults to england. Only england is checked; others return not_covered.
depth_mNoRear extensions: how far it projects beyond the rear wall of the ORIGINAL house, metres.
projectYes
storeysNoStoreys in the extension or outbuilding.
width_mNoSide extensions: width of the extension.
claddingNoArticle 2(3) land: will the outside be clad in stone, render, pebble dash, timber, plastic or tiles?
height_mNoHighest point of the extension, porch or outbuilding above ground, metres.
roof_typeNoOutbuildings: dual pitched allows 4 m (if not within 2 m of a boundary).
house_typeNoNeeded for rear extensions (4 m detached, 3 m otherwise) and lofts (40 m3 terraced or end terrace, 50 m3 otherwise).
designationsNoAny that apply at the address. national_landscape is the new name for an AONB. Leave empty if none.
hip_to_gableNoLofts: is it a hip to gable (no eaves set back needed)?
protrusion_mNoRooflights: how far it stands proud of the roof slope, metres.
floor_area_m2NoPorches: external ground floor area. Outbuildings: footprint.
property_kindNoDefaults to house. Flats and maisonettes have no householder permitted development.
eaves_height_mNoEaves height, metres.
added_volume_m3NoLofts: extra roof space volume including any earlier roof enlargements, m3.
eaves_setback_mNoLofts: dormer set back from the eaves along the slope, metres (at least 0.2).
materials_similarNoExternal materials look similar to the house.
roof_pitch_matchesNoMulti storey: roof pitch matches the house as far as practical.
distance_from_house_mNoOutbuildings in National Parks, National Landscapes, the Broads or World Heritage Sites.
within_2m_of_boundaryNo
original_house_width_mNoSide extensions: width of the original house.
higher_than_existing_roofNo
curtilage_coverage_percentNoAfter the work: ground covered by all buildings other than the original house, as a % of the plot excluding the original house footprint.
eaves_higher_than_existingNo
distance_to_rear_boundary_mNoMulti storey rear extensions: distance from the extension to the boundary opposite the rear wall.
on_front_slope_facing_highwayNoLofts: does the dormer go on the front roof slope facing a road?
between_side_wall_and_boundaryNoOutbuildings on Article 2(3) land.
distance_to_highway_boundary_mNoPorches: distance to the boundary with a road or footway.
forward_of_principal_elevationNoOutbuildings: in front of the house's front wall?
side_windows_obscure_and_fixedNoUpper floor or roof windows in a side wall are obscure glazed and non-opening below 1.7 m.
balcony_veranda_or_raised_platformNoIncludes a balcony, veranda, or a raised platform (decking) over 0.3 m high.
used_for_sleeping_or_separate_homeNo
beyond_principal_or_highway_side_elevationNoDoes it go forward of the front (principal) wall, or of a side wall facing a road?

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent, closed-world read, so the safety profile is covered. The description adds real behavioral detail beyond that: the full verdict enum, per-limit check statuses (pass/fail/needs_input) with paragraph citations, the 3-6 m attached / 4-8 m detached prior-approval route, designation flags, must_confirm and sources. It does not say how verdicts are prioritised when several checks fail, which keeps it off a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, but the body is one long run-on sentence stitched together with colons and semicolons, listing return fields and an enum inline, which is dense to parse. The trailing example is worth its length for a 35-parameter tool; the prose before it could be broken into scannable sentences.

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 35-parameter, 9-project-type tool with no output schema, this does a lot: it names the return fields, the verdict values, the check structure, designation flags and sources, with a worked example. Remaining gaps are minor, such as how to interpret must_confirm or what happens when inputs are insufficient (only implied by the needs_more_info verdict).

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 86%, so the baseline is 3, and the description earns a bump: it maps the project enum to specific GPDO classes, states the prior-approval depth thresholds attached to house_type (4 m detached, 3 m otherwise), and supplies a fully populated example input showing the expected shape across a dozen optional fields.

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?

Opens with a specific verb and resource ('Checks a householder project in England against the permitted development limits in the GPDO 2015') and then enumerates exactly which project classes (A, B, C, D, E, AA) are covered, so an agent can match a user question to this 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?

Usage context is clear: householder projects in England under GPDO Part 1, with the enumerated project list effectively defining when the tool applies and when it does not (non-England, non-householder). It stops short of naming alternatives such as check_building_regs or stating explicit exclusions, so routing still relies on the agent's own comparison.

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.