Combine multiple delivery notes, orders, quotes, or work reports into one document, such as a monthly summary invoice.
Raggruppa più DDT, ordini, preventivi o rapportini in un unico documento (es. fattura riepilogativa di fine mese).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| date | No | ||
| group | No | Raggruppa le righe uguali | |
| dry_run | No | ||
| company_id | No | Azienda su cui operare. Default: FIC_COMPANY_ID o l'unica azienda del token | |
| source_type | Yes |
Changes observed during successful MCP inspections.
v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden and largely fails: it does not say whether the source documents are consumed, merged, or left untouched, whether a new document is created, or what permissions/company context are required. The existence of a dry_run parameter hints at a preview mode, but the description never explains it.
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?
A single well-formed sentence that front-loads the action and adds a useful concrete example; nothing is wasted. It is arguably too terse for a 6-parameter mutation tool, but as prose it is clean.
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 mutating creation/merge tool with six parameters, no annotations, and no output schema, the description is far too thin: no side effects, no dry_run semantics, no return information, and no parameter guidance. An agent could invoke it but could not safely predict what happens to the source documents.
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 only 33%, yet the description explains none of the six parameters. The Italian source-type words loosely map to the source_type enum, but ids (minItems 2), date, group, dry_run and company_id get no clarification in the description, leaving most of the contract undocumented.
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+resource: grouping multiple delivery notes/orders/quotes/work reports into a single document, with a concrete example (month-end summary invoice). This is clearly distinct from CRUD siblings, though it does not differentiate itself from near neighbours such as transform_document, duplicate_document or bulk_duplicate.
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 example ('fattura riepilogativa di fine mese') implies when to use it, but there is no explicit when-not, no mention of prerequisites, and no routing to alternatives like transform_document or bulk_duplicate that an agent might confuse it with.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.