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

Annotations already declare this is not read-only, not destructive, and not open-world. The description adds important context beyond annotations: it emphasizes the operation is heavy, runs real inference, uses a warmup to absorb load time, and reports runtime-provided versus measured speeds.

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 crucial 'HEAVY' warning and the core purpose, then efficiently covers metrics and the models[] comparison path. Every sentence adds practical information without unnecessary repetition.

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 the output schema and rich parameter descriptions, the description is largely complete: it explains the benchmark's measurement approach, the warmup, and multi-model comparison. It could still clarify whether a model must be loaded first or how model versus models selection should be handled, but the core behavior is clear.

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 documents all seven parameters, including warmup behavior and the models[] comparison mode. The description reinforces the models[] comparison semantics and warmup purpose, but adds little beyond the schema's own parameter 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 states a specific action and resource: it runs real inference and measures a model's performance on this machine. It lists concrete metrics (time-to-first-token, generation tokens/sec, prompt-processing speed) and distinguishes itself from ordinary generation tools by framing the operation as measurement and comparison.

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 signals the tool's cost profile with 'HEAVY' and explains the comparison use case via 'Pass models[] to compare several models with the same prompt.' However, it does not explicitly say when not to use it or name an alternative such as complete for normal one-off 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?

Annotations already declare readOnly/non-destructive/closed-world, so the bar is lower, and the description still adds substantial context: where execution actually lands (`provider`, `host`, `local` fields), the local-only default and the fallback flag, schema-validated `parsed` output, and token streaming via MCP progress notifications when a progressToken is supplied. These are execution facts an agent could not recover from the annotations or schema.

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?

It is front-loaded with the purpose, then the provider-resolution rule, then a compact feature list, and no sentence is pure filler. It runs long and dense as a single paragraph, which slightly hurts scanability, but the information density justifies the length.

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 17-parameter tool with nested message/responseFormat objects and an output schema, the description covers the behaviors an agent most needs to call it correctly: provider resolution, output locality fields, structured-output validation, vision inputs, context window, and streaming. Remaining gaps are minor since the output schema and 82% schema coverage handle return shape and most parameter detail.

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 82%, so the baseline is 3, and the description earns above that by explaining what the schema only names: contextLength as a num_ctx window that must be raised to avoid truncation on long inputs, responseFormat's validated `parsed` field, and image content parts for vision models. Undocumented-in-prose params such as temperature, topK, stop, and repairAttempts are covered by the schema itself.

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 sentence states a specific verb and resource — offload a completion to a chosen model — and frames the value (cost, privacy). It is clear what the tool does, but it never distinguishes itself from the sibling `delegate` tool, despite the near-identical framing, so an agent must infer the split.

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 real usage guidance for the provider parameter (omit it and the server picks a live LOCAL provider; hosted only under LOCAL_AI_ALLOW_HOSTED_FALLBACK), which tells the agent how to call it safely. But there is no explicit statement of when to choose this over `delegate`, `embed`, or `benchmark`, so routing between siblings is left 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?

Annotations only declare the safety profile (not read-only, open-world, not idempotent), and the description adds substantial behavior beyond that: the full routing preference order, the no-load-cost preference, VRAM-fit and CPU-fallback behavior, the 14-day benchmark expiry, and the env var controlling hosted fallback. It also discloses that the response carries a 'routing' block, which the annotations cannot convey.

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 headline 'ONE CALL' and then organized by ranking rules, hosted policy and return shape; nearly every clause carries information. Minor redundancy where allowHosted's env-var behavior is restated in both the description and the schema, and the paragraph is dense enough to be slightly hard to scan.

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 21-parameter composite tool with an output schema, the description covers the decision logic an agent needs to call it correctly, and correctly defers return-shape details to the schema. It does not note that one of prompt or messages is effectively required, which is the main remaining 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 86%, so the baseline is 3, but the description adds meaning that the schema lacks: how the task enum maps to specialist vs general model tiers, the ~20% size-tier grouping and benchmark tie-break, and the interaction between allowPull/allowHosted and local availability. Parameters such as maxSizeBytes, contextLength and repairAttempts are not elaborated beyond their schema text.

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?

