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

With no annotations supplied, the description carries the full behavioral burden; 'leggero' usefully signals that this is a cheap, non-destructive operation rather than a full backup. However, it never says what the snapshot captures, how long it is retained, or that it is the object later consumed by driftguard_rollback, leaving the agent to infer the safety model.

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 and the object, with the timing constraint appended where it is most useful. Nothing is redundant or padded.

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 tool with no output schema, the definition is workable but leaves a real gap: it does not tell the agent what comes back (a snapshot identifier or name) that would be needed to later call driftguard_rollback. The absence of annotations also means the reversibility and permission profile go unstated.

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 single optional 'label' parameter is fully documented in the schema (100% coverage) with examples, so the description does not need to compensate. It adds no meaning beyond the schema, which is the expected baseline here.

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 gives a specific verb and resource in 'Crea un checkpoint (snapshot) leggero dello stato del workspace', which tells an agent exactly what is produced. It does not name any sibling such as driftguard_rollback or driftguard_list_snapshots, so the differentiation from the surrounding snapshot lifecycle tools is left implicit.

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?

'prima di eseguire modifiche rischiose a file o configurazioni' clearly states the triggering condition for calling this tool, which is genuine when-to-use guidance. It stops short of naming the alternatives (rollback vs. list snapshots) or saying when a snapshot is unnecessary, so no exclusions are given.

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 supplied, so the description carries the full disclosure burden. It does usefully signal an advisory scope — it "suggerisce la soluzione immediata" rather than applying it — which tells the agent this is analysis, not remediation. However, it says nothing about whether it executes commands, reads log files, requires permissions, or what the response contains, so the behavioral picture is only partially filled in.

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 that front-loads the action and then scopes it with the parenthetical problem list; nothing is redundant. The parenthetical is slightly dense but every item earns its place by clarifying the diagnostic domain.

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, no-output-schema tool, the definition covers the input domain and states what comes back (a diagnosis plus an immediate suggested fix), which is the key missing piece when no output schema exists. The main gap is the absence of any hint that the tool is purely analytical and does not itself fix the problem, which matters given mutating siblings in the same family.

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?

There is a single parameter with 100% schema description coverage, so the schema already explains that errorOutput is the raw error text or stack trace. The description's phrase "messaggio di errore o output di log" is consistent with the schema but adds no format, size, or language constraints beyond it.

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 gives a specific verb ("Analizza ... per diagnosticare") and a specific input resource ("messaggio di errore o output di log"), then enumerates the problem classes it covers (blocked ports, zombie processes, permissions, missing commands). That is enough to separate it from siblings like driftguard_inspect_ports or driftguard_kill_process, though it never names those siblings explicitly.

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 only implied: an agent can infer it should call this when it holds an error message or stack trace. There is no explicit when-not guidance and no routing to alternatives (e.g. use inspect_ports for a live port check, kill_process to actually resolve a zombie), so the agent must reason about the boundary itself.

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 at all, the description carries the full burden. It does disclose the filtering behavior (only successful and essential commands, cleaned and ordered), which is real behavioral content beyond the name, but it never states whether the operation is read-only, which environment or snapshot scope it applies to, or what form the output takes.

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 front-loaded sentence that names the artifact first and qualifies it second, with no filler. It is dense but earns its words; only the mixed Italian/English vocabulary against English sibling names adds friction.

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 zero-parameter tool with no output schema and no annotations, the description should clarify what the returned artifact looks like and what scope it covers. It describes the content of the extract but leaves the scope (which environment or snapshot, current state vs. history) and the delivery format unstated.

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 takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the description correctly implies no arguments are needed.

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 ('Genera') and a named resource ('Reproducibility Blueprint'), then defines that resource as a filtered extract of only successful and essential commands. This is enough to tell an agent it is not the same as driftguard_list_snapshots or driftguard_create_snapshot, though no sibling is named explicitly.

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 phrase 'per riprodurre lo stato dell'ambiente' hints at the goal, but there is no explicit when-to-use rule, no when-not-to-use, and no reference to any of the seven sibling tools such as driftguard_rollback or driftguard_list_snapshots. An agent must infer that this is the read-only export step rather than the rollback step.

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 supplied, so the description must carry the behavioral burden. It implies a read-only inspection and limits scope to local TCP listening sockets (excluding UDP and remote hosts), but says nothing about required privileges, whether the operation has side effects, or what the response contains.

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 no filler, and the scope constraint appears before any optional detail. It is efficient, though it offers no structural cue about return values or conditions.

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-optional-parameter read tool with no output schema, the definition covers purpose and scope but leaves the caller guessing about output shape (process names, PIDs, addresses) and privilege requirements. Adequate, not complete.

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 coverage is 100% and the single parameter already documents the 'specific port vs. all listening ports' behavior, including examples. The description adds no syntax or format detail beyond what the schema provides, 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?

