Local models on this computer

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses locality ('nothing leaves it'), latency ('a few minutes'), the free cost of testing, that downloads consume the drive Ollama uses, and that nothing downloads without user consent. That is meaningful behavioral context the annotations do not carry. It stops short of describing response format or failure behavior for downloads.

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 entire definition is one long run-on sentence dense with nested parentheticals, which makes it hard to scan despite being front-loaded with the main purpose. The aside about Arena rating few small models and the 8-question test is justification rather than invocation guidance and could be compressed. Information density is high but structure is poor.

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, four actions and three optional parameters, the description covers what each action does, what suggest returns in outline, timing, and the consent gate for downloads. Coverage is broadly sufficient for correct invocation, though return shapes for status/download are only loosely sketched.

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%, so the baseline is 3, but the description adds two things the schema does not: that 'model' for download defaults to the best-rated suggested model, and the functional coupling between actions and parameters (test needs model, download accepts yes). That is genuine added meaning over the enum 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?

The description names a concrete resource (Ollama models on this computer) and enumerates the four actions it exposes: suggest, test, status and download. An agent can tell it is a local-model inventory/test/download tool. It does not differentiate itself from the sibling tool named 'models', leaving potential overlap ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each action carries an explicit use case: 'suggest (the default) says all this; test, with model, starts the test; status says how a test or a download goes; download asks the user...'. That is clear per-action routing guidance with a stated default. There is no explicit when-not-to-use or reference to sibling tools as alternatives.

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