UK Land Registry MCP

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

With no annotations, the description carries the full burden and does disclose key traits: the tool is paid, costs £0.49, returns a Stripe Checkout URL, and notes that soft-offer outbound is off. However, it does not explain authorization needs, whether invoking it alone charges the user, or what happens after checkout.

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 two short sentences with no wasted text, front-loading the product identity and then the price/return behavior. It is appropriately sized for a simple checkout-oriented tool.

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?

It explains what the pack contains, that it is paid, and that the call returns a checkout URL. But with no output schema, it does not fully describe the response beyond the URL or clarify the workflow after checkout, such as whether redeem_pack is needed.

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 both parameters are already documented in the schema. The description does not add format or behavioral meaning for 'area' or 'size', so the baseline of 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?

The description identifies a specific paid product, names its contents (Price Paid sample, summary stats, risk_flags), and states the immediate return (Stripe Checkout URL). This distinguishes it reasonably well from sibling pack tools, 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?

There is no explicit guidance on when to use this tool versus siblings such as price_paid_pack or price_paid_discover. The word 'Paid' and the listed contents imply the use case, but no conditions, exclusions, or alternatives are stated.

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?

With no annotations, the description carries the burden and does substantial work: it discloses that access is free with no key, the data source (HM Land Registry Price Paid Data), the geographic scope, the comparison window, and the 30+ sales-per-period threshold that filters results. It stops short of describing failure modes, caching/freshness beyond the 6-month window, or the shape of the returned lists.

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-loads the key constraint ('FREE, no key') and then packs methodology into a tight sentence; every clause about window, median, and sales threshold earns its place. The trailing 'Also GET /drops/price-moves (JSON) or ?format=text' is slightly wasteful and confusing, since the schema exposes no format parameter and this tool presumably wraps that endpoint already.

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 two-parameter read tool with no output schema, the description is nearly sufficient: it says what is compared, over what period, filtered how, and from what source. The remaining gap is the `direction` enum and how the risers/fallers lists are structured in the response, neither of which is covered 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 coverage is 50%: `limit` is documented in the schema (default 10, max 25) while `direction` (both/risers/fallers) has no description at all. The description's phrase 'top risers and fallers' partially illuminates what `direction` selects, but it never names the parameter or explains that 'both' is the default, so it only half-compensates for the gap.

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+resource: the biggest house price moves by postcode district, including the exact metric (median sold price, latest 6 complete months vs same months a year earlier) and coverage (England & Wales). It does not distinguish itself from the sibling pack tools (area_comps_pack, price_paid_pack, price_paid_discover), so an agent has no basis in the description for choosing among them.

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 rather than stated: an agent can infer this is for ranking districts by price change, and the 30+ sales filter quietly tells it this is a statistical comparison rather than raw listings. There is no explicit when-to-use, when-not-to-use, or reference to alternatives among the sibling 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?

With no annotations, the description carries the full burden. It usefully discloses the 5-result free cap and 24h caching, which an agent would otherwise not know, but says nothing about auth, rate limits beyond the cap, error behavior, or data freshness beyond the cache window. 'Soft-Offer outbound is OFF' is unexplained jargon that adds little for an agent unfamiliar with the domain.

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 purpose and packed into three short fragments with little waste. The trailing 'Soft-Offer outbound is OFF' is opaque and arguably does not earn its place without explanation.

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 data-retrieval tool with no output schema, the description never indicates what a returned sale record contains (price, date, address, property type), leaving the agent guessing about response shape. The caching and cap notes are helpful, but the opaque soft-offer clause and missing return-value context leave real gaps.

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 both parameters (area, size) are already documented in the schema. The description adds only the example format 'M1' and reinforces the free max of 5, which the schema already states. 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?

States a specific verb and resource: free preview of up to 5 HM Land Registry Price Paid sales by postcode/outcode/town, with an example (M1). The word 'peek' and the 5-result cap implicitly separate it from the sibling packs (price_paid_pack, area_comps_pack), but the description never names those alternatives 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?

'Free peek' plus 'max 5 for free' implies this is the sample/trial path and that a full pack exists elsewhere, but no sentence says when to choose this over price_paid_pack or area_comps_pack. The agent must infer the routing from the tool names alone.

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?

With no annotations, the description carries the full burden, and it does disclose the key behavioral facts that the response is a Stripe Checkout URL and that the price is £0.49 — genuinely useful for a purchase-initiating tool. However, it omits whether the call charges the user, whether it is idempotent, or what happens on repeat invocation, and the "Soft-Offer outbound" clause is unexplained.

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 short sentences with the payment behavior front and center — the size is appropriate. The final clause, "Soft-Offer outbound is OFF," is unexplained shorthand that does not earn its place without a definition.

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?

The tool has no annotations and no output schema, so the description is the only source of behavioral context, yet it leaves the core workflow undefined: what the pack delivers after payment, whether the URL must be shown to the user, and how redeem_pack relates. For a paid-transaction tool this is a significant gap.

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 both `area` and `size` are already documented in the schema. The description's "UK postcode / outcode / town" phrasing corroborates the `area` semantics but adds no syntax, format, or default information beyond what the schema states.

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?

"Paid Price Paid pack" largely restates the tool name, and the description never explains what data the pack actually contains. It does add one concrete fact — that the output is a Stripe Checkout URL priced at £0.49 — which tells an agent the call initiates a purchase rather than returning records. But it draws no distinction from price_paid_discover or redeem_pack.

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 statement of when to use this vs. price_paid_discover (presumably the free variant) or redeem_pack (presumably the post-purchase retrieval). "Soft-Offer outbound is OFF" is undefined jargon that gives no actionable routing guidance. The agent must guess the intended workflow.

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?

With no annotations, the description carries the full behavioral burden. It implies a state-changing redemption but says nothing about idempotency, what happens if the session was already redeemed or is unpaid, whether authentication/ownership of the session is required, or what the call produces (a pack entitlement? credits?). Those are exactly the facts an agent needs before invoking a mutation.

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 short sentences, no filler, with the action stated first and the parameter hint second. The only structural weakness is that the leading phrase "Instructions to redeem" reads like a doc pointer rather than a description of the operation.

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?

The tool is simple (one required param, no output schema), but for a redemption flow the missing outcome information matters: what the agent gets back, whether the pack becomes usable by the sibling pack tools, and what failure modes exist. With no annotations and no output schema to fall back on, the description leaves an agent guessing at the result of a write operation.

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 the schema already documents session_id as a Stripe Checkout id in cs_... form. The description adds only that the value comes "from checkout", a marginal sourcing hint beyond the schema. 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?

The description names a specific resource (a paid Stripe Checkout session) but the framing "Instructions to redeem..." is ambiguous about whether the tool performs the redemption or merely returns instructions for doing so. It also gives no hint of how this relates to the sibling 'pack' tools (tenders_pack, tender_score_pack), which an agent would reasonably wonder about given the shared naming.

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?

"Pass session_id from checkout" is the only usage cue and it addresses argument sourcing, not when to call the tool. There is no guidance on preconditions (session must be paid, not already redeemed) or on when an agent should prefer or avoid this tool relative to its siblings.

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