A specific verb and resource combination ('processi attivi in ascolto') plus an explicit scope ('una porta specifica o su tutte le porte TCP locali') makes the function unambiguous and separable from siblings such as driftguard_kill_process or driftguard_diagnose_failure.

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 never states when to reach for this tool instead of alternatives, nor any prerequisites (e.g., that elevated privileges may be needed on privileged ports). The only hint is the scope option, which merely restates the parameter and not a usage condition.

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 supplied, so the description carries the full behavioral burden for a destructive, irreversible operation. It says 'terminates' but never states that the action cannot be undone, that it likely requires elevated privileges, whether child processes are affected, or what happens if the PID does not exist. The only real behavioral detail (SIGTERM default vs SIGKILL with force) lives in the schema, not the description.

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 front-loaded sentence with the verb and resource first and the use-case hint second. Nothing is redundant or padded, and it is readable in one pass.

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 tool with full schema coverage and no output schema, the description covers the essentials of what will be done. What is missing is the risk profile of a destructive system operation — irreversibility and permission requirements — which is exactly the gap annotations would normally have filled.

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%: both pid and force are fully documented, including the SIGTERM/SIGKILL distinction. The description merely echoes the PID concept and adds no meaning beyond the schema, which is the expected baseline of 3 when the schema does the heavy lifting.

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 names a specific verb (terminates) and resource (a system process identified by its PID) and adds a concrete motivating scenario (freeing a blocked port). It is clearly distinct from the snapshot/rollback/diagnose siblings, though it never explicitly contrasts itself with any of them.

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 parenthetical example ('per liberare una porta bloccata') implies when the tool is useful, which is more than nothing. However, there is no guidance on preconditions (finding the PID first, e.g. via driftguard_inspect_ports) and no when-not-to-use or safety caveat about killing the wrong process.

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 supplied, so the description carries the full behavioral burden. It does convey that the operation is a scoped read of session-local snapshots, but says nothing about ordering, whether the list can be empty, or what happens to snapshots across sessions; for a zero-parameter read that is a modest but real 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?

A single front-loaded sentence with no filler. It is appropriately sized for a zero-parameter list operation, though it offers no elaboration that would help an agent predict the result shape.

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 simple, parameter-free listing tool with no output schema and no annotations, the description covers the essential who/what/scope. Return format and empty-state behavior remain unstated, which is the only notable omission.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The only semantic contribution is the implicit scope filter (current session), which is stated rather than parameterized.

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 ("Elenca tutti i checkpoint/snapshot") and adds scope ("nella sessione corrente"), which separates it from the mutating sibling driftguard_create_snapshot. It does not explicitly name any sibling as an alternative, so differentiation is implicit rather than stated.

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 only implied: listing snapshots is naturally a pre-rollback or inspection step, but the description never says when to call it or when another tool (e.g. driftguard_create_snapshot, driftguard_rollback) is the better choice. An agent can infer the intent but receives no explicit routing guidance.

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 behavioral burden, yet it discloses almost nothing beyond the record intent. It does not say whether entries are appended and ordered, whether repeated identical commands are deduplicated, whether a prior snapshot/session is required, or what happens on a failed call — all material for a tool named "log" in a drift/snapshot workflow.

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 front-loaded sentence with no filler; the verb and resource come first and the purpose clause follows. It is efficiently sized, though that brevity partly explains the missing behavioral detail rather than reflecting full sufficiency.

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 3-parameter, no-output-schema logging tool the description correctly conveys what gets recorded and why, which is the minimum an agent needs to invoke it. It omits the surrounding workflow context (session/snapshot prerequisites, error behavior, aggregation semantics) that would make it complete.

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%, so the schema already explains command, exitCode, and the optional durationMs. The description restates exit code conceptually but adds no new meaning such as format expectations, ordering/sequencing rules, or guidance on when to supply durationMs. 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?

"Registra un comando eseguito con relativo exit code" names a specific verb (record) and resource (executed command + exit code), and the trailing clause "per comporre la ricetta finale di riproducibilità" states the downstream purpose. That purpose clause also separates it from siblings like driftguard_get_recipe and driftguard_create_snapshot, though no sibling is named explicitly.

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 only implied: an agent can infer it should call this after executing a command so the exit code lands in the reproducibility recipe. There is no explicit when-to-use vs. when-not, no statement about whether a snapshot/session must exist first, and no mention of alternatives for recording failures (driftguard_diagnose_failure exists for that).

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 load, and it does disclose the destructive semantics precisely: files created after the snapshot are deleted and modified/deleted ones are restored. It does not state whether the rollback itself is reversible, whether confirmation is required, or what permissions/state the workspace must be in.

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 no filler; the destructive effect follows immediately after the verb. It could be marginally tighter, but nothing is redundant.

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 single-optional-parameter destructive tool with no annotations and no output schema, the description covers what matters most (what gets deleted/restored). Missing pieces are irreversibility, requisite workspace state, and any confirmation behavior.

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 coverage is 100% and the snapshotId parameter already documents its own default ('se omesso, viene utilizzato il più recente'). The description adds no further parameter meaning, which is the baseline expectation here.

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 verb and resource ('rollback immediato (Undo) ripristinando il workspace allo snapshot precedente') and spells out the effect on files created, modified and deleted. It is clearly distinguishable from create/list snapshot siblings, though it never names them.

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 guidance on when to choose this over alternatives (e.g. creating a new snapshot, or inspecting a snapshot before restoring), and no exclusions or preconditions. The reader can only infer usage from the verb 'rollback'.

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