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

readOnlyHint=true already declares the safety profile, and '[READ]' merely restates it. The description does add useful context by enumerating the four anomaly categories the rollup covers, but it omits the aggregation window/time range and any auth or scoping constraints, which matter for interpreting an anomaly report.

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 compact lines with the read tag front-loaded and the parameter note last; nothing is padded. The category list is dense but each item is informative rather than filler.

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?

With no output schema, the description carries the return-value burden and does list the reported categories, which is adequate. However, for an anomaly rollup the missing time window/aggregation scope leaves an agent unable to interpret or scope results confidently.

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 0%, so the description must carry the parameter burden, and it does: 'target' is identified as an Ollama target name from config, and the default behavior (omit for the default) is explained. This goes meaningfully beyond the bare anyOf string/null schema.

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+resource: a read-only rollup reporting shadow models, digest drift, high-risk prompts, and blocked count. That is far more concrete than a restated name. It does not, however, distinguish itself from siblings like usage_events, server_status, or model_provenance, so it stops short of a 5.

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 statement of when to call this tool versus the many sibling reporting tools. The only guidance present ('omit for the default') concerns the parameter, not tool selection or 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?

Adds substantial behavior beyond the annotations: scan targets (secrets/PII/code/jailbreak), the block condition, the usage-log record, and the guarantee that the raw prompt is never stored. The annotations' destructiveHint=true goes unexplained since nothing in the described flow is destructive, but this is a mild gap rather than a direct contradiction.

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?

Front-loaded with [WRITE][risk=medium] and a one-line summary before the flow detail, then a compact Args block. Dense but every sentence carries information; only the repetition of the scan/gate sequence in both summary and body costs a little.

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 no-output-schema mutation tool with six parameters, the description covers inputs, gating logic, and side effects (usage log, no prompt retention) well. It stops short of describing the shape of a blocked or successful response, which is the one thing an agent cannot infer from the schema.

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?

With 0% schema description coverage, the description compensates fully: it documents all six parameters, gives the risk-band vocabulary for block_threshold (none/low/medium/high/critical) which the schema lacks as an enum, and explains target's default behavior. It adds real meaning the schema does not carry.

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?

Names a specific pipeline (scan + policy-gate + record + conditional generate) and states the key verb ordering, which clearly separates it from the plain sibling scan_prompt. An agent can tell that this is the guarded generate path, not merely a scanner.

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 makes the use context explicit ('run if allowed', 'only calls Ollama if allowed') and ties the gating behavior to the block_threshold parameter. It does not, however, compare itself against scan_prompt or a bare generate path, so the agent must infer when to pick this over those.

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?

The [READ] marker is consistent with readOnlyHint=true and adds nothing on its own, but the description goes beyond annotations by disclosing the returned content: each model is annotated with a policy verdict and unsanctioned "shadow" models surface as allowed: false. That is meaningful behavioral context for a policy-aware tool, though error/timeout behavior against a target is not covered.

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?

Front-loaded with the [READ] marker and the core purpose, then one short clarifying sentence, then the arg note. Every sentence earns its place; the "Args:" block is slightly formulaic but harmless.

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-param read-only lister with no output schema, the description covers what is listed, the special output case (shadow models with allowed: false), and the parameter's default semantics. It stops short of describing the return shape (e.g. name/hash fields) or failure modes against an unavailable target, which would make it fully self-sufficient.

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 carry the load, and it does: it identifies target as an Ollama target name from config and states that omitting it selects the default (local). It doesn't enumerate valid target names or where in config they live, so it is not fully compensating, but it is well above the schema alone.

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 opening states a specific verb and resource — installed models — plus the distinctive twist that each entry carries an allow/deny policy verdict. The "installed" scope implicitly separates it from running_models and model_details, but 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 implied by the resource scope (list what's installed rather than what's running), and the target arg guidance says to omit it for the default. There is no explicit when-to-use or when-not-to-use statement versus alternatives like running_models or model_details.

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?

