Skip to main content
Glama

Small Business Intelligence by Brick & Mortar

Compose Report

compose_report
Read-only

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"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
audienceYesWho will read this report — drives section order, tone, and what gets emphasized vs. cut.
business_nameYesThe business the report is about.
completed_analysesYesThe completed write-ups from any prior tool calls this session, to be assembled — not re-researched.

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

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

Annotations specify readOnlyHint=true and destructiveHint=false, so the tool is non-destructive. The description adds that it does not re-research but assembles existing outputs, which clarifies behavior beyond annotations. No contradiction exists.

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 concise, using two sentences plus two examples. It front-loads the purpose and lists key aspects (section order, executive-summary rules, etc.) without unnecessary detail. The structure is effective and easy to parse.

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?

The description, combined with the input schema (which includes parameter descriptions and an output schema reference), provides sufficient context. Examples illustrate typical use cases, and the 'not re-researched' note clarifies the input handling. No gaps that would prevent correct usage.

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 input schema has descriptions for all three parameters, including a detailed explanation for completed_analyses. The tool description itself does not add further parameter semantics, but the schema provides sufficient meaning, so a neutral score is appropriate.

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's purpose: assembling outputs of prior tool calls into a client-ready report. It specifies the resource (outputs of prior tool calls) and the verb (assemble), making it distinct from other tools. The examples further clarify the intended use.

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 it assembles outputs from prior tool calls and includes example invocations that show when to use it (after running other tools). The input schema also notes 'not re-researched', reinforcing the condition. This provides clear guidance on when to use the tool versus alternatives.

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

Try in Browser

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.