gemini-relay

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

No annotations are provided, so the description carries full burden. It discloses several beyond-schema behaviors: file inclusion via @path, conversation continuation, response-ID reporting caveats in plain-text vs jsonSchema/changeMode, agy backend's sandbox limitations, and skipPermissions behavior. Some details live in the schema, but the description adds A plain-text reply vs parsed-body distinction and the basic file-inclusion mechanism.

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 sentences: core action, feature highlights, and sibling routing. Front-loaded with what the tool does, no filler, and the routing closes the description. Every sentence earns its place; it stays compact despite handling a complex 15-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Richly covers a complex general-purpose tool: what it returns, how to reference files, how to continue threads, and when to use siblings. There is no output schema to document return values, but the description's core promise ('get the answer back') plus the conversationId/plain-text caveat suffice. No essential calling context 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 documents every parameter, making the baseline 3. The description adds meaning above that by encoding the @path file-inclusion convention directly ('Reference project files with @path to send their contents along') and by grouping the conversational state (conversationId to continue a thread). It also gives a quick semantic to mode via 'accept-edits' and 'plan' examples in the schema; the prose adds the general mental model, which lifts it slightly 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?

Description leads with a clear verb+resource ('Send one prompt to Google Gemini... and get the answer back'), and enumerates concrete uses: questions, code review, analysis, edits, structured JSON. It also distinguishes itself from gemini-plan and gemini-brainstorm by name, which is enough to tell it apart from siblings.

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

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

Explicitly says when to use this tool vs alternatives: 'For a phased implementation blueprint use gemini-plan; for idea generation use gemini-brainstorm; for everything else use this.' That is direct when/when-not routing. Thread-continuation guidance (conversationId) is also included.

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 must carry the behavioral disclosure burden. It does this well by clarifying the tool only generates ideas, produces a ranked list, and optionally includes feasibility analysis. It could go further by describing the return structure or any model-related caveats, but the key behavioral boundary—ideation only, not execution—is explicit.

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 sentences, front-loaded with the core function, and contains no filler. The second sentence earns its place by preventing misuse through clear sibling routing.

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 9-parameter tool with no output schema, the schema covers parameters thoroughly, and the description supplies the ideation boundary and sibling alternatives. It could be slightly more complete by mentioning what the output looks like beyond 'ranked list,' but the essential context for selecting and invoking the tool is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already has meaningful descriptions and enums. The tool description adds high-level context about ranked output and feasibility but does not add per-parameter semantics beyond what the schema already provides. The baseline 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 opens with a specific verb and resource: 'Generate a ranked list of ideas for an open-ended challenge.' It names concrete creativity methods and mentions optional feasibility analysis, making the tool's function unmistakable. It also differentiates itself from siblings by explicitly saying this is ideation only, not for answers or implementation.

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 gives explicit routing guidance: 'Ideation only: use gemini-ask for answers and gemini-plan for implementation blueprints.' This tells an agent exactly when this tool is appropriate and when to choose a sibling, leaving no ambiguity.

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 burden of behavioral disclosure. It explains the side effect precisely: each cancelled call returns an error to its caller, and nothing else is affected. This is strong transparency for a cancel operation, though it doesn't mention reversibility or authorization requirements.

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 tightly written sentences. The first states the action and scope, the second clarifies side effects and boundaries. Every phrase earns its place with no filler or 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?

For a no-parameter cancellation tool with no output schema, the description is complete: it names the target, the scope, the effect on callers, and the exclusion of everything else. An agent has enough information to invoke it correctly and predict outcomes.

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 and an empty schema, so there is no parameter meaning to convey. Per the baseline for 0-param tools, 4 is appropriate; the description correctly focuses on behavior rather than inventing parameter details.

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 ('Stop') and resource ('every Gemini CLI run the relay has in flight'), and explicitly names affected sibling tools (gemini-ask, gemini-plan, gemini-brainstorm, gemini-image). This clearly distinguishes it from the read/execute tools in the sibling list.

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 gives clear context for when to use the tool: when there are slow in-flight Gemini CLI runs that need to be aborted 'right now.' It also scopes what is and isn't touched ('Nothing else is touched'), effectively ruling out unintended effects. It doesn't explicitly name alternatives, but for a cancellation operation the context is sufficient.

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 burden. It discloses that the tool reads 'agy's local store' and makes no model turn, signaling a read-only, low-cost operation. This is meaningful behavioral context beyond a generic list action.

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, each adding distinct value: what is listed, how to use the result, and the operational side effect. The important action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description covers the returned fields, the continuation workflow, and the read-only/no-model-turn behavior. Nothing essential 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?

