model_provenance

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.