credit_note_getReturn one credit note by its CN number or draft id: every line with quantity, unit price and tax, the totals per tax rate, the reason, the invoice it credits, and the notes. Reads only; use credit_note_list for the ids.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The credit note number CN-2026-0001 or draft id CN-DRAFT-2026-0001 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral burden, and it does the key part by stating 'Reads only' (safe, non-mutating). It also describes the returned payload in detail, which substitutes for an absent output schema. It stops short of covering edge cases such as a missing/invalid id or draft-vs-finalized behavior.
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 sentence front-loaded with the action, followed by a colon-delimited list of return contents and a trailing routing note. No filler; every clause earns its place.
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 one-parameter read tool with no output schema and no annotations, the description supplies the safety profile (reads only), the return shape, and the id-sourcing path. Nothing an agent needs to invoke it correctly is missing.
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 'id' parameter is fully documented there, including the CN-2026-0001 vs CN-DRAFT-2026-0001 formats. The description repeats that dual-id capability rather than adding new syntax or constraints, so the 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 ('Return one credit note') and enumerates exactly what the response contains (lines with quantity/unit price/tax, totals per tax rate, reason, credited invoice, notes). The lookup key is named (CN number or draft id), so it is clearly distinguishable from credit_note_list, credit_note_summary, and credit_note_render.
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?
Explicitly declares 'Reads only' and routes the agent to credit_note_list when it needs to discover ids first. That is a clear usage context and names the alternative sibling, though it does not spell out when this tool is the wrong choice beyond needing an id.
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.