Skip to main content
Glama

Small Business Intelligence by Brick & Mortar

by io.github.2016judea

Review Intelligence

review_intelligence
Read-only

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?"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNoCategory if known — helps set expectations for review volume/velocity norms.
city_metroYesCity + state/region, e.g. 'Wichita, KS' — disambiguates same-named businesses.
business_nameYesThe business's name as it appears on its own signage/website.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYes
noticeNoPresent ONLY when the request was denied by usage policy instead of executed. When present, every other field is an empty placeholder and must not be reported as a framework.
caveatsYes
subjectNo
frameworkYes
output_schemaYes
quality_rubricYes
research_procedureYes

TDQS

A4/5.0
Behavior4/5

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

The description aligns with the readOnlyHint and destructiveHint annotations, indicating a non-mutating analysis operation. It does not explicitly state that no data is modified, but the wording 'mines' and the focus on extracting signal imply a read-only behavior. It adds no extra transparency beyond the annotation but is consistent with it.

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

Conciseness5/5

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

The description is a single, concise sentence that efficiently enumerates the key analytical outputs without extraneous detail. It is well-structured and immediately communicates the tool's value proposition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core functionality and output types but does not elaborate on the input requirements or output format. Given that an output schema exists and parameter descriptions are complete, the description is sufficiently complete for an agent to understand what the tool does, though it could briefly mention how the location disambiguates businesses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explicitly connect the parameters (business_name, city_metro, category) to the analysis process. While the schema provides individual parameter descriptions, the tool description adds minimal contextual meaning about how these inputs are used to locate and focus the review mining. However, the parameter descriptions are clear enough on their own.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool mines public reviews and lists specific analytical outputs (complaint taxonomy, theme extraction, sentiment trajectory, differentiators, red flags). It uses a specific verb ('mines') and identifies the resource ('public reviews'), making the purpose unambiguous and distinct from generic search or retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for review analysis but does not explicitly state when to prefer it over alternatives like competitor_landscape or local_visibility_audit. It lacks explicit when-to-use or when-not-to-use guidance, leaving the agent to infer applicability from the listed outputs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Small Business Intelligence by Brick & Mortar toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

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

Naming Consistency4/5

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

Tool Count5/5

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

Completeness4/5

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

Resources