Annotations already declare readOnlyHint=true, and the description's '[READ]' tag merely echoes that. It does add value by naming what the call returns (license/parameters/capabilities), but says nothing about error behavior when a model is absent or how large/rich the payload is.

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?

Front-loads the purpose in one bracketed line, then lists only the two parameters. Every sentence is useful, though the '[READ]' marker duplicates the annotation and the Args block could be folded together.

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 two-parameter read tool with no output schema and a clear annotation, the description supplies purpose, returned content, and both parameter meanings. Adequate; only absent-model/error semantics are unaddressed.

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 0%, so the description carries the full burden and mostly succeeds: it gives a concrete example format for 'model' ("llama3.2:3b") and explains 'target' as an Ollama target name with an explicit default when omitted. Minor gap: it doesn't say whether target accepts multiple entries or how names are discovered.

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 clear verb and resource — read details for a single model — and enumerates the returned content (license, parameters, capabilities). The 'one model' scope implicitly separates it from list_models/running_models, but 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?

No statement of when to use this versus list_models, model_provenance, or running_models. Only the target parameter's default behavior is hinted at ('omit for the default'), which is parameter guidance, not usage 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?

readOnlyHint=true already establishes this is a safe, non-mutating read, so the '[READ]' tag adds nothing beyond the annotation. The description does add operational context (it compares digests to pins and reports drift), but it omits what happens when a model has no pin, how drift is presented, or any cost/rate considerations. Adequate, not rich.

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 units, both earning their place: the purpose sentence is front-loaded and the Args block documents the single parameter tersely. No filler, no restatement of the tool name.

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 read tool with no output schema, the description covers what the tool does and how to call it. The main residual gap is the notion of a 'pin' — how it is established (via the pin_model_digest sibling) and what the drift report looks like — but this is minor at this complexity.

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% and the schema only exposes a bare 'Target' with default null, so the description must carry the meaning — and it does, defining target as an Ollama target name from config and stating that omitting it selects the default. That is genuinely useful semantics beyond the schema, though it doesn't say where the config value comes from.

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 concrete verb+resource: compare each installed model's digest against its pin and flag drift. That is clearly distinct from siblings like pin_model_digest (writes a pin) or model_details (inspects one model), even though no sibling is named explicitly. It stops just short of 5 because it never routes the agent relative to those alternatives.

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 the drift-audit tool, and 'omit for the default' tells it how to call the parameter. There is no explicit when-to-use, when-not-to-use, or comparison against pin_model_digest / model_details, so it lands at implied-usage level.

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?

Despite annotations declaring destructiveHint=true and idempotentHint=false, the description adds meaningful behavioral detail: the scan-then-gate-then-record-then-run sequence, the block_threshold gating logic, and the WRITE/risk=medium tag. This goes beyond what annotations provide.

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 [WRITE][risk=medium] prefix front-loads the mutation and risk profile efficiently. The Args block is structured and readable, though slightly verbose in listing trivial parameters.

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?

No output schema exists, so the description should explain what is returned (the model response? a policy decision?). It doesn't. For a mutation tool with pipeline behavior, the absence of return-value context is a notable gap.

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 documents all 6 parameters reasonably — model, messages, agent/user, block_threshold, target — but lacks detail on format syntax (e.g., valid risk bands for block_threshold, config target format). Adequate but incomplete.

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 uses a specific compound verb sequence: 'Scan + policy-gate a chat exchange, record it, then run if allowed.' This clearly states what the tool does. It is distinguishable from guarded_generate and scan_prompt, though it doesn't explicitly name those siblings to differentiate.

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 by the pipeline description but no explicit when-to-use vs alternatives is given. The relationship to guarded_generate and scan_prompt is unclear — an agent cannot tell which tool to pick for a given task.

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?

