Skip to main content
Glama

Small Business Intelligence by Brick & Mortar

by io.github.2016judea

Data Source Atlas

data_source_atlas
Read-only

Given a real question about a local market or a specific property, returns a source-first RESEARCH PLAN: which public record actually settles the question, how to reach it directly (county parcel GIS, Census CBP/ACS/permits, BLS series, state registries, licences, inspections), what the answer will be worth, and what the public record cannot answer at all. Use this BEFORE researching a local market — it is the difference between reading whatever a search engine surfaced and pulling the administrative record that settles it.

Example invocations:

  • "Where would I actually find what 1420 Grand Ave in Saint Paul last sold for?"

  • "I want to know if Wichita has room for another dog daycare — what should I pull?"

  • "How do I find out who really owns this building and what else they own?"

  • "What public data would tell me if this neighborhood is actually growing?"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
placeYesThe specific geography — 'Hennepin County, MN', 'Wichita, KS', 'the 78704 ZIP'. State matters more than people expect: it decides whether sale prices exist at all.
questionYesThe real question, in plain words — e.g. 'is there room for another coffee shop in Bend' or 'what did the building at 412 Main last sell for'. Not a dataset name; the point of this tool is to work out which records answer a question you can only phrase in English.
already_triedNoWhat you already looked at and what it failed to answer, if anything. Keeps the plan from re-recommending a dead end.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYes
noticeNoPresent 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.
caveatsYes
subjectNo
frameworkYes
output_schemaYes
quality_rubricYes
research_procedureYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by specifying that the output is a research plan rather than actual data, and by noting limitations ('what the public record cannot answer at all'), which helps set expectations.

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?

The core purpose and usage guidance are front-loaded in the first two sentences, and the example invocations are genuinely illustrative. It is longer than minimal, but each component adds value for an agent deciding whether and how to call it.

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?

With an output schema present and 100% parameter coverage, the description does not need to restate return structure. It provides enough context: what the tool does, when to use it, what to pass, and realistic examples. No critical information is missing for correct invocation.

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 the parameters are well documented in the schema itself. The description reinforces the intended usage with concrete example questions and places, but it does not add substantial meaning 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?

The description states a specific verb ('returns') and resource ('source-first RESEARCH PLAN'), and clarifies the plan's contents: which public record settles the question, how to reach it, what the answer is worth, and what it cannot answer. This clearly distinguishes it from sibling data-retrieval tools like twin_cities_records or market_opportunity_scan.

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 description explicitly says to use this tool BEFORE researching a local market and explains why it matters. It gives multiple example invocations that illustrate appropriate inputs, but it does not explicitly name sibling tools or state when to use them instead.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools target clearly distinct tasks — teardowns, competitor mapping, pricing, reviews, visibility, and data lookup are all separable. The main ambiguity is that business_teardown is a comprehensive single-business tool that overlaps with local_visibility_audit, review_intelligence, and pricing_benchmark, and twin_cities_datasets vs twin_cities_records could be confused at first glance.

Naming Consistency4/5

Names are almost uniformly descriptive snake_case noun phrases like business_teardown, competitor_landscape, and market_opportunity_scan. The exceptions are compose_report and request_a_feature, which are verb-first, creating a minor but noticeable convention break.

Tool Count5/5

Twelve tools is well within the ideal range for a server with this scope. Each tool covers a meaningful part of the small-business investigation workflow, from research planning and data lookup to analysis, diligence, and report assembly.

Completeness4/5

The surface covers the full investigative lifecycle: data sourcing, market and competitor analysis, business teardown, pricing, reviews, local visibility, broker diligence, and client-ready reporting. Minor gaps exist around direct valuation/financial modeling and non-Twin-Cities dataset access, but data_source_atlas and request_a_feature help agents work around them.

Resources