UK Postcode Property Report MCP

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this creates an external Stripe Checkout link and the £2.99 price, but it omits whether link creation itself charges the user, link expiry, authentication needs, and handling of invalid postcodes.

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 front-loaded sentence with no waste. The action, price, and scope are stated immediately.

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 simple one-parameter tool, the description covers the action, cost, and subject. But with no output schema and no annotations, it should clarify the returned link's form or lifetime and the required postcode format to be fully 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 0%, so the description must compensate for the single parameter. It says 'one postcode' but does not add format, validation, or regional expectations, adding only minimal meaning beyond the parameter name and string type.

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 ('Create') and resource ('Stripe Checkout link') with the price and subject ('full report on one postcode'). It distinguishes the purchase-link action from sibling report/summary tools implicitly, but does not explicitly name or contrast 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: create this link when a user wants to buy the full report for a postcode. However, the description does not state when not to use it, prerequisites, or how it relates to postcode_report and postcode_summary.

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 does well: it discloses the paid nature and exact price (£2.99 one-time), the auth requirement, and the degraded no-token behavior. It omits rate limits, whether the charge is re-applied on repeat calls with the same token, and failure modes for invalid postcodes.

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 most decisive fact ('PAID (£2.99 one-time)') before the feature list, so an agent can triage cost immediately. The long comma-separated inventory of data domains is dense but each item is a genuine capability distinction; only the list length risks losing the auth/fallback sentences at the end.

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?

No output schema exists, and the description compensates by naming the return format ('JSON + markdown') and the no-token return value. For a paid, two-parameter tool this is nearly complete; only the invalid-postcode and repeat-charge behavior remain 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 coverage is 50% (only access_token is described in the schema), but the description compensates by explaining where the token comes from and that a Bearer header is an accepted alternative. The postcode parameter receives no additional semantics beyond its name, leaving the 50% gap only partially covered.

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 concrete verb/resource pair ('Full UK Postcode Property Report') and enumerates the exact data domains returned (Land Registry sales, flood, crime, EPC, CQC, planning, amenities). The 'Full' qualifier plus the 3-month/median specifics implicitly contrast with the sibling postcode_summary, though it never names that sibling directly.

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?

Clearly states the precondition (access_token from /buy via Stripe Checkout) and the fallback behavior when no token is supplied ('returns a checkout link'), which tells the agent exactly how to respond to an unauthenticated call. It stops short of explicitly routing the agent to the buy_report_link or postcode_summary siblings by name.

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 does substantial work: it discloses cost (free), data windows (3 years, ~800 m radius, last month), and that a paid upsell link is included in the response. It does not cover failure modes for malformed or partial postcodes, which is the remaining gap.

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, front-loaded with the 'FREE' signal, then a tight enumeration of outputs, closing with the upsell behavior. Every clause earns its place and nothing is padded.

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?

No output schema exists, so the description must cover return content, and it does list the data categories plus the included purchase link. It stops short of describing response shape or what happens when data is unavailable for a postcode, which an agent would want.

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 sole parameter is documented with an example format, so the schema already does the heavy lifting. The description adds nothing about postcode syntax or normalization beyond what the schema states, 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+resource (property snapshot for one UK postcode) and enumerates exactly what the snapshot contains: sold price, sales count, flood band, crimes, EPCs, amenities. The 'quick snapshot' vs 'full report' framing lets an agent distinguish it from postcode_report and buy_report_link without opening any 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?

Usage is only implied: 'FREE' and 'Quick' versus 'the full report' signals this is the lightweight/free preview path, but the description never explicitly says when to choose postcode_report instead or when the paid path is warranted. The agent must infer the routing.

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