Free joined public records for small business and CRE: Twin Cities parcels, sales, licences
Scored across 16 tools
Most tools have clearly distinct purposes, but twin_cities_lookup and twin_cities_records overlap on single-property queries, and business_teardown overlaps with specialized analysis tools like review_intelligence and local_visibility_audit. Descriptions provide guidance, but some ambiguity remains.
All tool names use snake_case consistently, which is a clear convention. However, the set mixes verb-first (e.g., bring_your_document, compose_report) and noun-first (e.g., business_teardown, review_intelligence) patterns, so it is not a strict verb_noun scheme.
With 16 tools, the count is slightly above the typical 3–15 range for a well-scoped server. Each tool covers a distinct facet of the platform, so the set is not bloated, but it is on the heavier side.
The tool surface covers data access (datasets, lookup, records), analysis (teardown, reviews, competitor, pricing, visibility, market opportunity), diligence prep, reporting, and feedback channels. No obvious gaps for a small business intelligence platform.
Reads a document the person has — a P&L, a lease, a comp set, a schedule of locations, a member list, a story's addresses, a single claim — against the Minneapolis–St. Paul public record, and returns a table that cites the file behind every cell. This is the half of the platform the public record cannot do alone: their private file, our joined records, one answer. Free, no account. The document is read in the request, answered, and dropped — nothing is stored on either side.
Get the slug and what to bring from what_we_have_for_you (cards with api_tool=true list bring). Pass the text exactly as they gave it; do not summarise a P&L before sending it. Tell them in one line what was sent and that it was not kept.
Example invocations:
"Here's the P&L the seller sent — what does this business actually earn?" → tool 'pl'
"Grade my comps against the county's own sales" → tool 'compgrade'
"Check this line in my story: 'the building sold for $4.2M in March'" → tool 'claim-check', claim
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The document as plain text — a pasted P&L, a lease, a list of addresses one per line, a comp table. Their content, untouched. For 'claim-check' use `claim` instead. | |
| tool | Yes | A tool slug from a what_we_have_for_you card where api_tool is true — e.g. 'pl', 'leasecheck', 'compgrade', 'claim-check', 'registercheck'. | |
| claim | No | For tool 'claim-check' only: the one sentence to check against the record, exactly as written. | |
| context | No |
| Name | Required | Description |
|---|---|---|
| next | No | Which tool on this server answers each kind of card. Follow these rather than improvising. |
| tool | Yes | |
| cards | No | |
| links | No | |
| roles | No | |
| answer | Yes | |
| notice | No | Present ONLY when denied by usage policy. Nothing else in the payload is a result. |
| result | No | |
| status | Yes | |
| caveats | Yes | |
| subject | No | |
| engagements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/openWorld, but the description adds non-obvious traits the annotations can't convey: it's free with no account, the document is 'read in the request, answered, and dropped — nothing is stored on either side', and the caller should confirm in one line what was sent and that it wasn't kept. The idempotentHint=false annotation is not addressed, but nothing contradicts the stated behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and the operational instructions are tight, but it spends a sentence on pitch/marketing ('their private file, our joined records, one answer') that doesn't help an agent invoke the tool. The example invocations earn their place; the sloganeering does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers the privacy lifecycle, cost, required slug discovery, and the text-vs-claim branch. For a 4-parameter tool with a nested `context` object, the remaining gap is that the `context` sub-fields (fromMonth, radiusFeet, subjectAddress) are only explained in the schema and tied to 'tools that ask since when' in the description only loosely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage the schema carries most parameter detail, but the description adds material routing semantics: `tool` is not an enum and must be sourced from what_we_have_for_you, `claim` replaces `text` for 'claim-check', and text must be passed verbatim ('do not summarise a P&L before sending it'). The `context` sub-fields are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (reads a person's document against the Minneapolis–St. Paul public record) and a concrete output (a table that cites the file behind every cell). It also positions itself against the public-record-only siblings by framing itself as 'the half of the platform the public record cannot do alone', so an agent can distinguish it from twin_cities_lookup/twin_cities_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear invocation prerequisite ('Get the slug and what to bring from what_we_have_for_you', cards with api_tool=true list `bring`) and three worked example invocations mapping real-world asks to the `tool` slug. It doesn't state when NOT to use it (e.g. when the data is already public and twin_cities_lookup suffices), so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-diligence framework for a business broker or buyer evaluating a target: SDE framing (why the discretionary-earnings figure, not net income or raw EBITDA, is the relevant number, and what typically gets added back), a category multiple range the model must research fresh and date-stamp (never a hardcoded table), a public-signal red-flag checklist run before any financials are shared, and a prioritized seller-question list built from the specific gaps the research actually surfaces.
Example invocations:
"Prep me for diligence on a brewery taproom listed in Minneapolis, MN"
"What questions should I ask the seller of a hair salon in Wichita, KS before I make an offer?"
"This restaurant is asking $650K — what red flags should I check before taking that seriously?"
"I'm looking at a nail salon in Tampa, FL asking $310K — sanity-check that against category multiples before I meet the seller"
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category if known — determines the relevant SDE-multiple range. | |
| city_metro | Yes | City + state/region, e.g. 'Denver, CO'. | |
| asking_price | No | Listed asking price, if known — used to sanity-check against the multiple range, never to validate it. | |
| business_name | Yes | The target business's name. |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the readOnly/idempotent annotations: it states the model must research category multiples fresh and date-stamp them, explicitly rejects hardcoded tables, and specifies that the red-flag checklist runs before financials are shared and seller questions are built from research gaps. This gives the agent a clear picture of the tool's internal process and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: a lead sentence enumerating the four framework components followed by four example invocations. The examples earn their place by clarifying acceptable request phrasings, though the opening sentence is heavy with parentheticals and could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity, the description covers purpose, deliverables, behavioral constraints, and practical invocation examples, while the output schema handles return-value expectations. An agent has everything it needs to decide whether to call this tool and how to phrase the request correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all four parameters, so the baseline is 3. The description adds illustrative context by showing concrete city_metro formats ('Minneapolis, MN', 'Wichita, KS'), asking_price examples ('$650K', '$310K'), and how category and asking_price are used for sanity-checking against multiples, which helps an agent formulate effective calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a pre-diligence framework with four concrete deliverables: SDE framing, a category multiple range, a red-flag checklist, and a prioritized seller-question list. The example invocations show exactly what the tool does, making it easy to distinguish from siblings like business_teardown 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example invocations establish clear usage contexts: preparing for diligence on a specific business, asking seller questions before an offer, checking red flags before taking an asking price seriously, and sanity-checking against category multiples before meeting the seller. It does not explicitly name sibling alternatives or state when not to use the tool, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a research framework, not the finished analysis: the procedure, output schema and quality rubric for a structured teardown of ONE named small business — digital presence, review signal, competitive position, pricing posture, visibility gaps, and prioritized, evidence-cited recommendations. Start here for any single-business question.. This tool fetches no data; the calling model runs the procedure with its own web search and produces the result.
Example invocations:
"Run a teardown of Mucci's Italian in Saint Paul, MN"
"Tear down The Gray Duck Tavern (bar) in Minneapolis and tell me what's actually broken"
"I'm thinking about buying Sunrise Nails in Denver, CO — give me a teardown before I look deeper"
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category if known (e.g. 'nail salon', 'brewery taproom'). If omitted, step 2 of the procedure confirms it — don't guess from the name alone. | |
| city_metro | Yes | City + state/region, e.g. 'Saint Paul, MN' — narrows the trade area and comp set. | |
| business_name | Yes | The business's name as it appears on its own signage/website, not a guess. |
| 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 |
Returns a research framework, not the finished analysis: the procedure, output schema and quality rubric for mapping the local competitive set for a category + metro — true competitors vs. adjacent players, a positioning matrix, and saturation signals.. This tool fetches no data; the calling model runs the procedure with its own web search and produces the result.
Example invocations:
"Map the competitive landscape for coffee shops in Saint Paul, MN"
"How saturated is the nail salon market in Aurora, CO?"
"Who are the real competitors to a new brewery taproom opening in the North Loop, Minneapolis?"
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The business category/vertical, e.g. 'nail salon', 'brewery taproom'. | |
| city_metro | Yes | City + state/region defining the trade area, e.g. 'Denver, CO'. | |
| radius_note | No | Optional — a specific radius or neighborhood if the default trade-area logic in the procedure shouldn't apply. |
| 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 |
Returns a research framework, not the finished analysis: the procedure, output schema and quality rubric for assembling results already in the conversation into one client-ready report — section order, executive-summary rules, evidence-citation standards, and tone guidance matched to the audience. The calling model writes the report; this tool returns only the structure.. This tool fetches no data; the calling model runs the procedure with its own web search and produces the result.
Example invocations:
"I've run a teardown and a review-intelligence pass on this restaurant — compose it into a report for the owner"
"Assemble everything we've found on this brewery into a broker-facing diligence report"
"Turn the teardown and competitor landscape into a report I can hand an investor"
| Name | Required | Description | Default |
|---|---|---|---|
| audience | Yes | Who will read this report — drives section order, tone, and what gets emphasized vs. cut. | |
| business_name | Yes | The business the report is about. | |
| completed_analyses | Yes | The completed write-ups from any prior tool calls this session, to be assembled — not re-researched. |
| 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 |
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 it before researching a local market, to find the administrative record that settles the question.
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?"
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | The specific geography — 'Hennepin County, MN', 'Wichita, KS', 'the 78704 ZIP'. State matters more than people expect: it decides whether sale prices exist at all. | |
| question | Yes | The 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_tried | No | What you already looked at and what it failed to answer, if anything. Keeps the plan from re-recommending a dead end. |
| 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 |
Returns a research framework, not the finished audit: a scored checklist of what to check in a business's local search presence — map-pack factors, listing consistency, category selection, site fundamentals — and in what order. This tool reads no listing; the calling model runs the checks with its own web search.
Example invocations:
"Run a local visibility audit on Fern & Fig Nail Bar in Cedar Rapids, IA"
"Why doesn't Steel Toe Brewing show up when someone searches 'brewery near me' in Louisville?"
"Give me a scored GBP/NAP checklist for a hair salon in Aurora, CO before I redo their listing"
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category if known — narrows which map-pack searches are the right ones to check. | |
| city_metro | Yes | City + state/region, e.g. 'Aurora, CO'. | |
| business_name | Yes | The business's name as it appears on its own signage/website. |
| 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 |
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?"
| 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'. |
| 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 |
Returns a research framework, not the finished analysis: the procedure, output schema and quality rubric for a defensible local pricing comparison within a category — how to normalize across differing service bundles, and what to do when competitors don't publish prices at all. It holds no prices itself.. This tool fetches no data; the calling model runs the procedure with its own web search and produces the result.
Example invocations:
"Benchmark gel manicure pricing across nail salons in Denver, CO"
"Is this brewery's pint pricing in line with the Twin Cities taproom market?"
"Build a pricing comparison for full-service restaurants in Wichita, KS when most don't list prices online"
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The business category/vertical, e.g. 'massage spa', 'full-service restaurant'. | |
| services | No | Specific services/items to benchmark if known (e.g. ['30-min massage', 'gel manicure']) — otherwise the procedure derives a comparable bundle. | |
| city_metro | Yes | City + state/region defining the comparison market, e.g. 'Wichita, KS'. |
| 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 |
Sends a feature request, a data request or a correction straight to the person who builds this server — free, no account, and it reaches a real inbox. Use it whenever this server falls short of what the user actually wanted: a question it cannot answer, a dataset or column it does not hold, a city or sector it does not cover, or an answer from one of these tools that looks wrong. Reaching a wall is not the end of the turn; offer to file it.
Before calling, ask for what you do not have — what they were trying to do, which city/sector/dataset it concerns, and whether they want a reply at an email address. Do not demand any of it: file what you have. Pass their REQUEST and their EMAIL exactly as they wrote them, never a paraphrase or a corrected address; write context yourself. Tell them what you filed in one line afterwards so they can correct you, and never say it was sent unless status came back filed.
Example invocations:
"I wish this could tell me the lease rate — can you ask them to add it?"
"Do they cover Duluth? No? Tell them I want it."
"That sale price looks like the wrong year — report it to whoever runs this."
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | feature = make a tool do something it does not do. data = hold or expose a record we do not. correction = a tool here gave a wrong or misleading answer. Default: feature. | |
| context | No | Your summary of what they were actually trying to do when they hit this. This one is yours to write. | |
| request | No | The person's own words, VERBATIM — do not summarise, rewrite or tidy them. Omit only if they have not said it yet; you will be asked for it. | |
| subject | No | The city, sector, dataset or tool name this is about — 'Duluth', 'dental practices', 'twin_cities_records'. | |
| reply_email | No | Optional, and only if they offer it. VERBATIM — never guess, complete or correct an address. Omit it rather than approximate it. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| filed | No | |
| notice | No | Present ONLY when the request was denied by usage policy instead of executed. When present, nothing was filed. |
| status | Yes | `needs_more` means nothing was sent and you should ask the person the question in `message`, then call again. `not_filed` means it failed — do NOT tell them it was submitted. |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that the request goes to a real inbox, is free and requires no account, and must be filed even if the agent lacks all details ('Do not demand any of it: file what you have'). It also mandates verbatim transmission of user request/email, agent-written context, and never claiming success unless status came back 'filed'. These are behavioral rules the annotations cannot capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every section earns its place: purpose, usage triggers, pre-call info gathering, verbatim rules, post-call reporting, and examples. The core purpose is front-loaded in the first sentence, and the examples clarify the intended scenarios without padding. This is appropriate density for a tool with nuanced behavioral requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 0 required, and an output schema, the description is essentially complete. It tells the agent when to call it, how to gather and transmit information, what to do with missing fields, and how to report the outcome to the user. It even references the output status ('status came back filed'), which is sufficient because the output schema provides the formal structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the verbatim requirement for REQUEST and EMAIL and states 'write context yourself,' but the schema already says essentially the same thing ('VERBATIM — do not summarise', 'This one is yours to write'). The examples illustrate possible values, but they do not add semantically new parameter meaning beyond a high-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Sends a feature request, a data request or a correction straight to the person who builds this server.' It then enumerates the exact fall-short scenarios (question it cannot answer, dataset it does not hold, wrong-looking answer), which clearly separates it from the data-retrieval sibling tools. The name and title are reinforced rather than merely restated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use conditions: 'Use it whenever this server falls short of what the user actually wanted,' with concrete examples and the instruction that 'Reaching a wall is not the end of the turn; offer to file it.' It does not name alternative tools or explicitly state when not to use it, but the fall-short framing implies the sibling data tools are preferred when they can satisfy the request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a research framework, not the finished analysis: the procedure, output schema and quality rubric for mining public reviews for signal — a complaint taxonomy, theme extraction, sentiment trajectory over time, the differentiators customers actually cite, and red flags for a buyer. It does not read any review itself.. This tool fetches no data; the calling model runs the procedure with its own web search and produces the result.
Example invocations:
"Mine the reviews for Al's Breakfast in Minneapolis for real patterns, not just a star rating"
"Perfect Image Salon in Wichita has a 4.6 average — check whether that's stable or masking a bad last 90 days"
"I'm evaluating The Anchor Room (bar) in Saint Paul, MN as a buyer — what do the reviews show about staffing turnover or an ownership change that the rating alone doesn't?"
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category if known — helps set expectations for review volume/velocity norms. | |
| city_metro | Yes | City + state/region, e.g. 'Wichita, KS' — disambiguates same-named businesses. | |
| business_name | Yes | The business's name as it appears on its own signage/website. |
| 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 |
Asks a person at Brick & Mortar to read the public record for them, for a fixed fee: a site screen for a lender or environmental consultant, a diligence packet on a deal, a register check across a landlord's portfolio, a weekly work route for a contractor. Call with no arguments to see the engagements, their prices and turnaround — those come from the live page, never from memory. Call with engagement, who, email and detail to file the enquiry; a person replies by email. Nothing is quoted, charged or scheduled here.
Offer this only after the free tools have been tried or when the person asks for someone to do the work. Before filing, confirm with them what will be sent. Pass their EMAIL and DETAIL exactly as written. Never say it was sent unless status is filed.
Example invocations:
"Can someone there just run this site for me? I'm an SBA lender."
"I want the diligence packet on this deal — here's my email."
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | What the person does, in their words. Required to file — it decides which records a person pulls. | |
| No | Where a person should reply. VERBATIM — never guess, complete or correct an address. Required to file. | ||
| detail | No | The site, deal, portfolio or route in their own words — addresses, the deadline, what they need to know. VERBATIM. | |
| engagement | No | An engagement id from the list this tool returns when called empty — e.g. 'site-screen', 'diligence', 'register-check', 'route'. |
| Name | Required | Description |
|---|---|---|
| next | No | Which tool on this server answers each kind of card. Follow these rather than improvising. |
| tool | Yes | |
| cards | No | |
| links | No | |
| roles | No | |
| answer | Yes | |
| notice | No | Present ONLY when denied by usage policy. Nothing else in the payload is a result. |
| result | No | |
| status | Yes | |
| caveats | Yes | |
| subject | No | |
| engagements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the catalogue and prices come from the live page, never from memory; a human replies by email; nothing is quoted, charged or scheduled; and the agent must not claim success unless the returned status is 'filed'. The only mild tension is destructiveHint=true versus 'nothing is charged', but that reflects a real external side-effect (a person is dispatched), not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the two invocation modes, then constraints, then two concrete example utterances; every sentence carries operational content. It runs long for a four-parameter tool, but the length is justified by the real-world side effects being governed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an open-world, non-idempotent tool with a full schema and an output schema, the description covers what an agent needs: how to discover engagements, what each argument must contain, the human-reply flow, and the status check that gates any success claim. Return-value detail is rightly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: `engagement` must be an id taken from this tool's own empty-call listing, `who` determines which records the person pulls, and email/detail must be passed verbatim rather than normalized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: files an engagement enquiry so a person at Brick & Mortar performs a paid read of the public record. It also distinguishes the two modes of the tool (empty call lists engagements and prices; populated call files the enquiry), so an agent can tell it apart from the free research siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('only after the free tools have been tried or when the person asks for someone to do the work'), a precondition ('confirm with them what will be sent'), and a hard reporting rule (
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?"
| Name | Required | Description | Default |
|---|---|---|---|
| about | No | Optional plain-words filter — 'sales', 'who owns it', 'contamination'. Matches dataset titles and subjects. Omit to list everything. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| answer | Yes | |
| centre | No | |
| notice | No | Present ONLY when the request was denied by usage policy instead of executed. When present, no other field carries a result. |
| sample | No | At most six example rows. Never report these as the complete result. |
| caveats | Yes | |
| columns | No | |
| dataset | No | |
| subject | No | |
| coverage | No | The counties this dataset actually holds. Coverage is not uniform across datasets. |
| datasets | No | |
| scope_label | No | |
| download_url | No | Fetch this for the complete file. |
| documented_at | No | Page documenting this dataset's source, full column list and stated limits. |
| matching_rows | No | The true number of rows that match. `sample` shows at most six of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful context beyond that: 'Free, no account' discloses access requirements, and the promise of 'real row counts, column names, filtered cuts' clarifies what the response contains. This exceeds the annotation baseline without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but every section earns its place: scope, return contents, access, usage ordering, dataset examples, and invocation examples. It is front-loaded with the core purpose, and the examples are useful rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety traits, the description supplies everything needed to select and invoke the tool correctly: what it lists, how it differs from twin_cities_records, when to call it, and realistic example queries. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single optional 'about' parameter already well-documented as a plain-words filter with examples and omission behavior. The description does not add parameter-level detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb—'Lists'—and a clear resource: public-records datasets for the seven-county Minneapolis-St. Paul metro. It further specifies exact return details (row counts, column names, filtered cuts, counties covered), making its purpose unmistakable and distinct from the sibling twin_cities_records tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this FIRST to learn what can be answered, then call twin_cities_records to ask it.' This directly tells the agent when to use this tool versus the primary sibling, providing both ordering and routing guidance. Example invocations reinforce the intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One address in the Minneapolis–St. Paul metro → what the public record says about that parcel, in one call: land use, build year, assessed value, last recorded sale, any MPCA contamination or storage-tank file, and the parcels that touch it with how many owners they have. Each field is a value or a miss WITH ITS REASON — 'the county records no build year' — never a blank. Free, no account, nothing stored. Use it the moment an address comes up; then twin_cities_records for the surrounding market.
Example invocations:
"What do you know about 1420 Grand Ave, Saint Paul?"
"Is there anything on file for the building at 2900 Lyndale Ave S?"
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A street address in the seven-county Minneapolis–St. Paul metro. Include the city — 'Grand Ave' exists in several of them. |
| Name | Required | Description |
|---|---|---|
| next | No | Which tool on this server answers each kind of card. Follow these rather than improvising. |
| tool | Yes | |
| cards | No | |
| links | No | |
| roles | No | |
| answer | Yes | |
| notice | No | Present ONLY when denied by usage policy. Nothing else in the payload is a result. |
| result | No | |
| status | Yes | |
| caveats | Yes | |
| subject | No | |
| engagements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the description isn't carrying the safety burden. It still adds real behavioral value: free, no account, nothing stored, and the guarantee that misses come back with a reason rather than a blank. It doesn't discuss rate limits or result size, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core mapping and dense with useful detail; the two example invocations anchor usage cheaply. The middle sentence is long and slightly run-on, but every clause carries information, so it stays efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not enumerate return structure, and it correctly focuses on geography, coverage scope, and miss-handling behavior. For a single-parameter lookup with rich annotations, nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema coverage is 100% — the schema already explains to include the city because 'Grand Ave' exists in several of them. The description adds no additional syntax or format guidance for the address field, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific input (one address in the Minneapolis–St. Paul metro) and an enumerated set of outputs (land use, build year, assessed value, last sale, MPCA contamination/storage-tank file, adjoining parcels with owner counts). The scope is narrow and unmistakable, so an agent can distinguish it from a general records tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it 'the moment an address comes up' and names the follow-on alternative, twin_cities_records, for the surrounding market. Trigger condition and routing are both stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answers a question about the Minneapolis-St. Paul metro from joined public records — what a property sold for and when, who owns it and what else they hold, what shares its lot line, whether it has a contamination or storage-tank file, who is licensed to trade there, how the neighbourhood's census tract compares. Give an address to answer about one property and its surroundings; omit it to ask about the whole market cut. Returns the true matching row count, up to six example rows, and a link to the complete file.
Example invocations:
"What did 1420 Grand Ave, Saint Paul last sell for?"
"What commercial property sold within half a mile of 2900 Hennepin Ave, Minneapolis?"
"Does 500 Washington Ave S have a contamination file, and who owns it?"
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | A scope key from that dataset's `scopes`. Omit for the dataset's first cut. | |
| address | No | A street address inside the seven-county metro, to answer about ONE property instead of the whole market. Include the city after a comma when the street name is common — 'Grand Ave' exists in several of these cities. | |
| columns | No | Column keys to return. Omit for the dataset's default set. | |
| dataset | Yes | A dataset id from twin_cities_datasets — e.g. 'sales', 'owners', 'adjacency'. | |
| within_ft | No | Radius in feet around `address`. Default 5280 (one mile), capped at 26400. |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| answer | Yes | |
| centre | No | |
| notice | No | Present ONLY when the request was denied by usage policy instead of executed. When present, no other field carries a result. |
| sample | No | At most six example rows. Never report these as the complete result. |
| caveats | Yes | |
| columns | No | |
| dataset | No | |
| subject | No | |
| coverage | No | The counties this dataset actually holds. Coverage is not uniform across datasets. |
| datasets | No | |
| scope_label | No | |
| download_url | No | Fetch this for the complete file. |
| documented_at | No | Page documenting this dataset's source, full column list and stated limits. |
| matching_rows | No | The true number of rows that match. `sample` shows at most six of them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is well covered. The description adds useful behavioral context: results come from joined public records, and the tool returns a true matching row count, up to six example rows, and a link to the complete file. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and immediately communicates the two usage modes and the output contract. The em-dash list of query types is dense but informative, and the three example invocations all earn their place. It is slightly long, but no sentence feels wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, full schema coverage, rich annotations, and an output schema, the description covers the essential invocation modes (property-level vs market-level), the output shape, and the domain of records. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already thoroughly documents `address`, `within_ft`, `columns`, `scope`, and `dataset`. The description reinforces the address omission rule and provides examples, but it does not add meaning materially beyond what the input schema already provides. A 3 is appropriate given the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Answers a question') and a concrete resource: joined public records for the Minneapolis-St. Paul metro, with an enumerated range of query types such as sales, ownership, contamination, licensing, and census comparison. The address-or-market distinction and concrete example invocations make the tool's purpose unambiguous. It does not explicitly name a sibling tool, but the question-answering role is clearly distinct from the analysis/scoping siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the main usage branch: give an `address` to answer about one property and its surroundings, omit it to ask about the whole market. The example invocations illustrate realistic query shapes. It does not spell out when to prefer sibling tools, but the dependency on twin_cities_datasets is visible in the schema and the market-vs-property guidance gives clear conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The front door of brickandmortar.dev, as a tool. The platform is organised by WHO YOU ARE — an SBA lender, a business buyer, a landlord, a contractor, a journalist, a site selector, an appraiser, a city planner, 18 roles — and each role has a shelf of cards: joined public-records datasets for the Minneapolis–St. Paul metro, tools that read a file you bring against those records, a one-address lookup, and fixed-fee engagements where a person reads the record for you. Call with no arguments to see the roles; call with role to get that shelf, each card tagged with which tool on this server answers it.
Call this FIRST when someone says what they do, or asks what we can do for them. Ask what they do if they have not said — the shelf depends on it. Everything free here is free with no account.
Example invocations:
"I'm an SBA lender in Minneapolis — what do you have?"
"What can this do for a landlord?"
"Show me the shelf for a business buyer."
| Name | Required | Description | Default |
|---|---|---|---|
| who | No | If you do not know the id yet: what the person does, in their words — 'I underwrite restaurants', 'I'm buying a plumbing company'. Returns the closest roles to pick from. | |
| role | No | A role id from the list this tool returns when called with no arguments — e.g. 'sba', 'buyer', 'landlord', 'press'. |
| Name | Required | Description |
|---|---|---|
| next | No | Which tool on this server answers each kind of card. Follow these rather than improvising. |
| tool | Yes | |
| cards | No | |
| links | No | |
| roles | No | |
| answer | Yes | |
| notice | No | Present ONLY when denied by usage policy. Nothing else in the payload is a result. |
| result | No | |
| status | Yes | |
| caveats | Yes | |
| subject | No | |
| engagements | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world semantics, so the safety profile is handled. The description adds real behavioral value beyond that: results are free with no account required, and the two-call discovery flow (no args to list roles, then role to get a shelf) is spelled out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The operational content is front-loaded and each sentence carries the role list, the card taxonomy, or the call pattern. It is somewhat verbose with marketing phrasing ('the front door of brickandmortar.dev') and a slightly redundant example block, but nothing is truly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because an output schema exists, return values need not be described, and the description instead fills the real gaps: role enumeration, the card categories, the two-step invocation pattern, and the cost/auth model. An agent has everything needed to call this correctly as a first step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds actual semantics: the intended sequencing (call with no arguments first to learn role ids), and the fuzzy-vs-exact distinction implied by 'who' versus 'role'. It clarifies workflow rather than merely restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete retrieval verb and resource: it returns the list of supported roles when called with no arguments, or the 'shelf' of cards for a given role. It is clearly the discovery entry point, though it names no sibling tool by name, relying instead on the tagline 'front door' to differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing guidance: 'Call this FIRST when someone says what they do', plus the fallback instruction to ask the user what they do if unspecified. It also states the no-args vs. role argument behavior, so the agent knows exactly which call shape to use at which moment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
watch_teardownswatch_teardownsbring_your_documentstart_an_engagementtwin_cities_lookupwhat_we_have_for_youbroker_diligence_prepbusiness_teardowncompetitor_landscapecompose_reportdata_source_atlaslocal_visibility_auditmarket_opportunity_scanpricing_benchmarkrequest_a_featurereview_intelligencetwin_cities_datasetstwin_cities_recordsReal estate data for AI agents: US parcel boundaries (tiles), owners, sale history, permits, hail.
US property register: 92M parcels, deeds, violations, CMBS filings, county sales, market series.
Property Records MCP — address-level US property records (sales history,
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
Add one secure layer between your agents and this server.