Opens with a specific verb and resource: 'ONE CALL to offload work locally: pick the best model for a task on THIS machine, make it ready, and run it.' This distinguishes the composite routing tool from single-purpose siblings like complete, suggest_model, ensure_model and load_model.

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 explicit selection conditions for hosted vs local ('Never uses a hosted provider unless allowHosted is true...') and the allowPull gate, plus points to the benchmark sibling for recording speeds. It does not explicitly say when to prefer a sibling such as complete or suggest_model instead, leaving that 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds genuinely new context by disclosing redaction behavior ('API keys never shown, only whether one is set'). It also notes the snapshot actively probes providers and hardware, implying latency cost, though it does not state how long the probe takes or how large the output 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?

A single front-loaded sentence whose key claim ('read-only snapshot for troubleshooting') comes first, followed by the contents and the intended use. The comma-separated inventory is dense but every clause carries information; a bulleted list would read better but nothing is wasted.

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 an output schema present, the description need not explain return values, yet it still previews the payload contents so an agent knows what it is getting. Combined with rich annotations and zero parameters, nothing an agent needs in order to call this 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No misleading parameter references appear.

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 the specific deliverable ('one read-only snapshot for troubleshooting') and then enumerates exactly what it contains: effective configuration, per-provider detection result, latency and error, benchmark speed cache, and hardware probing. That enumeration clearly separates it from siblings like health_check, system_resources, and fit_check, which each cover only part of this picture.

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 a concrete use context ('for troubleshooting') and an explicit next action ('paste its output into bug reports'), so an agent knows the intended scenario. It stops short of naming when-not-to-use it or pointing to alternatives such as health_check for a quick liveness probe, which keeps it from 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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds the default routing behavior (live local provider holding the model) and a one-vector-per-input guarantee, but the routing detail is largely restated in the provider schema description, so added value is modest.

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?

Three short sentences with the core capability front-loaded and no filler. The 'DELEGATED EMBEDDINGS:' prefix mildly duplicates the title but otherwise every clause carries information.

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 an output schema present, return shape needn't be explained, and all three parameters are fully described in the schema. The description covers routing defaults and output cardinality, leaving only minor gaps such as error behavior for unsupported models.

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%, including the provider enum and the meaning of omitting it, so the baseline is 3. The description adds no syntax, batching, or model-selection semantics beyond what the schema already documents.

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 ('Generate embeddings') and the accepted input shapes ('a string or an array of texts'). It is clearly distinct from siblings like complete or delegate by resource, but the description never names an alternative to contrast against.

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?

'Without provider, runs on the live local provider that has the model' gives context for the optional provider path, but there is no explicit when-to-use guidance versus siblings such as complete or fit_check, and no stated 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?

Annotations declare a non-read-only but non-destructive, idempotent, open-world operation; the description adds the material detail that it may download a model, may unload OTHER loaded models (evict 'lru' or 'all'), and verifies afterward. That side effect on shared state is exactly the kind of context annotations alone would hide, especially given destructiveHint=false. It stops short of saying what happens on fit failure or whether evictions are restored.

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 dense sentence front-loads the outcome and the pipeline in execution order, followed by a single sentence covering the safe-preview mode. There is no filler, and the ordering mirrors how the operation actually proceeds.

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 an output schema, full schema coverage, and rich annotations, the description only needs to convey the composite behavior and side effects, which it does. Minor gaps remain around failure modes (what if the model cannot fit even after eviction) and what the verify step returns, but nothing blocking 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 100% and every parameter, including the evict enum and dryRun, is already documented in the schema. The description restates pull, evict values, and dryRun without adding semantics such as how kvCacheType or contextLength affect the fit estimate. Baseline 3 applies when the schema carries the load.

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 outcome ('make a model ready') and enumerates the exact pipeline it composes: pull, VRAM fit check, evict, load, verify. Because those steps correspond directly to siblings like pull_model, fit_check, load_model, and unload_model, an agent can immediately tell this is the one-call orchestrator rather than any single-step tool.

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 only explicit usage guidance is 'Use dryRun:true to get the plan without changing anything,' which covers the planning case well. There is no statement of when to prefer this over the granular siblings (e.g. when you already know the model is pulled, or when you want to inspect before committing), so the agent must infer the orchestration-vs-single-step tradeoff.

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 description reveals complex internal behavior beyond annotations, detailing how it uses model architecture, estimates memory for weights and KV cache, and crucially, how it credits back memory for already loaded models.

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?

