driftguard_network_check

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, and it leaves the most consequential question unanswered: whether the tool merely reports a verdict or actually blocks/executes anything. The phrasing "per bloccare script malevoli" reads as if the tool enforces blocking, which an agent could mistake for a state-changing action. It does usefully disclose the detection heuristics (piped scripts, raw IPs, unverified domains), which earns some credit above the floor.

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 comes first and the detection patterns follow. It is slightly dense — the blocking intent and the pattern list are packed into one clause chain — 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 one-parameter inspection tool with a fully documented schema and no output schema, the description covers what is scanned but not what comes back (a verdict? a list of findings?) or whether the command is ever executed. Those gaps matter for an agent that must decide whether calling this is safe and what to do with the result.

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?

Only one parameter exists and the schema documents it fully (100% coverage), including a description stating it is the shell command containing URLs or network calls. The prose adds the categories of network tool it recognizes (curl, wget, npm, pip), which slightly enriches what the agent knows to pass in, but nothing about format, length limits, or multi-command strings. 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?

The description gives a specific verb ("Ispeziona" / inspect) and a clearly scoped resource (shell commands containing network calls), and enumerates concrete examples of what it looks for (curl, wget, npm, pip, piped `| bash`, raw IPs, unverified domains). This is far more specific than the name alone. It does not, however, distinguish itself from likely-overlapping siblings such as driftguard_safety_check or driftguard_policy_check.

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 this is a pre-flight inspection of a command that touches the network, but the description never says when to call it versus driftguard_safety_check, driftguard_policy_check, or driftguard_dry_run_command. No conditions, prerequisites, or exclusions are stated.

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