Skip to main content
Glama

Compare areas for a business

compare_areas
Read-onlyIdempotent

Rank Spanish areas by business opportunity for a category, comparing market per business and competitor counts to decide where to open or where services are lacking.

Instructions

Rank areas by opportunity for a business category: where is there most market per business.

Each area gets a yearly market in euros, estimated competing businesses and an opportunity
score against its region, all with ranges. Areas are ranked by the cautious (low) end of
the score; areas too small for the category are left out and counted. Use for "where in
Valladolid should I open a gym" or "which towns in Málaga province lack pharmacies".

Input Schema

NameRequiredDescriptionDefault
levelNo'district' or 'tract' within a municipality; 'municipality' within a province or region.auto
limitNoHow many areas to return, best first.
withinYesA municipality (compares its districts or tracts) or a province or region (compares its municipalities).
categoryYesBusiness 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').

Output Schema

NameRequiredDescriptionDefault
dataYes
checksNo
sourcesYes
confidenceYesLowest confidence across inputs: high, medium or low. Never state a conclusion more strongly than this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds real behavioral detail beyond them: the scoring basis (ranked by the cautious/low end), the outputs per area (yearly market in euros, competing businesses, opportunity score with ranges), and the exclusion rule with counting. Only latency/cost behavior is unaddressed.

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 sentence one, then ranking mechanics, then examples. Sentence two is a dense run-on ('all with ranges') but every clause carries information; no padding.

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?

Despite an output schema existing, the description still conveys the shape of results (market estimate, competitors, opportunity score) and the ranking/exclusion semantics an agent needs to interpret them correctly. Nothing material is missing for a read-only analytics tool.

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 all four parameters are already documented in the schema. The description adds marginal meaning, only implicitly linking 'towns' vs 'districts' to the level parameter and mentioning the small-area exclusion that relates to limit.

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 (rank) and resource (areas) plus the exact metric framing: 'most market per business'. This is clearly distinguishable from siblings like market_size or catchment, which do not rank areas against a category.

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?

Gives concrete usage triggers via two natural-language example questions ('where in Valladolid should I open a gym', 'which towns in Málaga province lack pharmacies'). It does not, however, explicitly state when to prefer a sibling such as market_size or catchment instead.

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