Skip to main content
Glama

HouseFile UK property licensing checker

Check a property’s licensing

check_property_licensing
Read-onlyIdempotent

Looks up a postcode in England in HouseFile’s records of council licensing schemes and returns each scheme in force there, with its dates, fee, source link and the date the records were last verified, plus the national HMO rule. Schemes not in force yet are listed under upcoming. It works to postcode precision, so near a scheme’s edge it says so. Give occupants and households to settle the mandatory HMO test in England.

Input Schema

NameRequiredDescriptionDefault
postcodeYesThe full UK postcode of the property being checked, in any spacing or case, such as "e8 1dy". Only its first half is kept
occupantsNoHow many people live in the property
as_of_dateNoYYYY-MM-DD. Defaults to today; at most 24 months ahead
householdsNoHow many separate households they form

Output Schema

NameRequiredDescriptionDefault
councilYes
countryYes
coveredYes
schemesYes
postcodeYes
upcomingYes
as_of_dateYes
disclaimerYes
housefile_urlYes
council_gss_codeYes
council_address_checkerYesThe council’s own address-level lookup, where it has one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / address_line
      Removed value: -{
      -  "description": "House number or name and street. Accepted, but the lookup works to postcode precision, and the address is never stored",
      -  "maxLength": 200,
      -  "type": "string"
      -}
    • changedInput schema / properties / postcode / description
      Previous value: -"A full UK postcode in any spacing or case, such as \"e8 1dy\""New value: +"The full UK postcode of the property being checked, in any spacing or case, such as \"e8 1dy\". Only its first half is kept"
  2. Changed1 schema field changed
    • addedOutput schema / properties / upcoming / items / properties / expected_start_date / description
      Added value: +"Null where the council hasn’t announced a start date"
  3. Changed3 schema fields changed
    • addedOutput schema / properties / upcoming / items / properties / applicability
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "applies",
      +        "conditional",
      +        "boundary_uncertain",
      +        "does_not_apply",
      +        "not_covered"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Whether the postcode falls in the scheme’s area on our records, as for a scheme in force. Null where no postcode was given"
      +}
    • addedOutput schema / properties / upcoming / items / properties / note
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / upcoming / items / required
      Previous value: -[
      -  "scheme_name",
      -  "scheme_type",
      -  "council",
      -  "stage",
      -  "expected_start_date",
      -  "end_date",
      -  "summary",
      -  "source_url",
      -  "last_verified_at",
      -  "housefile_url"
      -]New value: +[
      +  "scheme_name",
      +  "scheme_type",
      +  "council",
      +  "stage",
      +  "applicability",
      +  "note",
      +  "expected_start_date",
      +  "end_date",
      +  "summary",
      +  "source_url",
      +  "last_verified_at",
      +  "housefile_url"
      +]
  4. First observed

TDQS

A4.3/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 (openWorldHint=false), so the safety profile is covered. The description goes further with substantive traits the annotations can't express: postcode-level precision and explicit edge-of-scheme caveats, the split between in-force and upcoming schemes, and record staleness via a 'last verified' date.

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?

Front-loaded with the verb and result shape, and every sentence carries information (scope, return fields, precision caveat, HMO-test inputs). It is dense rather than padded, though the run-on first sentence packs several distinct claims together and could be split for faster scanning.

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?

With an output schema present, return values need no elaboration, and annotations cover safety; the description still adds precision caveats and HMO-test guidance. The one gap is as_of_date, whose retroactive/prospective use (defaults to today, up to 24 months ahead) is left entirely to the schema.

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 100%, so a 3 is the baseline. The description nonetheless adds meaning beyond the schema by explaining that occupants and households exist to settle the mandatory HMO test, which tells the agent why those optional parameters change the answer rather than just what they are.

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 (looks up a postcode in England against HouseFile's council licensing scheme records) and names the exact payload returned: schemes in force, dates, fee, source link, verification date, national HMO rule, plus upcoming schemes. This clearly separates it from siblings like list_council_schemes (enumeration) and upcoming_licensing_changes (future-only), since this tool is the per-property lookup.

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?

Gives clear operational context — supply occupants and households to resolve the mandatory HMO test in England, and note that not-yet-in-force schemes appear under 'upcoming'. It does not, however, explicitly say when to prefer this over licensing_coverage or upcoming_licensing_changes, leaving the sibling routing to inference.

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