Market Pulse

Overview Schema Source Related Servers Discussions Admin

compare_two_areas

Read-only

Compare two UK areas head-to-head: see which has more new companies in a chosen industry and which grew faster, with counts for matched periods and rounding-aware tests of difference.

Instructions

Head to head: which of two places has more new companies in this industry, and which grew faster? Gives each area's count for a period (default the latest four quarters) and the earlier one, a test of whether one has more, and a test of whether one area's share of the two together changed (that is, one grew faster, or fell less if it fell). Both tests allow for rounding. Formation-agent addresses are left out.

Input Schema

Name	Required	Description	Default
`area`	Yes	A council area, region or nation code from find_area
`against`	No	Compare with the same quarters a year before (default; '2026-Q1 to Q3 against 2025-Q1 to Q3'; a period longer than four quarters goes back whole years, e.g. eight quarters against the eight before, so the two never overlap) or with the period of the same length just before. Answers name both periods	year_before
`sic_codes`	Yes	SIC codes from find_sic: 5 digits, a 2-4 digit group such as '812' for all of it, or a ready-made bundle id such as 'ai-and-data' (approximate). Choose codes for the activity asked about, e.g. cleaning: ['812']; digital and tech: ['62011', '62012', '62020', '62090', '63110', '63120', '58290']; every industry: ['all']. The choice can change the answer, so say which codes you used.
`other_area`	Yes	A second, non-overlapping council area, region or nation code
`to_quarter`	No	YYYY-Qn ending the later period; default the last complete quarter
`from_quarter`	No	YYYY-Qn starting the later period; default four quarters before to_quarter's end, so a whole year
`include_closed`	No	True (default): count companies registered in each period, including those since dissolved, so an older period isn't shrunk by closures. False: still open only

Output Schema

Name	Required	Description
`rows`	Yes
`answer`	Yes	The summary plus both must-quote caveats, ready to pass on as one text.
`caveats`	Yes	The first two are must-quote: include them in any answer.
`summary`	Yes	Quote this sentence word for word.
`excluded`	Yes
`snapshot_date`	Yes
`snapshot_sha256`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description appropriately spends its words on substance: the default period (latest four quarters), the two statistical tests, the rounding tolerance, and the exclusion of formation-agent addresses. These are non-obvious behavioral facts an agent could not get from the schema, though the response shape is also partially restated despite an output schema being present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause and the remaining content is dense but earned, covering periods, tests, and the formation-agent exclusion. The middle sentence is convoluted ('that is, one grew faster, or fell less if it fell') and could be tightened, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter read-only comparison tool with a full output schema and 100% schema coverage, the description supplies everything an agent needs to call it correctly: what is compared, the default and alternative baselines, the tests performed, and the population exclusion. Nothing material is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including detailed text for 'against', 'sic_codes', 'include_closed', and the quarter bounds, so the schema already carries parameter meaning. The description adds only the period default ('default the latest four quarters'), which largely duplicates what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ('Head to head: which of two places has more new companies in this industry, and which grew faster'), making the two-area comparison unambiguous. It does not, however, explicitly distinguish itself from the sibling compare_area_with_great_britain or rank_areas_against_great_britain, so the reader must infer the distinction from 'two places'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by the head-to-head framing: this is the tool for comparing two specific areas on new-company formation. There is no explicit statement of when to prefer it over compare_area_with_great_britain or rank_areas_against_great_britain, and no prerequisites (such as needing codes from find_area/find_sic) are stated in the description itself.

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

Deploy Server