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

With no annotations, the description bears the full burden. It discloses key traits: one-shot (no conversation state), local execution, no cloud usage, and raw text return. It does not mention error conditions, model availability, or potential latency, but these are secondary for a simple tool. The provided information is accurate and materially helps an agent predict behavior.

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 paragraphs. The purpose sentence is front-loaded, followed by usage context and a cost note. Every sentence serves a purpose; no fluff or repetition. Ideal length for a simple 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?

The description covers purpose, usage, cost, and output format clearly. It omits potential failure modes (e.g., model not installed) and doesn't mention that the model must be pre-pulled, but given the tool's simplicity and the presence of an output schema, these are optional. An agent can safely invoke it with just the required prompt.

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% — all three parameters (prompt, model, system) have descriptions. The tool description adds little beyond the schema: it frames the action as 'one-shot' and mentions 'raw text completion,' which relates to output rather than parameter semantics. This meets the baseline for high 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 opens with a clear verb-resource pair: 'Send a one-shot prompt to a local Ollama model and return its text response.' It distinguishes from siblings by emphasizing 'one-shot' (vs chat_local) and 'raw text completion' (vs specialized extract/summarize tools). The example use cases reinforce its generic scope.

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 states when to use: 'Use for any handoff where the cloud model's full reasoning isn't needed' and lists concrete tasks (drafts, boilerplate, simple extractions, formatting, quick lookups). It also provides a cost rationale ('Runs on the user's own GPU and consumes no cloud-LLM usage'), which guides selection. While it doesn't name sibling alternatives, the categories imply exclusions (e.g., complex reasoning for cloud models, specialized extraction for extract_local).

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool runs locally at no cloud cost and returns the next assistant message as text, which are useful behavioral traits. It does not explicitly mention potential failure modes (e.g., model unavailability, timeouts) or confirm it is read-only, but these are less critical for a chat tool.

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 concise and well-structured. The first paragraph states the purpose and usage guidance, and the second adds contextual details. Every sentence contributes value without redundancy or fluff.

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 that an output schema exists, the description does not need to explain the return format in depth. It covers the tool's purpose, when to use it versus an alternative, and the basic return type, making it complete for an agent to correctly invoke the 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?

The input schema already documents both parameters (model and messages) with detailed descriptions, achieving 100% coverage. The tool description does not add additional parameter-level semantics, but the schema is sufficient, so the baseline score of 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 states the tool's specific function: holding a multi-turn chat against a local Ollama model. It clearly distinguishes from the sibling `ask_local` by the multi-turn requirement, so an agent can immediately understand its purpose and differentiate it from related tools.

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 explicitly says 'Use instead of `ask_local` when the handoff needs more than one turn of context' and provides concrete examples ('a running conversation or a system + user + assistant history'), leaving no ambiguity about when to select this tool over its alternative.

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 no annotations, the description carries the full burden of behavioral disclosure. It discloses local execution ('Runs locally at no cloud cost'), the output format ('Returns review notes as text'), and the shallow/first-pass scope. It does not mention latency, determinism, or resource constraints, but the most important behavioral traits are present.

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 compact and front-loaded: the first sentence states the operation, the second covers use context, and the third covers behavior and output. A slight redundancy exists between 'quick first-pass' and 'cheap pre-filter,' but it earns its place by adding the cost angle. No wasted or filler words.

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 tool with a fully documented schema and an output schema present, the description provides the needed context: purpose, usage scenario, execution environment, and return type. It would benefit from an explicit 'when not to use' note, but nothing essential is missing for a correct call.

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 both `diff_or_code` and the optional `model`. The description adds no new parameter-level meaning beyond reinforcing that the input is a diff or code block. This matches the baseline for fully covered schemas.

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 identifies a specific action ('Run a quick first-pass code review') and a specific resource ('local coder model'), and distinguishes this tool from sibling local tools by naming what it catches: 'obvious bugs, style issues, and risky patterns.' No other sibling tool description suggests this exact code-review role.

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 explicitly frames the tool as a 'cheap pre-filter before asking the cloud model for a deeper review,' giving an unambiguous when-to-use context and an implied alternative. It does not name sibling tools directly or state explicit exclusions, but the pre-filter/deeper-review distinction is concrete enough to route an agent correctly.

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 no annotations, the description carries the behavioral burden. It discloses local execution, no cloud cost, and the exact return format (single commit message as text), which are important operational traits. It could be more explicit about model availability or failure modes, but for a drafting tool this is adequate.

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 two paragraphs, front-loaded with the main purpose and efficiently covering usage and output. There is minor redundancy between 'cheap and fast' and 'no cloud cost', but overall it is appropriately sized and well-structured.

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 tool with an existing output schema, the description covers the core purpose, usage context, and return type. It does not explicitly state when to prefer a cloud alternative, but the implicit guidance is sufficient 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?

The schema already fully documents both parameters (diff and model) with 100% coverage. The description adds no parameter-specific detail beyond what the schema provides, so the baseline score of 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 the specific action—drafting a conventional-style commit message from a diff—while explicitly distinguishing this local-model tool from the cloud-model alternative and from sibling tools like ask_local or summarize_local. The verb, resource, and style constraints are all present.

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 provides explicit guidance on when to use the tool ('routine commits where the cloud model's analysis isn't needed') and emphasizes the cost/latency benefits. However, it does not name the alternative tool directly or list explicit when-not-to-use cases beyond that implied exclusion, 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool runs locally, incurs no cloud cost, and returns extracted items as text shaped by `what_to_extract`. This gives the agent enough behavioral context to set expectations, though it does not mention latency, size limits, or failure behavior.

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 concise and front-loaded with the core purpose. The only weakness is minor redundancy: "without spending cloud-model tokens" is repeated by the later sentence "Runs locally at no cloud cost." Overall it is still tight and readable.

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 three-parameter tool with a full schema and output schema, the description is largely complete: it explains what the tool does, the kind of extraction to request, and the return form. It could improve by explicitly noting how it differs from sibling local tools, but nothing essential for correct invocation 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%, so the schema already documents all three parameters. The description adds some context by noting that `what_to_extract` shapes the output and providing example values, but this is reinforcing rather than substantially expanding on the schema. 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 opens with a specific verb and resource: "Extract specific information from a text block." It then gives concrete target types (function names, URLs, error codes, TODO comments, dependency names), making the tool's purpose unmistakable and clearly distinct from the sibling chat/ask/summarize tools.

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 explicitly says when to use it: to pull structured facts out of unstructured text, and positions it as a cost-saving local alternative to cloud-model extraction. It does not name explicit alternatives or when-not-to-use cases, so it falls short of a 5, but the guidance is clear and actionable.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool lists locally installed models and returns model-name strings, but it doesn't explicitly state whether it is read-only or mention potential failure modes (e.g., no models installed). For a simple list operation, this is adequate but not exhaustive.

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 concise sentences with no redundancy. The primary action is front-loaded, followed by a clear usage hint and return type. Every sentence 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?

Given there are no parameters and the output schema is present (though not shown in the prompt), the description provides the essential information: what it lists, why to use it, and what it returns. Nothing an agent needs 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 has zero parameters, so the schema is empty and description coverage is 100% by definition. Per the rubric, 0 params earns a baseline of 4. The description adds nothing about parameters because none exist, which 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 states a specific verb ('List') and resource ('Ollama models installed locally'), and clarifies its role as a discovery tool distinct from the sibling task tools (ask_local, chat_local, etc.). It also specifies the return type, making the purpose unambiguous.

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 explicitly says 'Use to discover valid values for the `model` parameter before pinning a specific model,' which provides clear context for when to call it. It doesn't explicitly state when not to use it, but the intent is evident given the sibling tools are the consumers of the model names.

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 no annotations provided, the description carries the behavioral burden. It discloses that the tool returns a JSON object and names its payload fields, and 'Report' implies a non-mutating operation. It does not discuss error behavior or access constraints, but the behavior of a config-reporting tool is sufficiently clear.

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?

Four concise sentences with no filler. The core purpose is front-loaded, followed by return details and actionable use cases; every sentence 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?

Given a zero-parameter tool with no output schema, the description is complete: it states what is returned, enumerates the key fields, and gives concrete usage scenarios. An agent can decide to call it and interpret the result without further information.

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 has zero parameters, so the baseline is 4. The description compensates for the absence of parameter documentation by explaining what the returned configuration report contains, which is the only semantic information an agent needs.

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, 'Report', with a concrete resource, 'the server's effective configuration', and enumerates the exact fields returned (default model, Ollama base URL, context size, request timeout). This clearly distinguishes it from siblings like list_models, which lists models rather than reporting overall server configuration.

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 explicitly states when to use it: to confirm the default model the tools will use or to debug connectivity. It does not mention when not to use it or name alternatives, but for a zero-parameter diagnostic tool the guidance is specific and useful.

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 no annotations provided, the description carries the full behavioral disclosure burden. It states that the tool 'Runs on the user's GPU at no cloud cost' and 'Returns a concise prose summary,' which are useful behavioral details. It does not mention potential latency, failures, or size limits beyond the schema, but the disclosure provided is solid.

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 concise and well-structured: a clear opening definition, a practical use-case sentence, a cost/location statement, and a return-value sentence. Every sentence contributes useful information without redundancy or 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?

Given that an output schema exists and all parameters are documented, the description covers the essential usage context well. It explains when to call the tool, what it returns, and why local execution is beneficial. It could be more complete by explicitly distinguishing from sibling tools like extract_local or ask_local, but 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds a small note about passing `focus` to bias the summary, but this largely repeats what the schema's focus parameter already says. A baseline 3 is appropriate because the schema does the heavy lifting.

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 identifies the tool as 'summarize a block of text using the local model', which is a specific verb and resource. It communicates the core purpose well, but it does not explicitly differentiate from sibling tools like extract_local or ask_local, so it falls short of full sibling distinction.

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 provides clear context for when to use the tool: 'Use to offload long files, logs, transcripts, or docs the cloud model does not need to fully ingest.' It also tells the agent to call this 'instead of reading a large blob into the cloud context,' giving practical usage guidance. However, it does not name specific alternatives or state when not to use it.

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