Spain Open Data MCP

Market size in euros

market_size

Read-onlyIdempotent

Size the yearly market in euros for a business category in a Spanish place using households, INE spending, income adjustments, and competitor supply; returns an opportunity score.

Instructions

Size the yearly market for a business category in a place in Spain, in euros, with a range.

Market = households × INE household spending on the category × an income adjustment. Supply = competing businesses, calibrated against INE's company directory. Returns market per business and an opportunity score against the region (1.0 = same as the region), with every assumption listed. Assumptions can be overridden to test scenarios. Use for "how big is the market for X in Y" and "is Y under-served for X".

Input Schema

Name	Required	Description
`place`	Yes	Place name or INE code: municipality ('Valladolid' or '47186'), province ('41'; a bare name like 'Sevilla' means the city), autonomous community ('Cataluña' or 'CA09'), district ('4718603') or census tract ('4718603012'). 'Name, Province' picks between same-named towns.
`category`	Yes	Business category: restaurant, cafe, bar, fast_food, bakery, butcher, greengrocer, supermarket, pharmacy, optician, dentist, physiotherapy, hairdresser, beauty_salon, veterinary, gym, childcare, private_school, clothes, home. Plain words work too ('gyms', 'peluquerías').
`competitors`	No	Override the estimated number of competing businesses.
`capture_share`	No	Share of the market one business could win (0-1), to estimate obtainable revenue.
`spend_per_household`	No	Override INE's yearly spend per household on the category, in euros.

Output Schema

Name	Required	Description
`data`	Yes
`checks`	No
`sources`	Yes
`confidence`	Yes	Lowest confidence across inputs: high, medium or low. Never state a conclusion more strongly than this.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Oct 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), but the description adds real behavioral context: the underlying model (households × INE spend × income adjustment), supply calibration against INE's directory, that every assumption is listed, and that assumptions can be overridden for scenarios. It stops short of noting data recency or geographic coverage limits.

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?

Front-loaded with the core purpose in the first sentence, followed by methodology and return summary. Three short paragraphs with little waste, though the final paragraph blends usage triggers with output description rather than keeping them separate.

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?

Given the output schema exists and the input schema is fully documented, the description supplies the model mechanics, assumption-override capability, and usage triggers an agent needs. Nothing required to invoke or interpret the tool is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning by framing competitors, spend_per_household, and capture_share as overridable assumptions for scenario testing, which contextualizes why those optional params exist. It doesn't add unit or format detail beyond the schema.

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?

States a specific verb (size), resource (yearly market), scope (business category in a place in Spain), unit (euros) and output shape (with a range). It is clearly distinguishable from siblings like demographics, income, or businesses because it names the market-sizing operation explicitly.

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

Usage Guidelines4/5

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

Provides explicit trigger phrases: '"how big is the market for X in Y"' and '"is Y under-served for X"', plus a scenario-testing note via overrides. It gives clear context but doesn't name alternative siblings (e.g., demographics, businesses) or state when not to use it.

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

Deploy Server