Market Pulse

Overview Schema Source Related Servers Discussions Admin

compare_area_with_great_britain

Read-only

Compare an industry's growth in a chosen UK council area with Great Britain using company counts, significance-tested area share, location quotient, and quarterly trend.

Instructions

One-call brief: is this industry growing faster or slower in this area than across Great Britain? Compares a period (default the latest four quarters) with the same quarters a year before, or the period just before: the area's count, Great Britain's, the area's share of GB with a significance test, how concentrated the industry is here (location quotient), and the quarterly trend. Formation-agent addresses are left out on both sides. If you picked this area from rank_areas_against_great_britain, quote the ranking's verdict instead: this tool tests one area on its own. To say which of two areas grew faster, use compare_two_areas.

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.
`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

A4.5/5.0

Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses substantive behavioral traits: formation-agent addresses are excluded on both sides, a significance test is applied to the area's share of GB, a location quotient is computed, and the meaning of include_closed is spelled out in the schema. It stops short of describing performance, rate limits, or responses, but the output schema already covers return shape. Strong but not exhaustive.

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

Conciseness5/5

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

Front-loaded with the question the tool answers, followed by what it returns, its exclusions, and delegation to siblings. No sentence is filler; the length is proportionate to a six-parameter analytical tool with several exclusions to communicate.

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?

The description covers scope, default periods, data exclusions, and sibling routing, while the input schema (100% coverage) and output schema handle parameters and return values. Nothing an agent needs to select or correctly invoke this tool is missing.

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%, so the schema already documents every parameter including the against enum, SIC code formats, and quarter ranges. The description's only added semantic is the default comparison window and the caveat that the SIC code choice can change the answer, which is a useful but modest contribution over structured data.

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

Purpose5/5

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

The opening sentence states a specific analytical question with explicit verb+resource: it compares one industry's growth in one area against Great Britain. It also names what it is not (a ranking, or a two-area comparison), so an agent can distinguish it from rank_areas_against_great_britain and compare_two_areas immediately.

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

Usage Guidelines5/5

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

Explicit routing rules are given: if the area came from rank_areas_against_great_britain, quote the ranking's verdict instead, and to compare two areas use compare_two_areas. It also discloses the default baseline (latest four quarters vs. same quarters a year before) and the alternative baseline, so the agent knows the selection conditions rather than inferring them.

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

Deploy Server