The [WRITE][risk=medium] tag adds context beyond the annotations, and the digest-source pointer is genuinely helpful. But with destructiveHint=true declared, the description never says whether pinning overwrites an existing pinned digest or whether the change is reversible via undo_apply — meaningful gaps for a destructive write.

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?

Very compact: one summary line plus two short arg lines, with the risk/write markers front-loaded. No wasted sentences.

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 destructive write with no output schema and no annotation-adjacent detail, the definition covers the essentials but omits overwrite semantics, reversibility, and any confirmation behavior — all relevant to a mutation tool.

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 carry the load. It does define both parameters minimally ('model: Model name', 'digest: The expected digest to pin (from list_models / model_details)'), including the provenance of the digest value, but adds no format, validation, or constraint detail.

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: 'Pin a model's expected provenance digest', with the parenthetical '(drift detection)' explaining why. It is distinguishable from siblings like model_provenance or list_models, though it never explicitly contrasts itself with 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 description implies when to use it (drift detection) and usefully points to where the digest value comes from (list_models / model_details). However it gives no when-not-to-use guidance and does not mention the related undo_apply tool that could reverse a pin.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the description does not need to restate safety. It adds the substantive content of the response (allow/deny policy and digest pins), which is genuine added context. It says nothing about permissions, freshness, or whether pins are scoped per model, so it stays at a baseline 3.

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 sentence with the read-only marker front-loaded and no filler. The '[READ]' tag is slightly redundant against readOnlyHint, but it is a cheap, useful scannable prefix and the sentence is appropriately sized for a zero-arg 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?

With no output schema and only a readOnlyHint annotation, the description carries the burden of explaining the return value, and it does so only in compressed form ('provenance digest pins'). It is enough for an agent to decide to call it, but thin on what the payload actually looks like or whether pins are per-model or global.

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 no parameter semantics to document and the baseline of 4 applies. The description correctly adds no redundant parameter talk.

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 concrete resource and its contents: the current model allow/deny policy plus provenance digest pins. That is far more specific than the bare name policy_view and tells the agent exactly what data comes back. It does not explicitly differentiate itself from siblings such as model_provenance, which partially overlaps on the provenance aspect.

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 statement of when to call this versus the write-side siblings (set_model_allowlist, set_model_denylist, pin_model_digest) or versus model_provenance. The '[READ]' prefix hints at the read-only role but gives no condition or context for selecting it. Usage is left entirely to inference.

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 only readOnlyHint=true in annotations, the description should carry heavy behavioral burden and it does: it discloses that nothing is written, no listener starts, request scanning vs. response streaming behavior, refusal of unparseable governed bodies, and the critical chokepoint-vs-enforcement caveat. This goes well beyond the annotation's safety hint.

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 front-loaded with the key [READ]/WRITES NOTHING framing and organized into clear paragraphs. It is slightly verbose in places but every sentence adds meaningful caveats or behavioral detail rather than restating schema.

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 beyond readOnlyHint, and 0% schema description coverage, the description supplies the missing context: what the tool does not do, what it returns (the caveat), how the proxy behaves, and parameter meanings. An agent has enough to invoke and interpret 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?

Schema coverage is 0%, so the description must explain parameters. It documents listen_host, listen_port (with default 11435), and target semantics reasonably, though listen_host's default (127.0.0.1) is omitted and format expectations are not fully specified.

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 opens with a specific verb+resource ([READ] How to run the transparent capture proxy) and immediately differentiates itself from siblings by clarifying it WRITES NOTHING and starts no listener. An agent can tell this is a guidance/composition tool rather than an execution tool without checking the schema.

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?

It clearly frames the guidance context ('how to run... and what it does NOT guarantee') and explains the composition behavior, but does not explicitly name alternative sibling tools or state precise when-not-to-use conditions (e.g., when to use running_models or server_status instead).

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?