The only parameter, limit, is fully documented in the input schema with default, max, and ordering. The description does not need to restate it, and at 100% schema coverage the baseline is 3.

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 leads with a specific verb and resource ('List recent Gemini conversations the relay can resume') and lists the returned fields. It also names gemini-ask as the downstream consumer, which helps an agent distinguish listing from asking.

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 tells the agent to pass a returned id to gemini-ask as conversationId when continuing a thread, giving a clear use case. It does not state when to avoid this tool in favor of gemini-ask for a new conversation, but the context is clear enough.

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 disclosure burden. It lists what is checked (installation, backend, version, readiness) but does not explicitly state whether the tool is read-only, whether it modifies anything, what output format to expect, or whether it requires any prerequisites. 'Diagnose and verify' strongly implies non-mutating, but this is left implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler. The action verb is front-loaded, and every phrase adds a distinct diagnostic aspect: installation, backend, version, and readiness.

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 zero-parameter diagnostic tool with no output schema and no annotations, the description covers the key dimensions an agent needs to understand its purpose. It does not state what the verification output looks like or how to interpret results, but the low complexity makes that a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter documentation burden. Schema coverage is trivially complete, and the description does not need to explain parameters that do not exist.

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 specific verbs ('diagnose', 'verify') and names exact resources: Gemini CLI / Antigravity CLI (agy) installation, active backend, CLI version, and system readiness. This clearly distinguishes it from sibling tools like ask-gemini or gemini-image, which are content-generation 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 diagnostic scope clearly implies use when checking environment health or CLI readiness, which is distinct from the content-generation siblings. However, it does not explicitly state when not to use it or name alternative tools for similar checks.

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 disclosure burden. It discloses two non-obvious behaviors: no model turn is consumed and cached data expires after 10 minutes. For a simple retrieval tool this is adequate, though failure behavior on cache expiry is not stated.

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 with no filler; the verb and target are front-loaded and the behavioral caveats are packaged cleanly.

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 cached retrieval tool, the essentials are present: what to pass, where the values come from, and that the cache is short-lived. Minor omissions are the exact return shape and expiry/error behavior, but an agent has enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters 100%, so baseline is 3. The description adds provenance guidance—the cacheKey and chunkIndex come from the initial gemini-ask reply—which is more useful than either schema description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise action: retrieve one chunk of a chunked changeMode reply, scoped to data produced by gemini-ask, identified by cacheKey and chunkIndex. This clearly distinguishes it from siblings like gemini-ask or gemini-cancel.

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

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

The description implies the trigger: use after gemini-ask returns a chunked changeMode reply and supplies cacheKey/chunkIndex. It identifies this as a retrieval step rather than a model call and gives a 10-minute validity window, but it does not explicitly name alternatives or exclusions.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It accurately states that the tool prints the CLI's --help text and mentions the two possible CLIs, 'agy or gemini', which is useful transparency. It does not discuss output size or failure modes, but for a zero-argument read-only help tool this is a minor omission.

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 a single sentence with no filler. It front-loads the action ('Print'), names the resource, and gives the purpose, all in one efficient, well-structured statement.

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 tool with no parameters and no output schema, the description is complete: it explains what is printed, which CLI's help text is shown, and why the agent would call it. Nothing essential 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?

