Checks whether a property in England is in a council's selective or HMO licensing scheme
Scored across 4 tools
Each tool is anchored to a different lookup scope: postcode, coverage metadata, one council's full scheme list, and a time-windowed change feed. Some upcoming/proposed scheme data appears in multiple outputs, but the parameters and descriptions make the intended selection clear.
All names use snake_case and are descriptive, but the pattern is mixed: two verb_noun names (check_property_licensing, list_council_schemes) and two noun-phrase names (licensing_coverage, upcoming_licensing_changes). Readable, but not a single predictable convention.
Four tools is well scoped for a read-only property licensing reference service. Each tool covers a distinct query need: property lookup, coverage confidence, council detail, and upcoming/recent changes.
The surface covers property-level licensing checks, coverage transparency, council-level scheme listings, and upcoming/recent changes, including the national HMO rule and verification dates. For the stated read-only domain, there are no obvious missing operations.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | The full UK postcode of the property being checked, in any spacing or case, such as "e8 1dy". Only its first half is kept | |
| occupants | No | How many people live in the property | |
| as_of_date | No | YYYY-MM-DD. Defaults to today; at most 24 months ahead | |
| households | No | How many separate households they form |
| Name | Required | Description |
|---|---|---|
| council | Yes | |
| country | Yes | |
| covered | Yes | |
| schemes | Yes | |
| postcode | Yes | |
| upcoming | Yes | |
| as_of_date | Yes | |
| disclaimer | Yes | |
| housefile_url | Yes | |
| council_gss_code | Yes | |
| council_address_checker | Yes | The council’s own address-level lookup, where it has one |
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.
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.
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.
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.
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.
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.
Which councils HouseFile’s records cover: each council with published schemes, with how many, how many are in force and when they were last verified, and the councils checked and found to run none. Use it to tell the user honestly whether their area is covered, and list_council_schemes for one council’s detail.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| councils | Yes | Councils with published schemes. Councils checked and found to run none are in checked_no_scheme_councils |
| council_count | Yes | Every council the records cover, with schemes or checked and found to run none |
| housefile_url | Yes | |
| councils_with_schemes | Yes | |
| published_scheme_count | Yes | |
| checked_no_scheme_count | Yes | |
| most_recent_verification | Yes | |
| checked_no_scheme_councils | Yes | Short names of the councils a person checked and found to run no additional or selective scheme. list_council_schemes gives the date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive. Beyond that, the description discloses a non-obvious behavioral trait: the result includes negative findings (councils checked and found to run none), which prevents an agent from misreading absence as no data. It does not note result size or how stale 'last verified' can get, so it stops short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is returned, then the usage rule. The first sentence is a long compound clause listing the output fields, which is dense on first read but every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required; the description instead supplies scope and the sibling routing. What is missing is minor: no hint about dataset granularity (UK councils only?) or how frequently verification runs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies; the description correctly implies no filtering is possible and that the whole coverage set is returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource (council licensing coverage) and enumerates exactly what the result contains: per-council counts, in-force counts, last-verified dates, and councils checked with no schemes. This is clearly differentiated from list_council_schemes, which is called out as the per-council detail view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it (to answer whether the user's area is covered) and names the alternative (list_council_schemes) for the deeper per-council case. The routing decision is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists a council’s licensing schemes from HouseFile’s records: in force, starting soon, proposed, and ended in the last 12 months, each with its area, dates, fee, source link and last verified date. Takes a council name, part of a name or a GSS code. If several councils match, it returns them to choose from.
| Name | Required | Description | Default |
|---|---|---|---|
| council | Yes | A council name, part of one, or its GSS code, such as "Croydon" or "E09000008" |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| result | Yes | |
| council | Yes | |
| schemes | Yes | |
| candidates | Yes | |
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description still adds real behavioral context: the 12-month lookback for ended schemes, the fields each scheme carries, and the disambiguation behavior when multiple councils match (it returns them to choose from).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the resource and scope, then input form, then ambiguity handling. No filler, though the enumerated return fields edge slightly toward duplication of the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input flexibility, match disambiguation, and the status/time window of returned schemes, which is enough for an agent to call it correctly given that a full output schema exists and needs no restating. Only the missing when-to-use-vs-siblings guidance keeps it from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents that it accepts a name, partial name, or GSS code with examples. The description restates this input flexibility but adds no syntax, formatting, or matching rules beyond what the schema provides, so this is the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (lists) and resource (a council's licensing schemes) and scopes the content precisely: in force, starting soon, proposed, and ended in the last 12 months, each with area, dates, fee, source link and last verified date. This is far more specific than the sibling names check_property_licensing or licensing_coverage and lets an agent distinguish it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to invoke it (council name, partial name, or GSS code) and what happens on ambiguous matches, but never states when to prefer this tool over siblings like licensing_coverage or upcoming_licensing_changes. Usage is implied by the resource scope rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What’s coming: schemes proposed or starting soon, and recent changes to schemes in HouseFile’s records (started, ended, fee, dates or area changed), newest first. Optionally for one council, and for a number of months ahead and back (6 by default, at most 24). For all councils the lists stop at the 15 soonest schemes and the 10 latest changes, with the totals; ask for one council to see all of its own.
| Name | Required | Description | Default |
|---|---|---|---|
| council | No | A council name, part of one, or its GSS code | |
| within_months | No | Months ahead and back to look, 6 by default |
| Name | Required | Description |
|---|---|---|
| note | Yes | What the stages mean, and how to see more when a list was cut short |
| result | Yes | |
| council | Yes | |
| upcoming | Yes | Soonest first, then proposals with no start date by council; at most 15 when no council is given |
| candidates | Yes | |
| disclaimer | Yes | |
| within_months | Yes | |
| recent_changes | Yes | Newest first, at most 10 when no council is given |
| upcoming_total | Yes | How many schemes are proposed or starting soon; more than listed when the list was cut short |
| recent_changes_total | Yes | How many changes there were in the window; more than listed when the list was cut short |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the safety annotations, the description discloses ordering (newest first), default and maximum month ranges, and important truncation behavior: all-council queries are capped at 15 soonest schemes and 10 latest changes with totals, while single-council queries return all. These are exactly the behavioral details an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then moves efficiently into filters, defaults, and result limits. Every sentence carries useful information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, complete parameter schema, and output schema, the description provides all the context needed to call the tool correctly. It covers purpose, temporal scope, filtering, defaults, ordering, and truncation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters. The description adds meaningful semantics beyond the schema by explaining that omitting the council returns all councils, with truncation limits that do not apply when a single council is requested.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns upcoming licensing schemes and recent changes, with a specific temporal scope and ordering. It is distinguishable from siblings by focusing on upcoming/recent change records, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the optional council filter, the default and maximum lookahead/back window, and when to ask for a single council to see full results. It gives clear usage context but does not explicitly compare against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_property_licensing2 fields changedInput schema / properties / address_lineRemoved 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"
-}Input schema / properties / postcode / descriptionPrevious 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"licensing_coverage12 fields changedOutput schema / properties / checked_no_scheme_councilsAdded value: +{
+ "description": "Short names of the councils a person checked and found to run no additional or selective scheme. list_council_schemes gives the date",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / checked_no_scheme_countAdded value: +{
+ "type": "number"
+}Output schema / properties / council_count / descriptionAdded value: +"Every council the records cover, with schemes or checked and found to run none"Output schema / properties / councils / descriptionAdded value: +"Councils with published schemes. Councils checked and found to run none are in checked_no_scheme_councils"Output schema / properties / councils / items / properties / checked_no_schemeRemoved value: -{
- "type": "boolean"
-}Output schema / properties / councils / items / properties / countryRemoved value: -{
- "type": "string"
-}Output schema / properties / councils / items / properties / gss_codeRemoved value: -{
- "type": "string"
-}Output schema / properties / councils / items / properties / housefile_urlRemoved value: -{
- "type": "string"
-}Output schema / properties / councils / items / properties / name / descriptionAdded value: +"The council’s short name, as on HouseFile’s pages. list_council_schemes takes it as it is"Output schema / properties / councils / items / requiredPrevious value: -[
- "name",
- "gss_code",
- "country",
- "published_schemes",
- "in_force",
- "checked_no_scheme",
- "last_verified",
- "housefile_url"
-]New value: +[
+ "name",
+ "published_schemes",
+ "in_force",
+ "last_verified"
+]Output schema / properties / councils_with_schemesAdded value: +{
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "councils",
- "council_count",
- "published_scheme_count",
- "most_recent_verification",
- "note",
- "housefile_url"
-]New value: +[
+ "councils",
+ "checked_no_scheme_councils",
+ "council_count",
+ "councils_with_schemes",
+ "checked_no_scheme_count",
+ "published_scheme_count",
+ "most_recent_verification",
+ "note",
+ "housefile_url"
+]upcoming_licensing_changes10 fields changedOutput schema / properties / noteAdded value: +{
+ "description": "What the stages mean, and how to see more when a list was cut short",
+ "type": "string"
+}Output schema / properties / recent_changes / descriptionAdded value: +"Newest first, at most 10 when no council is given"Output schema / properties / recent_changes_totalAdded value: +{
+ "description": "How many changes there were in the window; more than listed when the list was cut short",
+ "type": "number"
+}Output schema / properties / upcoming / descriptionAdded value: +"Soonest first, then proposals with no start date by council; at most 15 when no council is given"Output schema / properties / upcoming / items / properties / applicabilityRemoved 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"
-}Output schema / properties / upcoming / items / properties / noteRemoved value: -{
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / upcoming / items / properties / summaryRemoved value: -{
- "type": "string"
-}Output schema / properties / upcoming / items / requiredPrevious value: -[
- "scheme_name",
- "scheme_type",
- "council",
- "stage",
- "applicability",
- "note",
- "expected_start_date",
- "end_date",
- "summary",
- "source_url",
- "last_verified_at",
- "housefile_url"
-]New value: +[
+ "scheme_name",
+ "scheme_type",
+ "council",
+ "stage",
+ "expected_start_date",
+ "end_date",
+ "source_url",
+ "last_verified_at",
+ "housefile_url"
+]Output schema / properties / upcoming_totalAdded value: +{
+ "description": "How many schemes are proposed or starting soon; more than listed when the list was cut short",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "result",
- "council",
- "within_months",
- "upcoming",
- "recent_changes",
- "candidates",
- "disclaimer"
-]New value: +[
+ "result",
+ "council",
+ "within_months",
+ "upcoming",
+ "upcoming_total",
+ "recent_changes",
+ "recent_changes_total",
+ "note",
+ "candidates",
+ "disclaimer"
+]check_property_licensing1 field changedOutput schema / properties / upcoming / items / properties / expected_start_date / descriptionAdded value: +"Null where the council hasn’t announced a start date"upcoming_licensing_changes1 field changedOutput schema / properties / upcoming / items / properties / expected_start_date / descriptionAdded value: +"Null where the council hasn’t announced a start date"check_property_licensing3 fields changedOutput schema / properties / upcoming / items / properties / applicabilityAdded 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"
+}Output schema / properties / upcoming / items / properties / noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / upcoming / items / requiredPrevious 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"
+]upcoming_licensing_changes3 fields changedOutput schema / properties / upcoming / items / properties / applicabilityAdded 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"
+}Output schema / properties / upcoming / items / properties / noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / upcoming / items / requiredPrevious 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"
+]check_property_licensinglicensing_coveragelist_council_schemesupcoming_licensing_changesRegEvidenceHub Premises: UK premises-licensing preflight for supported authorities.
Check a home to rent in England: rent, licensing, flood risk, energy rating and the free report.
Landlord rules for England by postcode: council licensing, the landlord register and the law, cited.
Planning constraints for English properties from official planning.data.gov.uk data, via Apify.
Add one secure layer between your agents and this server.