Annotations already declare the destructive, non-idempotent, non-readonly profile, so the safety bar is lowered. The description adds genuine value beyond that by disclosing the deny/allow policy gate that can refuse the operation, which is not captured in annotations.

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?

Front-loads the operation type and risk tag, then the one-line purpose, then the args. The args section is justified by the 0% schema coverage, and there is no padding.

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 medium-risk write operation it covers the key gaps (the policy gate and both parameters) while annotations handle the safety profile, but it says nothing about the nature of the pull (registry download, potential size/time cost, or failure behavior). Adequate but leaves meaningful operational questions open.

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 carry the param burden, and it does: it defines 'model' and explains that 'target' is an Ollama config name that should be omitted for the default. This compensates well for the empty schema descriptions.

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 ('Pull a model') and tags the operation type and risk level via '[WRITE][risk=medium]'. This clearly separates it from read-oriented siblings like list_models and model_details, though it does not name a specific sibling to contrast with.

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?

Adds one useful condition ('refused if it violates the deny/allow policy') that tells the agent when the call fails, but gives no explicit guidance on when to pull versus unload/remove/pin operations. Usage is largely inferred from the purpose statement.

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?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds substantial context the annotations cannot: undo/re-pull recording, the interaction with the allow/deny policy, the reversible=false outcome for denied models, and that dry-run carries the same verdict. This is exactly the beyond-annotation disclosure an agent needs before a destructive call.

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?

Front-loads the risk marker and destructive warning, which is the right structure for a high-risk tool. The undo-policy explanation spans several sentences and restates the dry-run verdict point, so it is slightly more verbose than needed, but most sentences earn their 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 destructive, non-idempotent tool without an output schema, the description covers the critical unknowns: reversibility, undo recording, policy preconditions, and dry-run behavior. It does not detail the actual return payload beyond reversible=false, but the essential decision inputs are present.

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 carries the full burden and documents all three parameters, including intent for dry_run ('return what WOULD be deleted without deleting') and target ('Ollama target name from config; omit for the default'). Only model is covered tersely, but the semantics are adequately conveyed, so it compensates for the empty schema.

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 ('Delete a local model') and immediately flags the WRITE/high-risk nature. It is clearly distinguishable from siblings like unload_model (unload vs. permanent delete) and pull_model, so an agent can route correctly.

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?

Gives an explicit when-to-use instruction for the dry_run preview ('pass dry_run=True to preview'), which is actionable guidance. It does not, however, contrast itself against the semantically close sibling unload_model or state when not to use it, so it stops short of full alternative routing.

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?

Annotations already declare readOnlyHint=true and the description reinforces it with a '[READ]' marker, so the safety profile is covered twice over. It adds the useful detail that results include VRAM footprint and residency expiry, but says nothing about freshness, scoping to a single target, or failure modes when the target is unreachable.

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 key information (read-only, currently loaded, what is returned) is front-loaded in a single line, with the argument detail tucked into an Args block. The prose is tight with no filler; the Args block is slightly heavyweight for one optional parameter.

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?

With no output schema, the description must at least signal what comes back, and it does (VRAM footprint + residency expiry). For a zero-required-parameter read tool with annotations covering safety, that is close to sufficient, though the shape/units of the returned figures remain unknown.

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 carries the full burden for the single parameter — and it does: 'Ollama target name from config; omit for the default' explains both meaning and the optional/default behavior. No format examples or naming conventions for targets are provided, which keeps it from a 5.

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 operation (list currently loaded models) and even names the returned content (VRAM footprint + residency expiry), which lets an agent separate it from list_models (catalogue listing) and vram_usage. It stops short of explicitly naming those siblings, so differentiation is inferable 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 by the phrase 'currently loaded models' and the '[READ]' tag. There is guidance for the target argument ('omit for the default') but no statement of when to prefer this over list_models, vram_usage or server_status.

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?

