UK Salary Benchmarks MCP

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

With no annotations or output schema, the description carries the full burden. It usefully discloses that the tool is free, defines the statistic (median full-time gross annual pay), and names the data source (ONS ASHE), but omits caveats such as small-area suppression, postcode-to-local-authority mapping approximations, currency, and return format.

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 compact sentence plus the 'FREE' marker, front-loaded with the cost signal and then the substance. It is efficient, though 'FREE.' is stylistically awkward.

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 one-parameter lookup tool, the description gives enough to select it, but with no annotations and no output schema it should say more about what comes back (a single number? GBP? missing-data behavior) and any input format expectations.

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 0%, so the description must compensate. It adds meaningful context by saying the input is a UK postcode that is resolved to a local authority, but does not specify postcode format, case, or precision expectations beyond 'UK postcode'.

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 precisely what is returned: median full-time gross annual pay for the local authority area of a UK postcode, citing ONS ASHE. This is a specific metric and scope that an agent can distinguish from salary_percentiles, though it does not name that 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?

There is no guidance on when to use this versus salary_percentiles, compare_areas, or offer_check. The description leaves the agent to infer the use case from the metric 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?

No annotations exist, so the description carries the full burden, yet it only discloses the 10-area cap. It is silent on the subscriber-token auth requirement (only visible in the schema), rate limits, error behavior, and what the comparison returns.

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 sentence with the constraint and use cases front-loaded and no filler. The 'PRO' prefix is terse and slightly opaque but does signal tiering.

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 annotations and no output schema, the description should do more to explain the comparative return shape and the paid-tier auth requirement. It covers what the tool compares but leaves how it authenticates and what comes back to inference.

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 75% and documents measure, pattern and access_token, so the description's main added value is the 'up to 10 postcodes' limit, which the schema does not state. It adds nothing about the measure/pattern semantics or default behavior beyond the schema.

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?

Names a specific verb (compare) and resource (median and percentile pay across postcodes), plus the cap of up to 10 areas. It does not explicitly name its siblings (area_salary, salary_percentiles) to steer selection, but the multi-area comparison scope implicitly distinguishes it.

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 use cases ('for relocation, hiring and pricing') which imply when to reach for it, but never states when to use area_salary or salary_percentiles instead, nor any prerequisites beyond the 'PRO' tag.

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?

No annotations exist, so the description carries the full burden. It usefully discloses that the result is an approximation rather than an exact figure, and the 'PRO.' marker hints at a subscription gate. It says nothing about output shape, precision limits, or what happens with out-of-range salaries or unknown 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 framed as the question it answers, with the key qualifier 'approximate percentile' up front. No filler, no restatement of the tool name beyond the tier marker.

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 5-parameter, unannotated tool with no output schema, the description leaves gaps: it does not say what the response looks like (a percentile value, a band, a range), nor explain the subscription/token prerequisite beyond 'PRO.' The core intent is conveyed, but not everything needed to call and interpret it confidently.

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 60%: measure, pattern, and access_token are documented in the schema, but the two required parameters (postcode, salary) have no descriptions. The description implicitly ties salary to 'local pay distribution' and postcode to locality, which partially compensates, but adds no format or unit details for either.

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 computation: locating a given salary within the local pay distribution for a postcode, returning an approximate percentile. That is a clear verb-and-resource combination an agent can act on. It does not, however, distinguish itself from siblings like salary_percentiles or area_salary, leaving the agent to infer the difference.

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 by the question phrasing: it fits evaluating a concrete offer (salary + postcode). There is no explicit when-to-use, no when-not-to-use, and no pointer to salary_percentiles or area_salary for alternative needs. The 'PRO.' prefix signals a paid tier but offers no 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?

With no annotations, the description carries the full burden; it does disclose the returned statistics (10th-90th percentile, mean, median) and that results are scoped to a postcode area. It says nothing about read-only semantics, pricing/access-tier implications beyond 'PRO', rate limits, or error behavior for an invalid postcode.

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 that packs the tier marker and the returned metrics efficiently. It is terse but 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?

For a 6-parameter data-query tool with no annotations and no output schema, the description covers the returned metrics and dimensions but omits the auth/token prerequisite and any hint of output shape. Adequate, not 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 coverage is 67%, above the 50% threshold, so the schema largely documents the parameters. The description echoes the dimension names (pattern, measure, sex, basis) but adds no format detail beyond what the schema already says; access_token semantics live only in the schema.

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 resource (percentile + mean/median pay for a postcode's area) with the breakdown dimensions, so an agent knows exactly what data it returns. The 'PRO' prefix signals a paid-tier endpoint. It does not, however, distinguish itself from siblings like area_salary or compare_areas.

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 gives no when-to-use guidance, no exclusions, and never names area_salary, compare_areas, or offer_check as alternatives. Usage is only implied by the data it returns.

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