wave_get_businessRetrieve full details for a Wave business—address, contact info, currency, timezone, email-invoice capability, and invoice/estimate branding—by business ID.
Full details of one business: address, contact info, currency, timezone, whether Wave can email invoices for it, and invoice/estimate branding.
| Name | Required | Description | Default |
|---|---|---|---|
| businessId | No | Business ID; defaults to the one wave_get_context reports |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description's contribution is naming the payload fields, which is genuinely useful because there is no output schema, but it says nothing about failure modes (invalid or inaccessible businessId) or whether the default resolves silently.
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?
One front-loaded sentence with a colon-delimited field list; every element carries information for an agent with no output schema. Slightly dense as a fragment, but nothing is wasted.
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?
A simple single-record read with rich annotations and a fully documented parameter; the field enumeration compensates well for the absent output schema. Only the default-resolution behavior and error handling are left implicit, which is minor for this tool class.
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 100% and the single parameter already documents that businessId defaults to whatever wave_get_context reports. The description adds no meaning beyond that — no guidance on when to omit versus pass explicitly — so baseline 3 applies.
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?
States a specific verb and resource ('Full details of one business') and enumerates the returned facets — address, contact info, currency, timezone, invoice-email capability, branding. That makes it clearly a single-record fetch rather than a list, though it never explicitly contrasts itself with wave_list_businesses.
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?
No when-to-use guidance at all: nothing about calling this before invoice/estimate creation to obtain branding defaults, and nothing about the fallback to the context business. The only hint of the default behavior lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.