UK planning data inside ChatGPT, Claude and your agents

The server URL

Get a key at /api-access (a demo key is free) and put it in the URL. That is the whole setup.

https://api.plota.co.uk/v1/mcp/YOUR_API_KEY

Streamable HTTP, stateless, JSON in and JSON out. Clients that can send headers may use https://api.plota.co.uk/v1/mcp with Authorization: Bearer YOUR_API_KEY instead of the key in the path.

Set up your client

{
  "mcpServers": {
    "plota": { "url": "https://api.plota.co.uk/v1/mcp/YOUR_API_KEY" }
  }
}

What the assistant can do

One tool per API operation, generated from the OpenAPI description, so a new endpoint is a new tool the same day. Three more sit beside them: search and fetch, the pair ChatGPT looks for, and find_council, which turns a council name into the slug the other tools take.

A reply gives the assistant one line per record to read, with the full records once as structured data. Searches leave out applicant, agent and site constraints unless they are asked for; get_application returns all of it for the record that matters. A whole council reference, such as LA04/2022/1694/F, finds that application exactly, archive records included on a paid plan. Tools that change the account or spend allowance tell the assistant to confirm with you first.

Applications

• search_applicationsThe main way to find applications, and the right tool whenever any part of the question can be named as a filter. Exact filters: postcode (full or district), council slug, nation, category slug(s), keyword q, normalised stage, procedure, received and decided date ranges, or a lat/lng radius. Returns records with address, proposal, status, dates, category and links to the Plota page and the council record, plus meta.next_cursor for the next page. Read the council slug from find_council and category slugs from list_categories. Records come back without contacts or constraints unless asked for.
• get_applicationOne planning application in full by its Plota id (the id field from any search result): proposal, address, status, decision, dates, category, documents count, links, and on Pro the planning constraints at the site. This is where the enrichment lives, so search widely and then call this on the one or two that matter. Applicant and agent where held with include_contacts true.
• nearby_applicationsPlanning applications near a point, ordered by distance: give lat and lng, a full UK postcode, or an address (geocoded live), with a radius in metres (max 5000).
• application_historyThe status and decision timeline of one application: every recorded status change with its date.
• search_appealsDecided planning appeals from the Planning Inspectorate: filter by council, outcome (allowed, dismissed, split), type, decision date range, reference or postcode.
• associated_applicationsThe family an application belongs to: earlier and later applications on the same site (outline, reserved matters, amendments, discharge of conditions, appeals).
• searchFallback lookup for a phrase that cannot be broken into filters: a building or estate by name, a street, a council reference, or words from a proposal. Up to ten results with id, title and URL; call fetch with an id for the full record, including historical results. Reference-shaped queries rank exact references first across live and plan-entitled historical records, followed by text mentions. Check the council when several exact matches exist. Whenever the question names a council, a place, a category, a stage, a date range or a number of homes, use search_applications instead for explicit filters.
• fetchThe simple document retrieval pair is search then fetch: fetch an id from search as full text with proposal, address, council, status, decision, dates, category and links. For structured analysis and optional contact or constraint fields, use search_applications and get_application.

Sites

• site_constraintsWhat the national datasets put at a coordinate, a full postcode or an address (geocoded live): flood zones, green belt, conservation areas, listed buildings, scheduled monuments, national landscapes, tree preservation orders, rights of way, farmland grades and more. Pro plan and above; a demo key gets 20 checks to try it.

Decisions

• decision_statsDecision times and approval rates. source=auto (default) tries the register, then official MHCLG aggregates only when the council lacks register decision dates and no window, specific segment or rankings were requested. source=register keeps register-only behaviour. source=mhclg requests official English council aggregates for their stated reporting period: omit window, segment and rankings. The response labels its actual source; official aggregates have median_days null and timing_metrics_available false.
• expiring_consentsPermitted full and outline consents whose statutory time limit falls in the coming months, for a council or a bounding box: sites where permission will lapse unless work starts.

Reference

