Small Business Intelligence by Brick & Mortar

by io.github.2016judea

Market Opportunity Scan

market_opportunity_scan

Read-onlyIdempotent

Returns a research framework, not the finished analysis: the procedure, output schema and quality rubric for a gap analysis of a category x metro — how to tell underserved demand, oversaturation and genuine whitespace apart using only public signals, for someone deciding whether/where to open, expand, or invest.. This tool fetches no data; the calling model runs the procedure with its own web search and produces the result.

Example invocations:

"Is there whitespace for a new brewery taproom in the North Loop, Minneapolis?"
"Scan the nail salon market in Aurora, CO for underserved demand"
"Where in Wichita, KS is full-service restaurant demand outrunning supply?"

Input Schema

Name	Required	Description	Default
`category`	Yes	The business category/vertical to scan for whitespace, e.g. 'coffee shop', 'massage spa'.
`city_metro`	Yes	City + state/region defining the market, e.g. 'Aurora, CO'.

Output Schema

Name	Required	Description
`tool`	Yes
`notice`	No	Present ONLY when the request was denied by usage policy instead of executed. When present, every other field is an empty placeholder and must not be reported as a framework.
`caveats`	Yes
`subject`	No
`framework`	Yes
`output_schema`	Yes
`quality_rubric`	Yes
`research_procedure`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Discloses the critical, non-obvious trait that this tool 'fetches no data' and that the calling model must run the procedure with its own web search. Annotations cover the read-only/idempotent safety profile, but this execution-model disclosure is something only the description could carry and it is stated plainly.

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-loads the most important fact (framework, not finished analysis) in the first clause, and the example invocations earn their space. It is somewhat dense and contains a stray double period ('invest..'), but overall the structure is purposeful.

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

Completeness4/5

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

For a framework-returning tool with a 2-param schema, full schema coverage and an output schema, the description covers the tool's nature and execution model thoroughly. The main thing an agent might still wonder is how to distinguish it from adjacent analysis siblings, but the core is complete.

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% and both parameters are documented in the schema with examples, so the baseline is 3. The description frames the inputs as 'category x metro' but adds no format or constraint detail beyond what the schema already provides.

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 deliverable (a research framework/procedure, output schema and rubric for a category x metro gap analysis) and explicitly distinguishes what it is not ('not the finished analysis'). An agent can tell it apart from siblings like competitor_landscape or pricing_benchmark from the text alone.

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?

The three example invocations give concrete, unambiguous usage context, and the target audience is stated ('someone deciding whether/where to open, expand, or invest'). It stops short of naming sibling alternatives or explicit when-not-to-use exclusions, so it lands just below the top.

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

All Small Business Intelligence by Brick & Mortar tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.