The same Guided Business Study as a markdown document — the form a study is handed over in, with each stage’s findings beside its own evidence table.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | No | Optional: the business’s stated objective. | |
| businessId | Yes | ||
| inspectWebsite | No | Optional, default false. Inspect the website on record before running, so the stages comparing the site against the record can look. Costs one bounded fetch. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the output format (markdown with stage findings and evidence tables) but fails to describe whether it performs any writes, requires certain data availability, or has side effects (e.g., costing fetches). The existence of the inspectWebsite parameter suggests optional fetches, but this is not explained in the description.
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 a single sentence that is relatively concise, front-loaded with the tool's purpose ('the same Guided Business Study as a markdown document'), and includes relevant detail about output structure. However, it could be slightly more efficient by removing the redundant clarification about handing over a study.
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 3 parameters, no output schema, and no annotations, the description is not complete. It does not mention the return value format beyond 'stage findings beside its own evidence table,' which is vague. The optional inspectWebsite parameter's behavior (costing a bounded fetch) is not mentioned, and the required businessId's purpose is omitted. The description lacks enough detail for an agent to use this tool confidently.
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 67% (2 out of 3 parameters have descriptions). The businessId parameter lacks a description, so the description does not clarify what it represents. The description adds no extra meaning beyond the schema for objective and inspectWebsite. For a required parameter with no schema description, the tool description should ideally explain its role.
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 states it provides 'the same Guided Business Study as a markdown document' with a reference to stage findings and evidence tables. However, it does not specify the resource it operates on (a business) clearly—'Guided Business Study' is vague—and it does not differentiate this from sibling tools like run_business_study or various get_* tools that might retrieve similar formatted reports.
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 lacks any guidance on when to use this tool vs. alternatives like run_business_study or get_business_health_markdown. It does not state prerequisites, context for selecting markdown output over other formats, or when not to use it. The user must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools are effectively duplicates or near-duplicates: get_emerging_signals is an explicit alias for list_economic_signals, resolve_entity and resolve_entities overlap heavily, and the markdown variants duplicate their non-markdown reports. Pairs like compare_communities/compare_municipalities and search_businesses/search_licensed_businesses also require reading long contracts to avoid misselection.
Tool names overwhelmingly follow a snake_case verb_noun pattern with sensible verbs like get_, list_, search_, and compare_. The main deviations are the backwards-compatible get_emerging_signals alias and prefix choices such as check_business_health vs get_business_health that obscure the underlying distinction.
70 tools is an extreme surface for any MCP server, far beyond the 25+ 'too many' threshold. The set is fragmented by format variants, aliases, and multiple overlapping lookup tools, making selection and maintenance costly.
The domain surface is broad: entity resolution, business health, labour, community economy, procurement, and governance evidence are all covered in depth. However, there are notable lifecycle gaps—no sandbox deletion, consent revocation, health-action cancellation, or actual exchange/connect/apply step—that leave agents with dead ends.
