Skip to main content
Glama

Small Business Intelligence by Brick & Mortar

by io.github.2016judea

Request a Feature

request_a_feature

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNofeature = 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.
contextNoYour summary of what they were actually trying to do when they hit this. This one is yours to write.
requestNoThe 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.
subjectNoThe city, sector, dataset or tool name this is about — 'Duluth', 'dental practices', 'twin_cities_records'.
reply_emailNoOptional, and only if they offer it. VERBATIM — never guess, complete or correct an address. Omit it rather than approximate it.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYes
filedNo
noticeNoPresent ONLY when the request was denied by usage policy instead of executed. When present, nothing was filed.
statusYes`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.
messageYes

TDQS

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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