Small Business Intelligence by Brick & Mortar — how it works, what it can do, and what to check before approving it.
No authentication required — add it as a custom connector in Claude (or any MCP-compatible client) using the URL above. Nothing to sign in to, no API key to generate.
Try it once connected:
Each tool covers a distinct piece of small-business analysis. They're designed to be used
individually or chained — run a few, then hand the results to compose_report to
assemble one polished write-up. Start with data_source_atlas: it's the one that
changes what the others are worth.
| Tool | What it does |
|---|---|
data_source_atlas | Turns a plain-English question about a place into a research plan naming the exact public record that settles it — the county parcel layer, Census establishment counts, a state licence roster, a BLS series — plus what the public record cannot answer at all. Resolves the jurisdictional fork (does this state even record sale prices?) before anything else. |
business_teardown | Full structured teardown of one named business — presence, review signal, competitive position, pricing, visibility gaps, prioritized recommendations. Start here for a single-business question. |
competitor_landscape | Maps the true competitive set for a category + metro — who's a real competitor vs. an adjacent player, positioning, saturation. |
review_intelligence | Mines public reviews for complaint/compliment themes, sentiment trajectory over time, and buyer-relevant red flags. |
local_visibility_audit | Scored local-search presence checklist — map-pack factors, listing consistency, category selection, site fundamentals. |
pricing_benchmark | Defensible local pricing comparison within a category, including how to normalize non-identical service bundles. |
broker_diligence_prep | Pre-diligence framework for brokers/buyers — SDE framing, current-multiple research method, red-flag checklist, seller questions. |
market_opportunity_scan | Gap analysis for a category × metro — underserved demand, oversaturation, and genuine whitespace vs. structurally-empty ground. |
compose_report | Assembles the outputs of prior tool calls into one client-ready report, tone- and structure-matched to the audience (owner, broker, buyer, investor). |
twin_cities_datasets | Lists the joined public-records datasets we publish for the seven-county Minneapolis–St. Paul metro — real row counts, column names, the cuts available, and the counties each one actually covers. |
twin_cities_records | Answers a question about one Twin Cities property or the whole market from those records — what it sold for, who owns it, what shares its lot line, whether it has a contamination file. Returns the true row count, six example rows and a link to the whole file. |
request_a_feature | The only tool here that sends rather than answers. Files a feature request, a data request or a correction straight to the person who builds this — when a question lands outside what the server holds, or an answer looks wrong. |
A capable model already knows how to reason about a small business. What it doesn't know is the operational trivia that lives in nobody's training data — and every item below produces a plausible wrong answer rather than an error, which is the whole problem with public data:
Touches predicate returns zero touching parcels instead of an error, so adjacency quietly becomes "this parcel touches nothing."src/tools/sources.ts and src/tools/federal_sources.ts in the repo.
Nine of these tools ship analytical methodology, not data; the two Twin Cities tools return real public records for the Minneapolis-St. Paul metro and are described under their own entries above. For the nine, every tool call returns a structured research framework — a named analytical lens, an ordered set of concrete research steps, the exact shape the finished deliverable should take, a quality rubric, and honest caveats. Your AI assistant reads that framework and then does the actual work itself: it runs its own web search, follows the procedure, and writes the deliverable.
Practically: ask your AI to research a business, it calls one of these tools, the tool hands back the framework for that kind of analysis, and your AI executes it live. That's also why the analysis is always current — there's no cached dataset to go stale.
We log a one-way hashed representation of the caller's IP address, rotated every UTC day, paired with a per-day call count. That's it for anything identity-shaped — no request bodies, no tool arguments, no business names or search queries, no conversation content. Full detail in the privacy policy. This exists only to support a metered free-usage tier that is not currently active — every call is allowed today, unlimited.
Separately, we keep an aggregate, non-identifying count of calls per tool per day, split by the kind of client (Claude, ChatGPT, a registry crawler…) read off the User-Agent — e.g. "business_teardown: 340 calls on 2026-08-09, 300 from Claude". It has no connection to the hashed-IP counter and carries no identity of any kind. Cloudflare's own request log additionally holds the JSON-RPC method and tool name (never arguments) for a few days — see /privacy.
None. The server makes zero calls to external APIs, databases, or third-party services. All research a tool call triggers happens in the calling AI's own session, not on our infrastructure.
None required. Per the MCP specification, authorization is optional — a server that doesn't require it is compliant by not implementing the OAuth flow at all, rather than serving misleading auth challenges. The codebase is architected so OAuth 2.1 + PKCE can be added later without restructuring, if a future paid tier needs it.
11 of the 12 tools are marked readOnlyHint: true in their MCP tool
annotations and are read-only in practice — they write nothing, delete nothing, and modify
nothing anywhere. Nine return a research framework and reach nothing; the two Twin Cities record
tools make one HTTPS GET to the published files at brickandmortar.dev, which is why those two carry
openWorldHint: true. Any searching or browsing the frameworks call for is done by the
calling AI with its own tools, not by this server.
request_a_feature is the exception and is annotated
readOnlyHint: false, because it does one thing: it sends the request you dictated to
a person's inbox. It is annotated destructiveHint: true because a sent message cannot be
recalled, so a client should confirm with you before it runs; it is not idempotent, it reads nothing, and it cannot be
used to reach anyone but us — the destination is fixed in the source and is not a parameter. Its
payload is bounded, it is rate-limited per caller per day, and the endpoint it posts to refuses
anything that does not carry this server's own credential. What it transmits is listed in full on
the privacy page.
Streamable HTTP over HTTPS, served from Cloudflare Workers. Origin and Host headers are
validated on every request to the /mcp endpoint to guard against DNS-rebinding-
style attacks.
Built and operated by Brick & Mortar AI (brickandmortar.dev), Saint Paul, MN. This MCP server is a free, standalone product — it is not a funnel into a paid offering, and using it does not require any relationship with Brick & Mortar's other services.
Questions, issues, or approval-review requests: reach Brick & Mortar AI via brickandmortar.dev.