Skip to main content
Glama

Small Business Intelligence by Brick & Mortar

by io.github.2016judea

Pricing Benchmark

pricing_benchmark
Read-only

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"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYesThe business category/vertical, e.g. 'massage spa', 'full-service restaurant'.
servicesNoSpecific services/items to benchmark if known (e.g. ['30-min massage', 'gel manicure']) — otherwise the procedure derives a comparable bundle.
city_metroYesCity + state/region defining the comparison market, e.g. 'Wichita, KS'.

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.4/5.0
Behavior4/5

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

Annotations already establish read-only, non-destructive behavior. The description adds meaningful methodological context: normalization across service bundles and handling of competitors that don't publish prices. No contradictions with annotations; it would benefit from stating data sources or freshness, but the added detail is valuable.

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

Conciseness4/5

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

The core purpose is front-loaded in one strong sentence, and the example invocations support real-world usage. Three examples are slightly repetitive, but each adds a different angle, so the length is justified and not bloated.

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

Completeness5/5

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

With an output schema present, return values need no elaboration. All three parameters are documented and illustrated, and the description covers key edge behavior around bundled services and unavailable prices. It is complete enough for an agent to select and invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by showing natural-language mappings for category and city_metro, and by clarifying that services is optional and that a comparable bundle is derived when omitted.

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 first sentence names a specific verb and resource: 'Builds a defensible local pricing comparison within a category.' Examples make the category and market scope concrete, and the emphasis on pricing clearly separates it from broader siblings like competitor_landscape or market_opportunity_scan.

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

Usage Guidelines4/5

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

The examples provide clear context for when the tool applies, including benchmarking, checking specific pricing, and handling missing public prices. It does not explicitly name alternatives or say when not to use it, but the pricing-specific framing gives strong enough guidance for selection among siblings.

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