travaso

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the archive never empties, which describes the archive's persistence, but it does not disclose whether the operation is read-only, whether it has side effects, or what the response looks like. The description adds context about the archive but not about the operation's 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?

Two short sentences with no extraneous information. The purpose and usage are front-loaded, making it very concise and easy to parse.

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?

The tool has 2 parameters, no output schema, and no annotations. The description gives a clear purpose and usage context, but it does not explain how it differs from sibling 'travaso_cerca', what 'travaso' refers to, or what the response looks like. This is incomplete for an agent to correctly select and call the tool among siblings.

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 0%, so the description must compensate by explaining parameters. It does not mention 'query' or 'limit' at all. While 'query' is self-explanatory from its name, 'limit' is not explained, and the agent gets no additional meaning beyond the schema's names and types.

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 a clear action ('Cerca' – search) on a specific resource ('archivio originale' – original archive) and adds a distinctive trait ('non si svuota mai' – never empties). However, it does not explicitly distinguish from the sibling tool 'travaso_cerca', which likely also performs searches, so the differentiation is only partial.

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 provides an explicit usage context: 'Da usare solo per ricordare qualcosa dopo il travaso' (use only to remember something after the transfer). This tells the agent when to use the tool, but it does not mention when not to use it or point to alternatives. The context is clear enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing side effects. It states facts 'leave the tank forever' and 'remain only in archive,' hinting at a destructive or irreversible operation, but doesn't specify whether this is permanent, reversible, or what happens to related data. The lack of explicit side-effect disclosure is a 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?

The single sentence is not concise in a helpful way; it packs a vague instruction with an implicit side effect, and the wording is ambiguous. The core action is buried behind a confirmational phrase rather than front-loaded.

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 no output schema, no annotations, and a description that fails to explain the operation, prerequisites, or return behavior, the tool is under-specified. An agent would struggle to know exactly what calling this tool does with the provided 'ids' and 'dove' values.

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?

The schema provides a description for 'dove' (50% coverage), so the baseline is 3. The tool description adds no parameter meaning beyond the schema. It doesn't explain 'ids' or clarify how 'dove' relates to the archival action. The description does not compensate for the uncovered parameter.

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 reads as an instruction to the agent ('Conferma che hai salvato...') rather than a statement of what the tool does. It implies a confirmation/archival action but never clearly states the tool's function (e.g., marking facts as absorbed/archived). The verb is directed at the user, not the tool, making purpose ambiguous.

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 guidance on when to use this tool versus its siblings (travaso_archivio, travaso_ripristina, etc.). The description implies a post-save confirmation but doesn't contrast it with alternatives or give conditions for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does add useful behavioral context: only undelivered facts are returned, next_queries are provided, and the caller must persist facts before invoking travaso_assorbi. However, it does not disclose whether the search mutates delivery state, what output format to expect, or any constraints.

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?

Two short sentences front-load the core search behavior before adding workflow guidance. There is no filler, though the final clause is an instruction to the agent rather than a property of the tool.

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 tool with no annotations and no output schema, the description gives a usable workflow and mentions next_queries, but it omits return structure details and the meaning of limit. It is adequate for a simple call, with clear gaps remaining.

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 0%, so the description must compensate, but it never explains the 'limit' parameter and only loosely implies that 'query' contains search terms via the phrase 'termini da cercare'. This leaves one of two parameters effectively 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?

The description identifies a specific action ('Cerca nel serbatoio') and a distinct scope: it returns only undelivered facts plus next_queries. It also signals a relationship to travaso_assorbi by instructing that sibling be called afterward, though it does not explicitly contrast all sibling tools.

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?

Usage is implied through the workflow instruction to save facts and then call travaso_assorbi, but the description does not state when to prefer travaso_cerca over travaso_stato, travaso_prossimi, travaso_archivio, or travaso_ripristina, nor any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does reveal the key protocol: facts are delivered in order, repeated calls lead to exhausted=true, and each block must be absorbed. This conveys drain/consumption semantics beyond a simple 'get next' operation.

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 two short sentences with no filler. It front-loads the action and then gives the necessary loop and absorption instruction, so every phrase 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?