Despite being a long paragraph, the description is highly efficient. It flows logically from the question (will it run?) to the mechanism (calculation) to the output (target resource), with no redundant phrasing.

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 the technical complexity involving VRAM, KV cache, and resource allocation strategies, the description is complete. It details all necessary components of the check, including fallback mechanisms and memory accounting.

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 description is highly semantic, explaining exactly which parameters drive the resource calculation—for instance, referencing 'layer architecture' and 'KV cache for a context length.' This adds significant value over the 100% schema coverage.

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 clearly states the tool's purpose: to determine if a model will run on the machine and precisely where (GPU/CPU/Partial). It distinguishes itself by focusing on resource compatibility rather than merely listing models.

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?

While it does not explicitly name sibling tools it replaces, its function is clearly defined as a resource pre-check prerequisite, which provides sufficient operational context for its use case.

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, idempotentHint, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered and the description correctly stays consistent with it. It adds that version and live metrics are reported, which is useful behavioral context. However, the claim that omitting the provider checks every configured provider 'including hosted ones' conflicts with the schema's statement that omission restricts to local providers unless LOCAL_AI_ALLOW_HOSTED_FALLBACK is set — a misleading scope claim in the description itself.

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 sentences, front-loaded with the core action and with the no-argument scope stated second; nothing is padding. The only cost is that the second sentence introduces an inaccurate scope claim rather than a needed clarification.

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 an output schema present, the description needn't explain return values, and rich annotations cover the safety profile. What an agent needs to call it correctly is present. It loses a point because the hosted-provider default is stated in a way that contradicts the schema, potentially causing wrong expectations about which providers get probed.

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 has a documented enum and a detailed omit-behavior note, so the schema does the heavy lifting. The description's 'Without provider...' sentence partially duplicates that note but adds nothing about the enum values themselves. Baseline 3 applies when the schema fully documents the parameter.

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 verb and resource ('check whether each provider is reachable and report its version'), which clearly separates it from sibling tools like list_providers or model_info. It also names the metrics returned (vLLM KV-cache usage), giving the agent a concrete idea of output. It stops short of explicitly naming the sibling it should be preferred over, so a 4 rather than 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?

The second sentence explains the no-argument behavior ('checks every configured provider'), which is about scope rather than when to call it. There is no explicit guidance such as 'use before load_model to verify a provider is up' or 'use list_providers instead when you only need configured names', so usage must be inferred from the tool name and sibling set.

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 establish read-only and idempotent semantics, so the description is not asked to carry the safety profile. It adds real behavioral context the annotations cannot: it is a point-in-time snapshot of live providers, and metrics are conditional ("where the runtime reports them"), warning the agent that VRAM and context length may be absent rather than zero.

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: scope first, reported metrics second, the caveat about incomplete reporting last. No filler and nothing repeated from the title.

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 an output schema present, the description need not enumerate return fields, and it correctly stays out of that territory while still flagging that per-model metrics are best-effort. It stops just short of telling the agent that omitting provider aggregates across all live providers versus querying a single one.

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 optional provider parameter is fully documented in the schema, including the omit-to-let-server-choose behavior and the hosted-fallback caveat. The description only echoes the result of omission with "on each live provider"; per the high-coverage baseline, 3 is correct.

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 models") plus a scope qualifier that does real work: "currently loaded into memory on each live provider." That qualifier is what separates it from the sibling list_models, so an agent can pick between them without opening either 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?