Annotations only declare readOnlyHint=true, so the description carries real added weight: it discloses that no Ollama/LLM call is made, that the scan is deterministic, and that it returns findings plus a weighted risk band. That is meaningful behavior beyond the annotation, though it omits details like severity thresholds or rate limits.

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?

Front-loads the [READ] tag and the one-line purpose, then the key behavioral note, then usage. The trailing Args block restating a self-evident parameter is slightly wasteful but overall tight and well-ordered.

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-parameter read tool with no output schema, the description usefully sketches the return value (findings + weighted risk band) and the deterministic nature. Nothing critical for invoking it correctly is missing, though the output shape is described only in the abstract.

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%, but there is only one parameter and the description's 'Args: text: The text to scan' is essentially redundant with the schema title 'Text'. It neither compensates with format guidance (e.g., size limits, encoding) nor leaves anything genuinely unclear, so a baseline 3 fits.

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 (scan) and resource (a text/prompt) with a clearly enumerated scope: secrets / PII / code / jailbreak. It also implicitly distinguishes itself from the sibling 'guarded_generate' by being the pure scan rather than the generation path.

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 says to 'use it to pre-check anything before sending it to a local model,' which gives a clear usage context. It stops short of naming the alternative (guarded_generate) or stating when NOT to use it, so not a 5.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the '[READ]' prefix merely restates that. The description adds that the call returns version info, but says nothing about auth requirements, failure/timeout behavior, or latency, which would matter for a reachability probe.

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 elements, front-loaded with the purpose before the argument note. No filler sentences; every line 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 simple one-optional-param read probe with no output schema, the description covers what is checked (reachability + version) and how to select a target. Nothing essential to invoking 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 0%, so the description carries the burden for the single 'target' parameter. It explains that target is an 'Ollama target name from config' and that omitting it selects the default, which is real meaning beyond the bare anyOf string/null schema.

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+resource: it checks Ollama reachability and reports its version. That is clearly distinct from the sibling tools (list_models, running_models, pull_model, etc.), though it never explicitly names what it is not for.

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 (call this to see whether the Ollama server is up and what version it runs), and the param note 'omit for the default' gives a small routing hint. There is no explicit when-to-use/when-not or reference to alternative siblings.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, but the description adds real value: the [WRITE][risk=medium] tag and the fact that this is a full replacement whose empty value means allow-all (a dangerous default worth surfacing). The one gap is that the annotation idempotentHint=false sits oddly with 'Replace' semantics, and no side effects (audit entries, immediate enforcement) are disclosed to explain 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?

Extremely economical: a leading write/risk marker, one sentence of semantics, and one argument line with syntax plus example. Nothing is redundant and the risk/write signal is 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?

For a one-parameter, no-output-schema mutation whose annotations already carry the destructive profile, the description supplies the argument format and the critical empty-value behavior. It omits revert guidance despite an undo_apply sibling existing, and does not describe enforcement timing, minor gaps for a medium-risk write.

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% and the single 'models' parameter is undocumented in the schema, so the description carries the load. It does so well: it specifies shell-glob syntax, gives concrete examples like ["llama3.*", "qwen*"], and defines the empty-list edge case as allow-all. It does not say how malformed patterns are handled, which keeps it from a 5.

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+resource: 'Replace the model allowlist', which immediately distinguishes it from set_model_denylist and other model-management siblings. 'Replace' also clarifies it is a full overwrite rather than an append. It stops short of naming the sibling it is not, so it is clear but not maximally differentiated.

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 when-to-use guidance: nothing says when an allowlist is preferable to set_model_denylist, what precedence applies if both are set, or whether the change takes effect on already-running models. The 'empty = allow-all' note is a semantic default, not usage routing. The agent must infer the operating context from the tool name alone.

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?

Annotations already declare the write, destructive, and non-idempotent profile, so the [WRITE][risk=medium] tag is largely redundant. The description does add real context beyond the annotations: "Replace" discloses full-overwrite semantics (existing entries are discarded) and "deny patterns always win" discloses precedence over the allowlist. It says nothing about validation, persistence, or required permissions.

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?

