wave_get_productRetrieve a product or service by ID, including its linked accounts and default sales taxes, optionally scoped to a specific business.
One product/service with its accounts and default sales taxes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product ID | |
| 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, but the description still adds genuine context by disclosing that the response is hydrated with related accounts and default sales taxes. It does not state behavior for a missing or archived ID, but for a simple read that is a minor gap.
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?
It is a single front-loaded clause with no wasted wording, which is good. The trade-off is that it is so compressed that it reads as a fragment and omits the retrieval verb and any operational qualifiers.
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?
For a two-parameter read tool with full schema coverage and complete annotations, this is close to adequate, and no output schema means return values needn't be detailed. What is missing is what happens on a nonexistent/archived product and what 'accounts' refers to, which an agent would need when interpreting results.
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?
With 100% schema description coverage, the schema already documents both 'id' and 'businessId' including the default-to-context fallback, so the baseline is 3. The description adds no further meaning about whether the ID accepts a product key, a numeric ID, or a reference.
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 identifies the resource ('One product/service') and hints at the expanded payload ('with its accounts and default sales taxes'), and the singular 'One' implicitly contrasts with wave_list_products. However, it is a noun phrase rather than a verb+resource statement, so the retrieval action is only inferred from the name.
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?
There is no explicit when-to-use or when-not-to-use guidance and no mention of the sibling alternatives (wave_list_products, wave_update_product, wave_archive_product). The singular framing is the only cue that this is a single-record lookup rather than a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.