Skip to main content
Glama

Small Business Intelligence by Brick & Mortar

Twin Cities Datasets

twin_cities_datasets
Read-only

Lists the public-records datasets Brick & Mortar publishes for the seven-county Minneapolis-St. Paul metro, with real row counts, column names, the filtered cuts available, and the counties each one actually covers. Free, no account. Call this FIRST to learn what can be answered, then call twin_cities_records to ask it. These are joined county and federal records — parcels and lot lines, recorded sale prices, owners, rental licences, contamination files, business counts by trade, census tracts.

Example invocations:

  • "What Twin Cities property data do you have access to?"

  • "Is there anything on contamination or storage tanks in Minneapolis?"

  • "What columns are in the recorded-sales dataset?"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
aboutNoOptional plain-words filter — 'sales', 'who owns it', 'contamination'. Matches dataset titles and subjects. Omit to list everything.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYes
answerYes
centreNo
noticeNoPresent ONLY when the request was denied by usage policy instead of executed. When present, no other field carries a result.
sampleNoAt most six example rows. Never report these as the complete result.
caveatsYes
columnsNo
datasetNo
subjectNo
coverageNoThe counties this dataset actually holds. Coverage is not uniform across datasets.
datasetsNo
scope_labelNo
download_urlNoFetch this for the complete file.
documented_atNoPage documenting this dataset's source, full column list and stated limits.
matching_rowsNoThe true number of rows that match. `sample` shows at most six of them.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover read-only and non-destructive behavior. The description adds valuable context beyond annotations: 'Free, no account,' which addresses authentication needs, and 'real row counts...the counties each one actually covers,' which sets accuracy expectations. It also clarifies the workflow role of the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by workflow guidance, data scope, and practical examples. Every sentence earns its place; the structure is tight and scannable without fluff.

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?

Given the simple optional parameter, strong annotations, and existing output schema, the description provides everything an agent needs: what the tool does, what data it covers, how it relates to its sibling, authentication posture, and example queries. No critical context is missing.

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?

The schema describes the single 'about' parameter with 100% coverage, including examples and the note 'Omit to list everything.' The tool description's example invocations reinforce this but do not add significant new meaning beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Lists the public-records datasets Brick & Mortar publishes for the seven-county Minneapolis-St. Paul metro.' It further distinguishes itself from the sibling twin_cities_records by saying 'Call this FIRST to learn what can be answered, then call twin_cities_records to ask it.'

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?

The description gives explicit workflow guidance: call this tool first to discover what data exists, then call twin_cities_records to query it. It also provides concrete example invocations showing the kinds of questions this tool can answer, making when-to-use unambiguous.

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.

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.