WhereToLive London open data

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description goes beyond them by naming data sources (Environment Agency, planning.data.gov.uk, police.uk) and disclosing the 'unknown' fallback where a borough publishes no data, plus the straight-line-distance caveat and the 'single home can differ' warning.

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 content is dense and largely earns its place because there is no output schema, but it is delivered as one sprawling semicolon-chained sentence. The critical caveats ('unknown', 'a single home can differ') sit at the very end rather than being front-loaded.

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 no output schema, the description must enumerate return content, and it does so comprehensively: flood zone, planning constraints, crime/deprivation/tenure, schools and stations, commute times, council tax bands, and the district page. The only gap is any indication of latency, coverage limits, or what happens for a non-London or invalid postcode.

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?

Only one parameter exists and schema coverage is 100%, so the schema fully documents the postcode field with its own example. The description repeats the format hint ('E17 4QH') without adding syntax the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

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 opens with a specific verb and resource ('Open-data facts at one full London postcode'), which is far more informative than the tautological title. Granularity ('one full London postcode') implicitly separates it from the district-level siblings, but no sibling is named explicitly, so an agent must infer the distinction.

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?

There is no when-to-use or when-not statement, and none of the six siblings (find_london_district, get_district_profile, etc.) are referenced as alternatives. The agent gets a data inventory but no routing guidance for choosing this tool over the district or commute tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds data provenance ('open-data figures') and clarifies that the hub/commute column is optional, but omits freshness, aggregation caveats (e.g. 'main borough's' rent roll-up), and any rate/coverage limits.

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 core scope (side-by-side, 2-6 districts, London baseline) before the metric list, and every token is informative. It is a single long run-on sentence, which slightly hurts scannability of the metric list but wastes nothing.

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 no output schema, the description carries the return-value burden and does so well by enumerating the metric columns, the London-wide baseline, and the optional commute column. It would be stronger with a note on output shape (per-district rows) and data recency, but it is largely sufficient for correct invocation.

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%: districts, hub and bedrooms are all documented inline, including the 2-6 item bound and the enum values. The description only echoes '2 to 6 districts' and the optional hub commute, adding no syntax or format meaning beyond the schema, so baseline 3 applies.

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 verb 'compare' (side-by-side) plus resource 'London postcode districts' is specific, and the enumeration of metrics leaves no doubt what the tool computes. It implicitly separates itself from single-district tools like get_district_profile and ranking tools like rank_london_districts via the '2 to 6 districts and London as a whole' scope, but never names a sibling explicitly.

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?

Usage is only implied: the side-by-side framing and multi-district scope suggest this is the tool for cross-district comparison. There is no explicit when-to-use/when-not, and no pointer to get_district_profile (single area) or rank_london_districts (ordered ranking) as the alternatives an agent should weigh.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavior beyond that: a match cap of 15, per-match borough attribution, and disclosure of how each match was made, which helps the agent interpret results.

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?

Two sentences with zero filler; the resolution scope is front-loaded and the sibling routing follows. Every clause carries information.

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 no output schema, the description usefully characterizes the return (up to 15 matches, boroughs, match rationale). It stops short of describing no-match or ambiguous-query behavior, but is otherwise sufficient for a single-parameter lookup tool.

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% and its parameter description already enumerates the same input forms (place, borough, station, outward code, postcode) with examples. The description adds no format or ambiguous-input handling beyond the schema, so baseline 3 applies.

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 (resolve) and resource (place names, boroughs, stations, codes to London postcode districts) and explicitly distinguishes itself from the sibling find_london_districts. An agent can route correctly 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.

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

Explicitly names the alternative for screening on prices, commute, crime, schools, flood or rent, with the selecting condition. However, it does not address overlap with the sibling check_london_postcode, which also sounds postcode-oriented — a small gap in routing guidance.

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

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

Goes well beyond the readOnly/idempotent annotations: each match carries qualifying figures, sample sizes, and a page URL; uncheckable districts are 'counted, not hidden'; and when nothing matches it returns near-misses sorted closest-first with the ruling-out criterion. The flats-retirement caveat is also disclosed. This is rich operational context.

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 purpose followed by criteria enumeration and then the two valuable behavioral clauses (uncheckable districts, no-match fallback). The criteria list partially duplicates the schema, but the description stays readable and most sentences carry non-redundant information.

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?

For a 12-parameter, no-required, no-output-schema tool, it explains the AND-combination semantics and the return payload (figures, sample sizes, URLs, near-miss fallback), so the agent knows what comes back. Only the interaction/precedence among the six sibling tools is left unaddressed.

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 the schema already documents all 12 parameters thoroughly (including enums, ranges, sort defaults). The description mostly re-lists the same criteria, adding only the houses-only qualifier for the price comparison. Baseline 3 is appropriate.

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?

Opens with a specific verb and resource ('Find the London postcode districts') plus the conjunctive screening model ('meet several open-data criteria at once'). This clearly separates it from siblings like find_london_district, rank_london_districts, and compare_london_districts without the agent needing to open schemas.

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?

Usage is implied by 'meet several criteria at once' (AND-filter screening), and it does state one constraint ('Houses only'). But it never names when to prefer rank_london_districts or compare_london_districts, which is a real risk given six siblings. No explicit when-not guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds useful context instead: data source (TfL Journey Planner), the 09:00 weekday departure assumption, quickest-first ordering, and that the district's quickest sector is included. It stops short of describing failure behavior for unrecognised districts.

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 core purpose, source, timing assumption and ordering are front-loaded in the first clause. The trailing 12-hub enumeration is long, but it is the only place the readable hub names appear, so it largely earns its space.

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 no output schema, the description does carry the return-format burden and handles it well (minutes, quickest first, quickest sector). Missing only edge-case detail such as what happens for an invalid or unrecognised district, which the check_london_postcode sibling could have been referenced for.

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 baseline is 3, but the description adds genuine value by mapping each enum slug to its human-readable hub name (e.g. canary-wharf to Canary Wharf, city-of-london to Bank / Liverpool Street / Moorgate), clarifying ambiguous codes the raw enum does not explain.

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 states a specific verb+resource with full scope: door-to-door public transport minutes from a London postcode district to named work hubs. It clearly distinguishes the tool from siblings like compare_london_districts and get_district_profile by naming the origin/destination framing and the quickest-first output.

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?

Usage is implied by the scope (one district against one or all hubs), and the hub omission default ('leave out for all 12' via schema) is helpful. However, there is no explicit guidance on when to use this versus compare_london_districts or get_district_profile, nor any stated precondition that the district must be valid.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is low and the description clears it: it discloses data provenance (HM Land Registry, police.uk, Ofsted, Environment Agency, ONS, Census 2021, IMD 2025), a 12-month sales window and five-year medians, and that every block carries caveats and a source citation. That is real context beyond the annotations, though it does not state failure behavior for an unknown district.

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 opening clause is well front-loaded and each enumerated block is arguably load-bearing for a data-heavy tool, but the body is a long run-on enumeration with no bullets or grouping, which makes it harder to parse than it needs to be. Content is justified; structure is not.

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?

There is no output schema, so the description bears the burden of describing the return payload, and it does so thoroughly across every data block, including windows, definitions and citation URL. The remaining gap is what happens on an invalid or non-London district input, which is not addressed anywhere.

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 the 'district' parameter is fully documented with format and examples in the schema; the description adds only the implicit scope ('one London postcode district') and no syntax or edge-case detail. This is the baseline 3 for a schema that does the heavy lifting.

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 (profile) and a precise resource/scope ('one London postcode district'), and the enumerated data blocks make it obvious this is a single-district deep-dive rather than a lookup or comparison. It never names a sibling (compare_london_districts, find_london_district, check_london_postcode), so the differentiation is inferred from scope rather than stated.

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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, despite five plausible siblings that overlap (compare_london_districts, rank_london_districts, check_london_postcode). The agent must infer from 'one district' that this is not the multi-district or validation tool.

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

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

Annotations already establish readOnly/idempotent/non-destructive, so the description's job is to add semantics beyond that. It does: data provenance (police.uk per 1,000 residents, Land Registry median sold price, Ofsted Outstanding), the flats exclusion, and that ranks are London-wide rather than within the borough filter. It doesn't describe the returned row shape, but annotations carry the safety profile.

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?

A single dense paragraph that front-loads the metric list, with no filler sentences. It is slightly long because of the parenthetical source annotations, but every clause carries information an agent needs to pick a metric correctly.

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?

For a 6-parameter read-only ranking tool with no output schema, the description covers metric semantics, the hub dependency, the cut-off, and the scope of ranking. The main remaining gap is the shape of returned rows (district name, score, rank), which an agent must infer.

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 3 is the baseline, but the description adds meaning beyond the schema: it defines what each metric rank actually measures and clarifies that reverse yields 'most expensive, highest crime, longest commute first', and that hub is required for shortest_commute. These tie parameters to behavior rather than restating field names.

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 (rank) and resource (London postcode districts) plus the exact set of ranking metrics with their data sources. An agent can immediately distinguish it from compare_london_districts or find_london_district, which are lookups rather than rankings.

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?

Explains each metric's meaning and conditional usage (shortest_commute 'needs hub', flats excluded from cheapest_houses), and describes the optional borough filter and reverse ordering. It does not explicitly name a sibling tool or say when to prefer this over compare_london_districts, so it stops short of a 5.

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