The phrase "currently loaded" implies you call this when you need to know what is resident right now rather than what is available on disk, but no alternative (list_models, model_info, list_providers) is named and no when-not condition is given. Usage is inferable rather than stated.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that results are keyed by provider and scoped to 'live' providers, but it does not mention other behavioral details such as error handling or the hosted-fallback caveat that appears in the schema.

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 sentences with no wasted words, and the main capability is front-loaded before the optional filtering note.

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 an output schema, rich annotations, and complete parameter documentation, the description is largely sufficient. It could be slightly stronger by distinguishing this tool from list_loaded or clarifying what 'available' means relative to installed models.

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 enum and provider description are already fully documented, including the hosted-fallback condition. The description's note that passing 'provider' queries just one provider adds only modest reinforcement and does not go beyond the 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 states a specific verb and resource ('List models') and clarifies scope ('installed/available on each live provider, keyed by provider'). It is clear enough to distinguish from list_providers, but it does not explicitly contrast with the sibling list_loaded, which likely covers a related concept.

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 implies usage by noting that passing 'provider' queries just one provider, which is useful guidance. However, it does not say when to use this versus list_loaded, search_available, or model_info, so the agent must infer the distinction.

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?

Beyond the safety guarantees provided by the annotations (readOnly, idempotent), the description specifies exactly what data points are returned (host, kind, live status, capabilities). This provides valuable structural context to the agent.

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 dense but efficient. Despite its length, it packs significant value into one statement by listing all supported technologies and the data elements returned, making the sentence highly functional.

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?

The description is extremely comprehensive. Given the presence of an output schema (handled by contextual completeness rules), listing all potential return fields (host, kind, status, capabilities) in the description provides a complete picture of the tool's capabilities.

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 100% schema coverage, the baseline is high. The description adds semantic value by listing all the supported runtime types, effectively defining the universe of the `provider` enum before the agent even checks the schema structure.

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 tool's purpose is highly specific: to list configured model runtimes. It explicitly enumerates the types of runtimes it supports (Ollama, LM Studio, vLLM, hosted instances), making its function unambiguous compared to list_models or list_loaded.

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?

While it does not explicitly state 'use this for listing infrastructure, not models,' the strong focus on 'model runtimes' provides sufficient distinction from sibling tools like list_models. Its usage scope is clearly defined, even if direct exclusionary guidelines are absent.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds some context — the fallback to the 'live local provider that has the model' and residency via keepAlive — but does not say what happens if no local provider has the model (error vs. implicit download), nor that loading reserves memory and may evict existing residency. That omission matters for a non-destructive but resource-consuming mutation.

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?

Three short sentences, front-loaded with the action and outcome, then optional parameters, then the default-provider rule. There is no filler and every clause carries information the agent needs before calling.

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?

An output schema exists and annotations carry the safety profile, so the description needn't explain return values; what it does cover is targeted and sufficient for a 4-parameter tool. It falls short of 5 because the failure mode when the model is absent locally — the most likely error path given the sibling `ensure_model`/`pull_model` tools — is 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 100%, so a baseline of 3 applies, and the description does add meaning beyond the schema by explaining the operational consequence of omitting `provider` ('uses the live local provider that has the model') rather than just 'let the server choose'. The keepAlive and contextLength mentions largely restate the schema, so it stops short of 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?

States a specific verb and resource ('Load a model into memory') plus the outcome ('ready for inference'), which tells an agent this is a load/warm-up step rather than an inference call. The 'on ONE provider' constraint scopes the operation, but the description never differentiates itself from the closely related sibling `ensure_model` (or `pull_model`), leaving the agent to guess which is appropriate.

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 outcome statement and by the default rule 'Without provider, uses the live local provider that has the model.' Nothing tells the agent when to prefer this over `ensure_model`, `pull_model`, or `list_loaded` first, and no preconditions (must the model already exist locally?) 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds that provider omission queries live local providers and that some fields are available only 'where available,' but it does not cover error behavior, latency, or ambiguities beyond what annotations and schema 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?

