Skip to main content
Glama

Prospects: size industry niches in a region (prototype)

size_niches
Read-onlyIdempotent

PROTOTYPE. Size up to 5 industry niches in a region by how many businesses Google Maps lists for each, to judge whether prospecting one is a quick campaign that runs out fast or a large market that needs a longer plan. Counts the whole region box by box (Google returns at most 60 per search), so it reaches past what find_prospects shows; 'at least' when the count hit its limit. The count includes neighbouring trades that mention the work, so each niche also gets a SPECIALISTS estimate: the share of businesses named for the trade, read from listings in up to 10 areas spread across the region, applied to the count; the size band uses it. Each niche also gets a sample of the 20 top listings: share with a website, share under 10 reviews, median reviews, average rating, share named for the trade, share without a storefront. Region: a city, state or region with its country, e.g. 'Sydney NSW', 'Queensland, Australia'. No credits used. Takes up to about a minute for big regions. Follow with find_prospects in the chosen niche to get the businesses themselves.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "niches": "<niches>",
      "region": "<region>"
    },
    "name": "size_niches"
  }
}

Input Schema

NameRequiredDescriptionDefault
nichesYesThe trades or kinds of business, e.g. ['fence builder', 'solar installer', 'pool builder']
regionYesCity, state or region, with country if ambiguous, e.g. 'Sydney NSW', 'Perth WA', 'Texas'
sampleNoAlso describe the top 20 listings per niche (websites, reviews, ratings, share named for the trade, share without a storefront)
name_wordsNoOptional, per niche: the words a specialist's business name contains, when the niche's own words don't work, e.g. {"solar installer": ["solar", "energy"]}. Default: the niche's own words without generic ones (builder, installer, services …).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behaviour beyond them: no credits used, ~1 minute runtime for big regions, Google's 60-per-search cap and the box-by-box sweep, the 'at least' qualifier when a count hits its limit, and the fact that counts include neighbouring trades. It also discloses the specialist-estimate methodology and the 20-listing sample. This is unusually rich disclosure for a read-only tool.

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 'PROTOTYPE' and the purpose, and every sentence carries information (limits, methodology, time, cost, next step). Some sentences are heavily packed with nested clauses, which slightly hurts scannability, but there is little filler for a tool of this complexity.

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 complex, nested-parameter tool with no output schema, the description covers what the return contains (counts and limits, specialist estimate and size band, sample metrics such as website share, reviews, rating, storefront share). Runtime, cost, and the follow-up call are all stated, leaving no material gap for correct invocation.

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 coverage is 100%, so the baseline is 3. The description goes further by explaining the conceptual role of name-matching (the SPECIALISTS estimate derived from 'the share of businesses named for the trade'), which gives the name_words parameter meaningful purpose, and shows region formats ('Sydney NSW', 'Queensland, Australia'). It stops short of documenting per-parameter edge cases, but adds real value over 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 and resource ('Size up to 5 industry niches in a region by how many businesses Google Maps lists') and immediately frames the decision it supports. It explicitly positions itself against the sibling find_prospects ('reaches past what find_prospects shows', 'Follow with find_prospects'), so an agent can disambiguate without opening either schema.

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?

Gives the when ('to judge whether prospecting one is a quick campaign that runs out fast or a large market that needs a longer plan') and names the follow-up tool and workflow step ('Follow with find_prospects in the chosen niche to get the businesses themselves'). Clear routing between the sizing tool and the enumeration tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.