The description provides the essential loop and the exhausted flag, which is valuable given no output schema. However, it omits what file refers to and what the response contains beyond exhausted, leaving a noticeable gap for a no-output-schema tool with 0% parameter coverage.

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?

Both parameters (file and limit) have no schema descriptions (0% coverage), and the description never mentions either parameter. The word 'blocco' hints at a batch-size concept that likely maps to limit, but the meaning of file is left entirely to inference.

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 a concrete verb and resource: 'Consegna in ordine i prossimi fatti del serbatoio' and clarifies the draining purpose. The word 'prossimi' plus 'in ordine' distinguishes it from siblings like search, state, and absorb tools.

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 second sentence gives explicit operational guidance: repeat until exhausted=true and absorb after each block. It tells the agent when to stop and what action accompanies each call, though it does not explicitly contrast with sibling tools by name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that this is a mutating action (refill from archive) and requires explicit user request, but does not explain side effects, reversibility, or what happens to existing data. The required 'conferma' parameter is not mentioned as a safety gate, leaving the agent unaware of the confirmation requirement.

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 two sentences, front-loaded with the action, and has no filler. It earns its place by stating the core purpose and a key usage constraint. Could be slightly more detailed without losing conciseness.

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 tool with a confirmation parameter and no annotations or output schema, this description is too sparse. It omits the confirmation parameter's role, fails to describe the archive source or any data loss implications, and provides no return value expectations. An agent lacks enough context to call it safely and correctly.

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 0%, so the description must compensate. It fails to mention the 'conferma' parameter at all, leaving the agent to infer its purpose from the boolean type and the phrase 'esplicita richiesta'. This is insufficient for a single required parameter that likely gates a destructive action.

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 a specific action ('Riempie di nuovo il serbatoio dall'archivio') with a clear resource and verb. It doesn't explicitly differentiate from siblings like travaso_assorbi or travaso_archivio, but the verb 'ripristina' and the phrase 'dall'archivio' imply a restore/refill action that is distinct enough from the other names.

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 provides a single usage condition ('Solo su richiesta esplicita dell'utente'), which tells the agent when not to call it. However, it gives no guidance on when to prefer this tool over siblings, nor any exclusions or alternatives. This is minimal but not comparative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the information returned (counts of facts, files, instructions), implying a read-only status operation, but it does not explicitly state that it has no side effects or that it is non-destructive. It also doesn't mention any prerequisites or rate limits. For a status tool, this is a moderate gap, but the description does convey the informational nature through 'stato' and the listed data points.

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, compact sentence (with a second short directive) that front-loads the core purpose ('Livello del serbatoio di memoria da travasare') followed by concrete details on what it reports. There is no filler or redundancy; every phrase earns its place. The 'Chiamalo per primo' is an efficient usage hint appended at the end.

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 the tool has no parameters and no output schema, the description must convey what the tool returns and how to use it. It does both: it lists the types of information returned (remaining facts, absorbed facts, files, instructions) and gives a clear usage directive. It doesn't specify the exact format or fields, but for a simple status tool this is adequate. It could be more explicit about the read-only nature, but overall it is complete enough for an agent to call it correctly.

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?

The tool has zero parameters and schema coverage is 100% (empty object). Per the baseline rule for 0 params, the description doesn't need to explain parameters. It adds value by clarifying the tool's output content (counts, files, instructions), which is beyond the schema's empty properties. This makes the description sufficient for parameter understanding.

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 clearly states the tool's function: it reports the level/status of the memory reservoir being transferred, including remaining facts, absorbed facts, files, and instructions. It distinguishes itself from sibling tools (search, next, absorb, archive, restore) by being a status/overview tool rather than an action, and the 'Chiamalo per primo' (call it first) hints at its role as an entry point. However, it doesn't explicitly name the verb 'status' or 'state' in English, leaving some ambiguity in the phrase 'Livello del serbatoio'.

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 provides a clear usage directive: 'Chiamalo per primo' (call it first), which tells the agent to invoke this tool before others in the workflow. It implies that this is the initial step to assess the state before performing actions like absorb or search. It does not explicitly mention alternatives or exclusions, but the sibling list and the directive give sufficient context for when to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.