• list_councilsThe councils Plota monitors with slug, nation, region and coverage. Filter by nation, region, a name fragment (q) or coverage_status; unfiltered it is every authority Plota covers, so filter when looking for one.
• list_categoriesThe planning categories (slug and label) used by the category filter. Call once and reuse the slugs.
• find_councilResolve a council name to the slug every other tool takes: "Waltham Forest" gives waltham-forest. Give any fragment of the name; add nation or region to narrow it. Use this rather than list_councils, which returns every authority.

Account

• list_alertsThe saved alerts on this account.
• create_alertSave an alert that emails the account owner about new applications: type radius (a postcode, address or lat/lng with radius_km 0.25, 0.5, 1, 2 or 5), council (a slug from list_councils) or national (one category from list_categories across a nation). Optional type_filter (categories), min_dwellings and max_dwellings (homes), procedure (e.g. outline or full,outline), q (keywords), frequency daily/weekly/fortnightly, label. The account owner is emailed a confirmation. Plan caps apply. Confirm the area, filters and frequency with the user before calling.
• update_alertChange a saved alert: frequency, label, type_filter, exclude_trees, or paused true/false. This changes what the account owner is emailed: confirm the change with the user before calling.
• delete_alertDelete a saved alert by id. Confirm with the user before calling.
• get_alertOne saved alert by id.
• alert_matchesApplications that matched a saved alert in the last N days.
• create_exportBulk export of matching records in one call (plan-gated). Every row counts against the monthly row allowance and cannot be refunded, so use search_applications for browsing and confirm the filters and the intent with the user before calling.
• list_webhooksThe webhooks registered on this account.
• create_webhookRegister an HTTPS endpoint to receive application.match.created events for a saved alert. Confirm the URL with the user before calling.
• delete_webhookDelete a webhook by id. Confirm with the user before calling.
• test_webhookSend a signed test event to a webhook by id. This calls the customer's endpoint: confirm with the user before calling.

Things to ask

• "What planning applications are pending within 300 m of SW11 2PF?"
• "Is this site in a conservation area or a flood zone, and are there listed buildings nearby?"
• "How long does Wandsworth take to decide householder applications, and how does that compare with the national figure?"
• "Which consents in Bristol lapse in the next six months?"
• "Show me appeals allowed against Wiltshire refusals this year."
• "Export every new-homes application in Cornwall received since June."
• "Which applications are linked to Oldham application HOU/355665/26?"
• "Email me every week about new applications within 1 km of SW11 2PF."

Allowance and privacy

Every tool call is one API request on the key, counted against the same request and records allowance as any other call on the plan. Applicant and agent details also draw on the plan's contact allowance, and an export counts every row it returns. There is no separate MCP price, and the demo key works for trying it out. The API pricing page has the plans.

Plota sees what it sees for any API call: the request, the key, the time and the size of the response, in the API request log. The conversation stays with the assistant. Nothing an assistant asks is used to train anything.

The key in the URL is the credential. Paste the URL into the connector and nowhere else, and rotate the key from the API dashboard if it is ever exposed. The API terms apply to use through MCP as they do to any other call.

Questions

What is MCP?

The Model Context Protocol is the open standard AI assistants use to call outside tools. A connector is a server that offers tools; the assistant reads the tool list, decides which to call, and reads the result. Plota offers one tool per API operation, so an assistant can search applications, read one record, check what constrains a site, compare decision times and more, with the figures coming from Plota rather than from memory.

Which assistants work with it?

Any client that speaks MCP over HTTP: ChatGPT (as a plugin, with Developer mode on), Claude on the web and in Claude Desktop, Cursor, Windsurf, VS Code with Copilot, and agent frameworks.

How is use charged?

Every tool call is one API request on the key, under the same request and records allowance as any other call on the plan. There is no separate MCP price. A demo key works for trying it out.

Is the key in the URL safe?

The key is the credential, so the URL is a password: paste it into the connector and nowhere else. Clients that can send headers may use the bare URL with an Authorization header instead. Keys can be rotated at any time from the API dashboard.

What does Plota see?

The same as for any API call: the request, the key it was made with, the time and the size of the response, kept in the API request log. The conversation itself stays with the assistant.