With zero parameters, the baseline is 4. The description adds meaning by clarifying that the tool needs no user input and instead introspects the 'active backend CLI', which helps the agent understand that invocation is automatic and requires no configuration.

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: 'Print the active backend CLI's own --help text (agy or gemini)'. It also immediately explains the purpose, 'to see which flags the installed version supports', making the tool's role clear and distinct from the gemini-* sibling commands.

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 clearly implies when to use the tool: whenever the agent needs to discover which flags the installed backend CLI supports. It does not name an alternative or exclusion explicitly, but no sibling provides the same help/introspection function, so the usage context is reasonably clear.

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 does disclose a material side effect: optional export directly into the project, and it places the tool in the Antigravity CLI context. However, it does not mention overwrite behavior, what happens when outputPath is omitted, or generation failure modes, leaving some behavioral gaps.

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 with no filler. The first sentence states the core purpose, and the second compactly lists the key options. Information is front-loaded and every word 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 the 100% schema coverage and straightforward nature of image generation, the tool definition is largely complete: prompt, sizes, aspect ratios, and export path are all documented. The only notable gap is the lack of any statement about what the tool returns when outputPath is omitted, which matters more because there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's second sentence ('Supports aspect ratio and output size selection, plus optional export') merely summarizes the schema's parameters without adding new meaning; the schema itself already documents each parameter precisely.

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 phrase 'Generate images from text descriptions', naming the resource (image generation) and the input (text). It also names the context 'Antigravity CLI's image generation tool' and the supported options, clearly distinguishing it from the chat/planning sibling 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 intended use is clear from the first sentence: generate an image when you have a text description. The description also previews optional export, helping an agent infer workflow use. It does not explicitly name alternatives, but no sibling tool performs image generation, so the context is 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?

No annotations are provided, so the description carries the full burden. The verb 'Lists' signals a read-only operation, and 'active backend status' discloses that it queries live backend state. It does not mention rate limits or authentication, but for a zero-parameter discovery tool these are low-risk omissions.

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 a single efficient sentence that fronts the core action ('Lists available Gemini models') and then packs the important output dimensions into a compact list. Every phrase adds information without 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 no-parameter, no-output-schema tool, the description covers what the tool returns: models, defaults, reasoning capabilities, and backend status. It could add a bit more about output format or how status is represented, but nothing essential is missing for invoking it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is an empty object with 100% coverage, so there is nothing for the description to add about parameter meaning. The baseline of 4 for no-parameter tools 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 uses a specific verb ('Lists') and identifies a distinct resource ('available Gemini models'), then enumerates the exact content categories returned: default selections, reasoning capabilities, and active backend status. This clearly separates it from action-oriented siblings like ask-gemini, gemini-plan, and gemini-image.

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

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

The description makes the use context clear: an agent should call this when it needs to know which Gemini models are available, which are defaults, what reasoning capabilities exist, or whether the backend is active. It does not explicitly name alternatives or exclusions, but no sibling tool appears to cover model discovery, so the context is sufficient.

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 burden. It meaningfully discloses that the tool avoids the CLI and any model and only echoes the prompt from the relay, strongly implying a safe, side-effect-free operation. It does not describe return format or error cases, but for a simple ping 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 short sentences with no filler. The primary purpose is front-loaded, and the alternative routing is stated in the second sentence without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity, optional-parameter ping tool, the description fully enables correct selection and invocation. The absence of an output schema is not a significant gap because the echo behavior makes the return value self-evident.

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 describes the single 'prompt' parameter as 'Message to echo', so the description adds little beyond confirming the echo behavior. This matches the baseline expectation for full 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 uses specific language ('liveness check', 'echoes the prompt back') and precisely identifies the resource/scope: the relay itself, not the CLI or any model. It clearly differentiates this tool from gemini-doctor and other sibling 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 states when to use this tool for a relay liveness check and explicitly directs agents to gemini-doctor for CLI checks. This gives clear selection guidance and distinguishes the tool from its closest 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: read-only nature, no file editing, restriction to a single task, and use of highest reasoning effort. It does not mention potential long-running behavior or response format, but the most important side-effect and scope constraints are clearly stated.

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 with zero waste. The core behavior and scope are front-loaded in the first sentence, and the exclusion/alternative is packed into the second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only planning tool with 6 parameters and no output schema, the description covers purpose, scope, exclusions, and a routing pointer. The main gap is the absence of behavior around response structure or asynchronous execution, but the schema handles parameters and the description gives sufficient context 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?

Input schema has 100% description coverage for all 6 parameters, so the baseline is 3. The description adds no parameter-specific detail beyond the schema; it only reinforces that the tool plans a task, which is already clear from the 'task' parameter. This is acceptable since the schema already documents each 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?

Description opens with a specific verb ('Produce') and identifies the deliverable: 'a read-only, phased implementation blueprint' with steps, dependencies, and risks. It clearly differentiates itself from gemini-ask by stating 'never answers general questions; use gemini-ask for those', so an agent can distinguish between the two without opening schemas.

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 this tool ('for one task' needing a blueprint) and when not to ('Never edits files and never answers general questions'), and names the alternative tool for general questions. This gives agents clear routing instructions with minimal inference.

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