Free joined public records for small business and CRE: Twin Cities parcels, sales, licences
Scored across 12 tools
Each tool targets a distinct analysis angle (teardown, competitor landscape, pricing, reviews, visibility, etc.), so an agent can usually pick correctly. However, business_teardown overlaps conceptually with review_intelligence, competitor_landscape, and local_visibility_audit, and data_source_atlas vs. twin_cities_datasets both serve as 'research planning' tools, creating minor boundary ambiguity.
All names use lowercase snake_case and are descriptive, with a strong 'domain_noun' pattern (business_teardown, competitor_landscape, pricing_benchmark). The convention is mostly consistent, but compose_report and request_a_feature break the pattern by leading with a verb, and broker_diligence_prep is a slightly awkward hybrid.
Twelve tools is well within the ideal range for a domain-specific intelligence server. Every tool covers a distinct analytical or operational need, from research planning to reporting, plus a feedback channel, without feeling padded or redundant.
The tool surface covers the core workflow well: research, teardown, competitive analysis, market scanning, pricing, review mining, visibility audit, diligence prep, and report composition. Minor gaps exist—there is no dedicated financial-statement valuation tool or direct booking/CRM integration—but these are outside the apparent scope and can be addressed via request_a_feature.
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.
Full structured teardown of ONE named small business: digital presence, review signal, competitive position, pricing posture, visibility gaps, and prioritized, evidence-cited recommendations. The flagship tool — start here for any single-business question.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered without needing repetition. The description adds scope and output expectations but does not disclose meaningful behavioral details beyond that, such as data sourcing, coverage limits, or report format, which is acceptable given output schema exists but not exceptional.
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 opens with a crisp definition and clear routing statement, making the core purpose immediately visible. The three example invocations are useful but somewhat redundant; one or two would convey the same guidance with less length.
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 complex teardown tool, the description names the main report dimensions and provides natural-language examples that show expected inputs and intent. The presence of an output schema and rich annotations lowers the burden on the description, but it could still more explicitly mention edge cases or when a narrower sibling tool would be more appropriate.
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 input schema already thoroughly documents business_name, city_metro, and category. The description's example invocations reinforce the parameters but add little semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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?
Description states a specific verb ('full structured teardown') on a specific resource ('ONE named small business') and enumerates the key coverage areas: digital presence, review signal, competitive position, pricing posture, visibility gaps, and recommendations. It also distinguishes itself as the flagship tool for single-business questions, separating it from narrower sibling tools like local_visibility_audit or pricing_benchmark.
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 instruction 'start here for any single-business question' gives clear routing context and is reinforced by example invocations. It does not explicitly state when to avoid this tool in favor of a more focused sibling, such as review_intelligence or pricing_benchmark, so it falls just short of full alternative-based guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Maps the local competitive set for a category + metro: true competitors vs. adjacent players, a positioning matrix, and saturation signals.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive, idempotent nature of the tool. The description adds meaningful behavioral context beyond that: it differentiates true competitors from adjacent players and indicates that saturation signals are computed rather than merely listed. The reference to 'default trade-area logic' in the radius_note parameter also hints at internal bounding 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?
The description is front-loaded with the core definition and supported by a short set of illustrative invocations. No filler is present, though the three examples are slightly repetitive; still, each adds a useful usage angle, making this a well-structured description.
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, the description sufficiently covers what the tool computes and how an agent might be invoked. The only missing piece is explicit disambiguation against a closely related sibling such as market_opportunity_scan, which keeps it from being fully complete.
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%, and the input schema already explains category, city_metro, and radius_note clearly. The tool description reinforces these with examples, especially for city_metro formats, but does not materially expand on what the schema already provides, so the baseline of 3 is appropriate.
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+resource: it maps the local competitive set for a category + metro, and enumerates concrete outputs: true competitors vs. adjacent players, a positioning matrix, and saturation signals. The example invocations reinforce this by showing realistic queries, making the purpose concrete and distinguishable from sibling analysis tools.
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 conveys when to use the tool through clear example invocations, including mapping, saturation, and competitor-identification phrasing. It gives solid context for the trigger scenarios, but it does not explicitly state when NOT to use this tool or point to a sibling alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assembles the outputs of any prior Small Business Intelligence tool calls into one polished, client-ready report: section order, executive-summary rules, evidence-citation standards, and tone guidance matched to the audience. This is what makes a multi-tool session feel like a finished product, not a pile of separate answers.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful context that the tool does not re-research but assembles provided summaries, and that audience-specific tone and structure rules are applied. It doesn't go beyond this, but with strong annotation coverage this is sufficient.
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 core purpose is front-loaded in the first sentence, and the three example invocations are genuinely illustrative rather than filler. The second sentence is somewhat promotional but still clarifies the value proposition. Overall, it is appropriately sized for a tool with three parameters and a clear composition role.
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 full schema coverage, output schema, and annotations, the description provides enough context for an agent to know when to call this tool and what to pass in. The examples cover multiple audiences and clarify the expected input format. Minor gaps like the exact structure of the produced report are covered by the output schema and the description's reference to section order and citation standards.
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 every parameter is already documented. The description reinforces that `completed_analyses` are final write-ups rather than raw payloads and that `audience` drives tone and structure, but it does not add substantial new semantics 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('assembles') and resource ('outputs of any prior Small Business Intelligence tool calls') to define exactly what the tool produces: a polished client-ready report. It clearly distinguishes itself from sibling analysis tools by positioning it as the final composition step, not another data-gathering task.
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 clearly implies this tool should be used after other analyses have been completed, and the examples reinforce the expected workflow ('I've run a teardown... compose it'). It does not explicitly name alternatives or when not to use it, but the context makes the intended usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?"
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive, so no contradiction exists. The description adds behavioral value by clarifying that the output is a plan rather than data, and by being honest that the tool also reveals what public records cannot answer. This goes beyond the structured annotation coverage.
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 purpose, immediately followed by a concrete usage directive and a compact, useful set of example invocations. Every sentence adds value, and the structure makes it easy for an agent to grasp what to send and why.
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 read-only planning tool with a full input schema, helpful annotations, and an output schema present, the description covers purpose, usage timing, example inputs, and known limits of what the plan can settle. Nothing an agent needs to decide when and how to invoke it is left out.
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%, with detailed descriptions for place, question, and already_tried. The description's example invocations illustrate realistic question phrasing and geography formats, but they do not add substantial meaning beyond the schema's own parameter descriptions. Baseline 3 is appropriate.
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 plus resource ('returns a source-first RESEARCH PLAN') and clearly scopes it to 'a real question about a local market or a specific property.' It also distinguishes the tool from sibling data-retrieval tools by positioning it as the planning step that precedes research rather than the research 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?
The description explicitly states when to use the tool: 'Use this BEFORE researching a local market.' It reinforces this with example invocations that show real planning scenarios. It does not explicitly name alternative sibling tools or state when not to use it, but the timing and intent are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audits a business's local search presence: map-pack factors, listing consistency, category selection, site fundamentals — what to check, and in what order — returned as a scored checklist.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns a scored checklist and covers what to check and in what order, which is useful behavioral context. However, it doesn't disclose details like data sources, freshness, or limitations.
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 well-structured with a clear main sentence followed by three example invocations that illustrate usage. It's appropriately sized and front-loaded with the core purpose. The examples add value but could be slightly more concise.
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?
The tool has an output schema, so return values are documented elsewhere. The description covers what the tool does, what it checks, and provides examples. It's complete enough for an agent to select and invoke it correctly, though it could mention data sources or limitations.
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 schema already documents all three parameters. The description adds context for the category parameter ('narrows which map-pack searches are the right ones to check') and the business_name parameter ('as it appears on its own signage/website'), which is helpful but not extensive. Baseline 3 is appropriate.
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 states the tool audits a business's local search presence and lists specific components (map-pack factors, listing consistency, category selection, site fundamentals) and the output format (scored checklist). It distinguishes itself from siblings like competitor_landscape or review_intelligence by focusing on local visibility audit with a scored checklist output.
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 provide concrete usage scenarios, showing when to use this tool (e.g., 'Run a local visibility audit...', 'Why doesn't... show up...'). It implies usage for diagnosing local search presence issues, but doesn't explicitly state when not to use it or name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gap analysis for a category x metro: detects underserved demand, oversaturation, and genuine whitespace using only public signals — for someone deciding whether/where to open, expand, or invest.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'using only public signals,' which is a useful data-source constraint not captured in annotations. It does not discuss data freshness, geographic coverage, or other operational limitations, so with the low bar for annotations, 3 is appropriate.
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 front-loads a precise one-line definition and purpose, then follows with three concrete examples. There is no redundancy or fluff, and every sentence contributes directly to tool selection and usage understanding.
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 simple two-parameter, read-only analytical tool with an output schema, the description covers purpose, audience, and example inputs well. It could mention data coverage or limitations, but nothing required to invoke the 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?
The schema already provides solid descriptions for both parameters with 100% coverage, giving a baseline of 3. The description reinforces the 'category x metro' pattern and adds three varied examples that show flexible phrasings and neighborhood-level specificity, which goes beyond the schema's simple examples.
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 gap analysis tool for a category and metro, specifically detecting underserved demand, oversaturation, and whitespace. It provides three concrete example invocations that illustrate the exact kind of questions it answers, making it easy to distinguish from siblings like competitor_landscape or pricing_benchmark.
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 context for when to use the tool: 'for someone deciding whether/where to open, expand, or invest.' The example questions further clarify real use cases. It does not, however, mention when not to use this tool or point to alternatives, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds 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.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it normalizes across service bundles and handles missing competitor prices, which tells the agent what kind of reasoning to expect. It doesn't contradict annotations.
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 concise and front-loaded with the core purpose, followed by example invocations that clarify scope. The examples are useful but slightly redundant with the first sentence; still, they earn their place by showing real user intents.
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?
The tool has an output schema, so return values are covered elsewhere. The description covers the main edge case (competitors not publishing prices) and the normalization challenge, which is the core complexity. It could mention data sources or confidence levels, but for a read-only analysis tool this is adequate.
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 schema already documents all three parameters. The description adds context about how 'services' is used ('otherwise the procedure derives a comparable bundle'), which is helpful, but it doesn't add much beyond the schema's own descriptions.
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 uses a specific verb ('Builds') and resource ('local pricing comparison within a category'), and clearly distinguishes the tool's scope from siblings like competitor_landscape or market_opportunity_scan. The example invocations reinforce the purpose with concrete use cases.
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 explains what the tool does and gives example invocations that illustrate when to use it. It does not explicitly state when not to use it or name alternatives, but the examples and phrasing ('defensible local pricing comparison') make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses key behaviors beyond annotations: the request goes to a real inbox, is free, requires no account, and must not be reported as sent unless the response status is 'filed'. It also warns against paraphrasing the user's words and against approximating email addresses. These are material side effects and constraints the agent must know, and they complement the non-read-only, open-world annotations without 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?
The description is front-loaded with the core purpose, then flows logically into usage criteria, pre-call behavior, parameter handling, and post-call reporting. The example invocations are compact and illustrative. Every sentence earns its place; there is no filler or redundant restating of the title.
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 five optional parameters and a nuanced interaction protocol, the description covers everything an agent needs: what the tool does, when to use it, what to ask the user, how to fill each parameter, how to report the result, and example prompts. The existence of an output schema covers return-value details, so nothing critical 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?
Although schema coverage is 100%, the description adds crucial semantics: 'request' must be verbatim, 'context' is the agent's own summary, 'reply_email' must never be guessed, and 'subject' can be a city, sector, dataset, or tool name. It even explains how to elicit missing information from the user before calling. This is far more meaningful than the bare schema descriptions.
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 first sentence states a specific action: 'Sends a feature request, a data request or a correction straight to the person who builds this server'. It clearly identifies the tool as a feedback/request channel, which is distinct from the sibling analysis tools. The description also names concrete triggers ('a question it cannot answer, a dataset or column it does not hold'), making its purpose unambiguous.
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 'Use it whenever this server falls short of what the user actually wanted' and enumerates four specific scenarios. It also instructs the agent on when to offer filing a request ('Reaching a wall is not the end of the turn') and what to ask before calling. This is direct, actionable guidance for selecting the tool at runtime.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mines public reviews for signal: a complaint taxonomy, theme extraction, sentiment trajectory over time, the differentiators customers actually cite, and red flags for a buyer.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the tool works on public reviews and produces derived signals, but it does not disclose limitations such as review data coverage, missing businesses, or corpus freshness. That leaves behavioral transparency adequate but incomplete.
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 core purpose is front-loaded in one dense sentence, followed by three illustrative invocations. The examples are distinct enough to add value, but the overall description is slightly longer than strictly necessary, so it does not merit a 5.
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 three documented parameters, read-only annotations, and presence of an output schema, the description supplies enough for an agent to invoke the tool correctly. It covers the analytical outputs and realistic usage phrasing, but it does not mention coverage limits or explicitly distinguish this from sibling business-intelligence tools.
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 business_name, city_metro, and category are already documented. The description's examples reinforce the expected format (e.g., 'Minneapolis', 'Wichita, KS') but add no additional parameter semantics like constraints, dependencies, or format edge cases.
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 resource ('Mines public reviews') and enumerates concrete output types: complaint taxonomy, theme extraction, sentiment trajectory, cited differentiators, and buyer red flags. This makes the tool's purpose clear and distinct from the sibling tool names without needing to open the schema.
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 give clear contexts for when to use the tool: finding patterns beyond star ratings, testing whether a rating is stable or hiding a recent decline, and buyer due diligence around staffing/ownership. However, it never names sibling tools or states when not to use it, so it stops short of explicit alternative routing.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
broker_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.
Property Records MCP — address-level US property records (sales history,
Agent-ready NYC public records. Hosted, source-backed civic data organized around durable anchors.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
Add one secure layer between your agents and this server.