Two sentences, front-loaded with the core purpose and then the key provider behavior. No unnecessary repetition or 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?

For a simple read-only metadata tool with an output schema and fully described parameters, the description is largely complete. Minor gaps around not-found behavior or ambiguity handling remain, but the core invocation context is covered.

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 both parameters are already documented in the schema. The description does not add syntax or semantic detail beyond the schema's provider fallback notes, so the baseline 3 is appropriate.

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 clearly states a specific resource (one model) and enumerates the metadata returned (family, parameter size, quantization, context length, layer architecture). It is distinct from list-style siblings, but it does not explicitly name or contrast with list_models/list_loaded.

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 explains the provider-omission behavior ('Without provider, queries the live local providers that have the model'), which implies usage context. However, it does not explicitly say when to use this tool versus list_models, list_loaded, or other sibling tools.

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 annotations already declare readOnly=false, idempotent=true and destructive=false, so the safety profile is covered. The description adds one useful behavioral fact — completed jobs are returned unchanged, reinforcing the idempotent semantics — but says nothing about what happens to in-flight state, partial downloads, or whether resources are freed.

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 sentences, zero filler, with the scoping condition (background:true) front-loaded and the edge-case behavior second. Every clause carries information.

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 mutation with rich annotations and an output schema (so return values need no explanation), this is nearly complete; the only missing piece is what an agent should do if the job is already finished or unknown, and whether partially downloaded data is retained.

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 jobId parameter is already documented as "Job id returned by pull_model". The description reinforces the provenance of that id via the pull_model reference but adds no format, validation, or error-case semantics beyond the 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 ("Stop a background pull") and qualifies it with the exact originating call (pull_model { background: true }), which cleanly separates it from the sibling pull_status (which monitors rather than cancels).

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 a clear precondition for use: only pulls started with background:true are cancellable, implying foreground pulls are out of scope. It does not explicitly name an alternative (e.g. pull_status for monitoring progress) or state what to do if the job already completed, so it falls short of full when/when-not 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?

The description carries substantial behavior beyond the annotations: multi-GB size, long duration, streaming via MCP progress notifications gated on a progressToken from the client, an immediate jobId under background:true, and provider selection fallback (already-has-model, else first live local provider, with LOCAL_AI_ALLOW_HOSTED_FALLBACK as the hosted escape hatch). The "a second call for the same model joins the running job" note gives concrete meaning to idempotentHint:true, and nothing conflicts with the 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?

The cost warning is front-loaded as the first token ("HEAVY:"), then progress mode, then background mode, then provider resolution — an efficient ordering with no filler sentences. Every clause either sets expectations or changes how the agent should call it.

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 heavyweight, long-running, job-capable tool this covers the operational facts an agent needs: cost, progress mechanics, async path and its polling/cancel siblings, and provider resolution defaults. An output schema is declared, so return-value documentation is correctly omitted from the description.

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 100% schema coverage the schema already explains all three parameters, so this starts at baseline 3. The description adds genuine semantics the schema does not: what happens when provider is omitted (existing-model preference, then first live local provider, hosted only under an env flag) and the deduplication behavior of repeated background calls.

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?