Terse header plus a one-line Args block is front-loaded and waste-free. The risk tag partially duplicates the annotations, but the size is well matched to a one-parameter 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?

Given a single parameter, no output schema, and annotations covering the safety profile, the description is close to sufficient: it names the resource, the replacement semantics, the precedence rule, and the pattern syntax. It omits interaction with the allowlist tool and any confirmation/permission requirements, which leaves a mild gap.

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 0% and the schema only types the single parameter as an array of strings, so the description must carry the burden. "Shell-glob patterns of forbidden model names" adds the matching syntax (shell-glob) and the meaning of each element, which is exactly what the schema omits.

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 ("Replace the model denylist") plus the scope qualifier that deny patterns take precedence. An agent can distinguish it from the sibling set_model_allowlist by the resource word alone, 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?

No when-to-use or when-not-to-use guidance is given; the agent is not told when to choose this over set_model_allowlist, pin_model_digest, or removal tools. The "deny patterns always win" note hints at precedence relative to the allowlist but does not state 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?

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false; the description adds real value on top by explaining that the actual risk tier lives with the dispatched inverse tool, that dry_run previews without executing, and that the token is single-use. It does not describe what the inverse dispatch returns or what failure looks like, so it is not maximally transparent.

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 [WRITE][risk=medium] tag and the core behavior/constraint sentences are front-loaded and efficient, and the Args block is compact. The Args list partially restates schema parameter names, but each entry adds meaning, so waste is minimal.

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 non-idempotent, destructive, three-parameter mutation with no output schema, the description supplies the missing context an agent needs: the risk marker, the once-only token rule, the preview path, and parameter sourcing. Only the result shape of the dispatched inverse call is left unspecified, which is a minor gap.

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 carries the full burden and largely meets it: undo_id is traced to its source (undo_list or `_undo_id` in a write result), dry_run is defined as a preview flag, and target is explained as pass-through to the inverse tool. The pass-through semantics of `target` (when it is rejected or ignored) remain somewhat vague.

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+resource ('Apply a recorded undo') and explains the mechanism (dispatching its inverse tool), which separates it cleanly from the sibling undo_list that only lists tokens. An agent can immediately tell what this does that its siblings do not.

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?

It states the context of use (apply a token obtained from undo_list or an `_undo_id` in a write result) and offers dry_run=True as the preview path, plus the constraint that a token can be applied only once. There is no explicit when-not-to-use or named alternative beyond undo_list, so it stops just short of a 5.

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?

Annotations only supply readOnlyHint=true; the description goes well beyond that by disclosing the return shape, that truncation is *measured* via an extra-row fetch, and that effectVerified=false means the reversed change is only PROBABLE, with a caution to check live state and not over-report. This is meaningful operational context the annotations cannot carry.

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?

Front-loaded with purpose and the sibling handoff, then structured paragraphs for return value and the effectVerified caveat. Every sentence carries information, though the emphasis on truncation being 'measured, not guessed from a length coincidence' is slightly verbose for the value it adds.

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?

With no output schema present, the description supplies the return JSON shape, the meaning of every field an agent must act on (returned, limit, truncated, effectVerified), and the follow-up behavior for truncation. Nothing needed to call or interpret 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 0% and no param has an enum, so the description must compensate, and it does fully: limit is documented as default 50 / capped at 500, and target is documented as ignored with the reason (host-local undo state, kept for CLI uniformity).

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 ('List recorded, not-yet-applied undo tokens') plus ordering ('most recent first'). The [READ] tag and the reference to undo_apply make it clearly distinguishable from the sibling that actually applies tokens.

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 routes the agent: 'Use the undoId with undo_apply.' and tells it to re-run with a higher limit when truncated rather than reporting a partial list as complete. It lacks an explicit 'when not to use this' condition, so it falls just short of a 5.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, so safety is covered. The description adds real value beyond them by disclosing the mechanism (keep_alive:0) and a 'risk=medium' signal, telling the agent exactly how eviction is performed rather than just that it mutates state.

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?