"HEAVY: Download a model onto ONE provider" gives a specific verb and resource plus an explicit scoping constraint (single provider), and the surrounding text carves it apart from pull_status and pull_cancel by role (this one starts the download; those poll and stop it). An agent can tell immediately that this is the initiating operation rather than a status or management call.

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 gives a concrete decision rule for the background mode ("use this when the client has no progress display or a short tool timeout") and names the follow-up tools to poll and cancel, which is real when-to-use guidance. It does not address when to prefer ensure_model over an explicit pull, so one obvious sibling comparison is left 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description doesn't need to restate that. It instead adds genuinely non-obvious behavior: finished jobs are retained for only an hour and all jobs are forgotten on restart, which tells the agent that a missing jobId result is not necessarily an error. It could go further on cost or size of the full listing, but the retention caveats are the important ones.

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 clauses: the primary purpose and return fields first, then the no-jobId fallback and retention caveat in a parenthetical. Nothing is repeated from the schema or annotations, and no sentence is wasted.

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 read tool with an output schema, the description covers the state model, the fallback listing mode, and the retention/restart limits — everything needed to interpret results correctly. The only small omission is whether a running job survives a server restart in any form, but the 'forgotten on restart' note largely implies the answer.

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 real meaning beyond the schema: without jobId the call switches from a single-job lookup to a full job listing. That optionality behavior is not evident from a bare optional string field, so it earns above baseline.

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 the specific resource (background pulls initiated by pull_model with background: true) and enumerates exactly what is returned: state (running, done, failed, cancelled), progress, and result or error. This clearly separates it from pull_model (which starts jobs) and pull_cancel (which cancels 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?

It establishes the trigger context — use this after starting a background pull — and explains the two calling modes: pass jobId for one job, omit it to list all remembered jobs. There is no explicit statement about when to prefer polling this versus other status surfaces, and pull_cancel is never mentioned, but the usage context is otherwise unambiguous.

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 non-idempotent behavior, but the description adds useful operational detail about permanence and the confirmation flow. However, the claim that provider is REQUIRED (no fan-out) conflicts with the schema property text saying provider may be omitted to let the server choose, which weakens the behavioral guidance.

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 DESTRUCTIVE and is very compact. Every clause contributes either safety, required-parameter, or confirmation behavior, with no wasted text.

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 annotations covering safety and an output schema covering return values, the description supplies the key missing context: permanence and the confirmation/elicitation fallback. It would be more complete if it resolved the provider-optional conflict and explicitly contrasted remove_model with unload_model.

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 defines all three parameters. The description adds the no-fan-out requirement and clarifies confirmation behavior, but its provider-required claim conflicts with the provider property description that says omitting provider lets the server choose, making the added semantic value only partly reliable.

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 destructive verb and resource: permanently delete a model from one provider. It also scopes the operation to a single provider and no fan-out, which helps distinguish it from broader or memory-only sibling operations such as unload_model.

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 gives clear usage context: this is destructive, provider is required, and confirmation is handled through elicitation or the confirm:true fallback. It does not explicitly name unload_model as the non-destructive alternative, so the when-not guidance is implied rather than stated.

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 annotations already cover safety and idempotency, but the description adds useful behavioral context: the catalog is built-in, local, offline, and instant. It does not detail result limits or ranking behavior, but that is a minor gap given the rich annotations and output schema.

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 three tightly written sentences with no filler. The core purpose and the sibling alternative are both 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 read-only search tool with full schema coverage, rich annotations, and an output schema, the description provides everything needed to select and invoke it correctly. The offline/curated scope and the search_models alternative are 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 100%, so the query parameter is already well documented. The description reinforces that matching applies to model name, family, and tasks, but adds little beyond the schema itself.

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: searching the built-in curated catalog of well-known local models. It also distinguishes the tool from the sibling search_models by contrasting offline curated results with live Hugging Face results.

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 explicitly names the alternative search_models and the condition for choosing it: live results with per-quant fit. This gives the agent a clear routing rule between the two search tools.

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 readOnly/openWorld/idempotent, so the safety bar is low; the description still adds real behavior: live network search of GGUF repos, per-quant size returns, best-quant-for-this-hardware annotation, and pullable references in Ollama form. It does not mention latency, rate limits, or failure behavior for the remote source.

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?

Three tight sentences: purpose first, then source semantics, then the negative constraint. Every sentence carries information an agent needs, and the exclusion is placed last so it doesn't bury the main action.

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?

An output schema exists, yet the description still sketches the return shape (quant sizes, best-fit quant, pullable reference), which is more than required. With annotations and full schema coverage present, nothing critical is missing for correct invocation.

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 baseline is 3; the description goes beyond it by explaining that results carry fit annotations, which gives meaning to the otherwise thin fitsOnly and contextLength parameters, and by characterizing each source value. It doesn't clarify limit defaults or query matching semantics beyond the 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 ("Find models to download") plus the value-add of hardware-fit annotation, and defines each source mode concretely. It does not name competing siblings such as search_available or suggest_model, so an agent still has to infer which search tool to pick.

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?

Explains the 'huggingface' vs 'catalog' choice with the consequence of each, and explicitly rules out a third source ("The Ollama library has no public search API, so it is not a source"), which prevents a wasted call. No guidance on when to prefer this over suggest_model or search_available.

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 this is a safe, idempotent, closed-world read, so the safety profile needs no restating. The description adds real behavioral value beyond that: the exact ranking order (full GPU → partial offload → CPU), the within-tier tie-break, and that installed models are flagged on a live provider.

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?

Three dense sentences, front-loaded with purpose then ranking rules then output traits. No filler and every clause carries information an agent needs to interpret results.

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 an output schema present, return values need no explanation, and the description still covers the semantics of the ranking, the tie-break, and the installed-model flag. Nothing an agent needs in order to call and interpret this 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 coverage is 100%, so the four parameters are already documented and 3 would be the baseline. The description earns one more point by explaining how preferSpeed actually interacts with tier ordering ('largest comes first unless preferSpeed is true'), which the schema's one-liner does not make explicit.

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 ('Recommend catalog models for a task') plus the key differentiator: ranked for THIS machine. An agent can separate this from list_models, list_available, or fit_check without opening any 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?

Clear context for when to call it (you have a task and want a ranked recommendation), and the tiering rules imply it is the right tool when hardware fit matters. It never names an alternative such as fit_check or list_models, nor states exclusions, so it stops 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new context beyond that: the per-platform discovery mechanisms (nvidia-smi, sysfs, Windows registry, Apple Silicon unified memory) and the guarantee that each GPU reports its data source, which tells the agent how much to trust the VRAM figures.

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 dense sentences, front-loaded with the returned fields before the platform-detection detail. Every clause carries information, though the parenthetical enumeration of OS-specific mechanisms is heavy for a definition whose output schema already documents the 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?

With an output schema present, the description need not describe return structure, and it still previews the key fields and the data-source provenance. For a zero-parameter, read-only inventory tool, nothing an agent needs in order to call 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless call with no scoping options.

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 ("Report") and resource ("local hardware") and enumerates exactly what is returned: platform, total/available RAM, CPU count, GPUs with total/free VRAM. This is unmistakably distinct from the sibling set, which is entirely model-management and inference tooling; no sibling could be confused with a hardware inventory read.

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 tool to consult for host capacity, but the description never says when to reach for it versus siblings like health_check, fit_check, or list_providers. No exclusions or prerequisites are stated.

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 cover mutation safety: readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds useful context beyond annotations by clarifying that unloading frees memory, applies to exactly ONE provider, and defaults to the live local provider that has the model loaded.

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 sentences, both front-loaded and substantive. The memory-freeing purpose comes first, followed by the provider default, with no wasted wording.

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?

The tool has rich annotations, full schema coverage, and an output schema, so the description need not explain return values. It is complete enough to call correctly, though it could note what happens if the model is not loaded or clarify that the model remains on disk.

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 parameter meaning is already well documented. The description still adds value by explaining the provider default more concretely: without provider, it uses the live local provider that has the model loaded, complementing the schema's server-choice wording.

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: unloading a model from memory to free VRAM/RAM, scoped to one provider. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like remove_model or load_model.

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 'to free VRAM/RAM' implies when to use the tool, and the provider default is explained. However, there is no explicit guidance on when to choose this over remove_model, list_loaded, or load_model, nor any stated exclusions.

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