Front-loaded with the write/risk classifier and the core action before the Args block, with no wasted prose. The Args section slightly restates the header's intent but is compact and scannable.

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 low-complexity two-parameter write tool with no output schema and annotations covering the safety profile, the description supplies purpose, mechanism, and both parameter meanings. The only material gap is the unaddressed overlap with the remove_model sibling.

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 carry the load — and it does, documenting both parameters: 'model' as the model name to unload and 'target' as an Ollama target from config, including the important 'omit for the default' behavior that the schema does not convey.

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: 'Evict a model from VRAM (keep_alive:0)' — an agent immediately knows this frees GPU memory rather than deleting a model. However, it never distinguishes itself from the very similar sibling remove_model, leaving the agent to infer that 'unload' is memory-eviction and 'remove' is disk-deletion.

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 by the header tag '[WRITE][risk=medium]' and the VRAM-eviction phrasing, so an agent can infer it's for freeing memory. But there is no explicit when/when-not guidance and no pointer to the near-identical remove_model sibling, which is exactly the ambiguity that needed resolving.

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?

readOnlyHint=true is already declared, and the description still adds significant behavioral context: the exact return envelope, the meaning of truncated, and the explicit warning not to conclude 'no risky prompts were observed' from a truncated result. That goes well beyond the annotation.

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?

Front-loaded purpose line followed by a compact Args block and return-contract paragraph; nothing is wasted and the crucial truncation caveat is prominent. The Args list partially echoes schema names, but each entry adds a semantic gloss, so the cost is low.

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?

With no output schema and zero schema-description coverage, the description compensates by documenting the return envelope and the truncation interpretation rule. Nothing an agent needs to invoke or correctly read this call 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 0%, so the description carries the full burden and meets it: all five parameters (model, risk_level, allowed, since, limit) are explained, including the non-obvious allowed=True/False semantics and the enumerated risk bands (none/low/medium/high/critical) absent from the schema. Only the default limit value is left unstated.

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?

Specific verb+resource: 'Query the observed-usage log', with a clarifying parenthetical ('route-through prompts + their findings') that distinguishes it from the raw-scan/policy siblings like scan_prompt and anomaly_report. An agent can identify what this returns without opening the schema.

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 explicit when-to-use/when-not versus alternatives among the 20 siblings (e.g., anomaly_report vs raw event listing). It does give filter semantics and a strong interpretation caveat about truncated results, but routing guidance is only implied.

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?

The [READ] prefix is consistent with readOnlyHint=true and adds no contradiction. Beyond the annotation, the description discloses one useful behavioral trait: models exceeding a supplied budget are flagged. It says nothing about output format beyond that flag or about cost/latency of the call.

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?

Front-loaded summary sentence followed by a compact Args block; each line carries information. The [READ] tag slightly duplicates the readOnlyHint annotation but is cheap and useful for scanning.

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 two-parameter read tool with no output schema, the description covers the operation, both parameters, and the one non-obvious output behavior (over-budget flagging). Missing only return-shape detail and sibling routing, which are minor here.

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, and it does document both parameters: budget_bytes as an optional VRAM budget with over-budget flagging behavior, and target as an Ollama config name that defaults when omitted. Only the byte unit/format of budget_bytes is left implicit.

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?

Names a specific verb-like operation and resource: reports total VRAM consumed by loaded models and flags models over budget. It is clearly distinguishable from siblings like server_status or running_models, though it never explicitly contrasts itself with 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?

There is no statement of when to reach for this tool versus alternatives (e.g. running_models or server_status), and no prerequisites or exclusions. The only usage-like guidance is 'omit for the default' on the target parameter, which is parameter-level rather than tool-selection guidance.

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