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

The description reveals meaningful behavioral traits beyond the annotations: it performs a complexity assessment, returns one of three artifact types, and may include intake questions to ask first. It also warns about cost of unnecessary delegation. It does not disclose whether the tool has side effects or executes the plan itself, but the annotations offer no contradiction.

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 deliver the core workflow, when to invoke, and a cost-awareness guardrail. Every sentence earns its place, and the most important behavioral signal (what the tool returns) 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?

Given the lack of an output schema and sparse annotations, the description does a good job explaining the three possible return shapes and the 'ask intake questions first' behavior. It is less complete on how to interpret or execute the returned plan, and it leaves the numeric limit parameters unexplained, but the core calling workflow 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?

The description adds no parameter-specific meaning; all parameter semantics must come from the schema, which covers only 57% of parameters. Notably, memory_limit, knowledge_limit, and scope have little or no explanation in the schema, and the description does not compensate by explaining how limits or scope affect the delegation assessment.

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's purpose with specific verbs: assess a task's complexity, then return a delegation shape (handle directly, single specialist, or multi-stage pipeline). It clearly distinguishes this from the sibling tools by framing it as the pre-task router/briefer, though it never names a sibling explicitly.

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 call the tool ('before starting any non-trivial task') and when not to delegate ('Respect a handle_directly verdict — spawning a subagent for small work wastes tokens and time'). This gives the agent both an inclusion and an exclusion criterion in one short passage.

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 adds 'permanently' to the delete operation, conveying irreversibility beyond the destructiveHint annotation. It also clarifies the scope ('one memory by id') and that the deletion targets a single stored preference. No contradictions with the annotations were found.

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, each earning its place: one states the action and target, the other states when to invoke the tool. No filler or redundant information is present, and the content is front-loaded with the core operation.

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 destructive tool with full schema coverage and relevant annotations, the description is complete. It covers what the tool does, when to use it, and the permanence of the action. No output schema exists, and none is needed for such a simple operation.

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 the schema already explains that id is the 'Memory id, as shown by recall.' The description only says 'by id,' adding no new meaning beyond the structured schema. Baseline 3 is appropriate because 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: 'Permanently delete one memory by id.' It clearly distinguishes the tool from siblings like remember, recall, and search_knowledge by defining its exact operation. The title and description are largely consistent, with 'preference' as the stored memory item.

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 an explicit trigger: 'Use when the user says a preference is wrong or obsolete.' It does not explicitly name alternative tools or state when not to use this tool, but the given condition is specific and actionable. The context signals and sibling list allow an agent to infer that remember or recall are the alternatives, but they are not named.

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 readOnlyHint=true, which covers the safety profile. The description adds some useful context about what 'full content' includes for different kinds, but it does not mention error behavior, missing slugs, or return format. This is acceptable given the annotation coverage but not especially rich.

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

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

A single, front-loaded sentence states the action and scope, with an em-dash list of examples. There is no wasted wording, and the most important information appears first.

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 two-parameter tool with readOnly annotations, the description provides enough to call it correctly. The absence of an output schema is partially mitigated by the description's examples of what 'full content' means, though a note about nonexistent entries or return format would make it fully complete.

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 documents both parameters and the enum, but only 'name' has a description. The description compensates for the low schema description coverage by mapping kind values to concrete content examples (agent prompt, runbook TOC, connector guardrails), adding semantic depth beyond the bare enum names.

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 verb and resource: 'Fetch the full content of one catalog entry.' It also enumerates example content types (prompt, skill, runbook with TOC, connector guardrails), which disambiguishes it from siblings like brief, list_catalog, and search_knowledge.

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 when to use this tool: whenever the full content of a specific catalog entry is needed. It does not explicitly name alternatives or exclusions, but the 'full content' contrast with sibling tools like 'brief' and 'list_catalog' gives clear contextual guidance.

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 mark readOnlyHint false, meaning the tool should not be treated as side-effect-free, but the description presents it purely as a fetch and never mentions any state changes, counters, or pipeline advancement. This contradicts the annotation, so the score is 1 per rubric.

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 call pattern. No filler or repetition of schema fields.

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 6-parameter tool with no output schema and a false read-only hint, the description omits return-value details, ordering constraints beyond 'previous finished', and any warning about side effects or limits. It's enough for a happy-path call but incomplete for safe and correct use.

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 only 3 of 6 properties, so the description must compensate. It adds meaningful semantics for `context` (the previous stage's output) and implies `role` selects the stage, but it leaves `scope`, `memory_limit`, and `knowledge_limit` unexplained. Net moderate value.

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 specific verb ('Fetch'), a specific resource ('system prompt for one stage of a plan returned by brief'), and ties it to the sibling 'brief' by referencing the plan it operates on. This clearly distinguishes it from list/get_entry/search 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?

The description gives concrete call timing: call when the previous stage is finished, and instructs to pass that stage's output as context. It doesn't enumerate alternatives or 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying that results are tagged base/custom/base+custom. No contradiction with 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?

A single concise sentence that front-loads the verb and resource, then enumerates scope and tagging. Every phrase adds information; there is no 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 read-only list tool with two optional parameters and no output schema, the description plus schema is complete: it states what is returned (catalog entries with tags), what filters exist (kind, topic), and the summary behavior when kind is omitted. Safety is covered by annotations.

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% ('Limit to one kind. Omit for a summary of everything.', 'Limit to entries in one topic.'), so the schema carries the parameter semantics. The description's enumeration of kinds overlaps with the schema enum but adds no new meaning beyond it.

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 ('Show') and a specific resource ('catalog entries'), then enumerates the seven kinds ('agents, skills, knowledge, runbooks, topics, tools, connectors') and the tagging dimension ('base, custom, or base+custom'). This clearly distinguishes list_catalog from siblings like get_entry or search_knowledge.

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 and title provide clear context: use this to list what the organisation has configured. The schema adds parameter-level guidance ('Limit to one kind. Omit for a summary of everything.'). It does not explicitly name alternatives or when-not-to-use conditions, so it misses the top bar.

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=true, so no credit is needed for read-only safety. The description adds useful behavioral detail that results are 'ranked by relevance and how binding they are', going beyond the schema. However, the concept of 'binding' is vague and not elaborated, and behavior like pagination or default limits is not disclosed.

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 concise sentence with no filler. It front-loads the key action and resource, then adds a distinguishing detail on ranking. Every word earns its place; no redundant or vague phrasing beyond the inherent 'binding' term.

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 four parameters and no output schema, the description needs to explain what results look like, what 'scope' and 'agent' mean, and how 'binding' affects ranking. None of that is present. The tool has no output schema, so return-value details are absent from both description and structured data, leaving an agent under-informed for 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 only 25% (only 'query' is described). The tool description adds no parameter insight: it does not explain 'scope', 'limit', or 'agent'. Since coverage is low, the description should compensate but fails to clarify parameter meaning beyond what the schema already provides.

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 ('Search') and a clear resource ('remembered preferences'), which distinguishes it from siblings like search_knowledge (knowledge) and list_catalog (catalog listing). However, it does not explicitly name the sibling for contrast, so differentiation is implicit rather than explicit.

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 this tool is for searching preferences, and the phrase 'remembered preferences' gives context for when to use it. But there is no explicit guidance on when to choose recall over search_knowledge or list_catalog, and no exclusions or alternatives are mentioned.

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 discloses the key side effect: it 'adjusts the term-to-agent weights it consults, so routing improves with use.' This goes beyond the annotations, which only mark the tool as not read-only. It tells the agent that calling this mutates internal routing state, which is valuable behavioral context.

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 short sentences, each earning its place: what the tool does, what effect it has, and when to call it. It is front-loaded with the primary action and has zero 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 feedback tool with no output schema, the description covers the core purpose, the consequential side effect, and the triggering condition. All parameters are already described in the schema, and the annotations cover the safety profile. The only minor gap is that it does not describe what response or acknowledgment the agent can expect after calling.

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 80%, so the schema already documents most parameters (task, agent, outcome, correct_agent). The description adds high-level context about reweighting terms but does not elaborate on individual parameters or their expected values. With coverage that high, a 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: 'Tell the router whether the agent it chose was right.' This clearly identifies the tool's function and distinguishes it from siblings like remember, forget, and status, which handle knowledge storage or state queries. The purpose is immediately obvious and not a tautology.

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 states when to call: 'Call after the user reacts to a subagent's work.' This gives a clear timing cue relative to user activity. It does not spell out when not to call or name alternatives, but the timing and purpose make the intended context 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 indicate this is a write operation and not read-only. The description adds valuable behavioral context beyond annotations: restating reinforces rather than duplicating, and contradictory corrections/constraints retire softer memories. This discloses conflict-resolution behavior that the schema and annotations do not.

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 with no filler; each sentence earns its place: primary action/purpose, dedup/retirement behavior, and usage boundary. There is no redundant repetition of schema or annotation 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 six-parameter write tool with no output schema, the description plus well-documented schema provides enough context to invoke correctly. It covers purpose, durability semantics, conflict handling, and when not to use it. A short example could push it to a 5, but nothing essential 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 high at 83%, so the baseline is 3. The description slightly reinforces parameter concepts ('preference', 'constraint', 'correction') but adds no new meaning beyond the schema's own parameter documentation.

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 uses a specific verb ('Record') and names the resource ('a preference, rule, or correction') with an explicit purpose ('so future briefings honour it'). It clearly distinguishes the tool from sibling read/delete tools like recall and forget by emphasizing durable preference storage.

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: 'Use for standing rules, never for one-off task instructions.' It provides a clear exclusion, though it does not explicitly name alternative tools for the excluded cases; the sibling set makes those alternatives inferable.

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 readOnlyHint/openWorldHint annotations, it discloses two key behavioral rules: cite the returned chunk id when using a passage, and state plainly when the answer is absent rather than filling the gap. These materially shape agent 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?

Three concise sentences with the core action front-loaded. Every sentence carries distinct operational value: purpose, usage context, and honesty/citation requirements.

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 search tool, it covers purpose, usage context, citation behavior, and missing-answer handling. It leaves some return-shape detail implied, but annotations and schema cover safety and parameter constraints.

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 only 33%, and the description adds no parameter-level detail for query or limit. It implies a direct query but does not compensate for the undocumented parameters.

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 action — retrieve passages — and a clear resource — the organisation's own documentation. Framing it as a direct factual lookup distinguishes it from memory-oriented 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 'Use for a direct factual lookup,' giving clear invocation context. It does not name alternatives or exclusions, so it falls just short of full when-not guidance.

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 readOnlyHint annotation already establishes that this is a safe read operation, and the description does not contradict it. The description adds useful transparency by stating exactly which state areas are covered: catalog counts by kind and layer, knowledge index size, stored preferences, and parse failures. This helps set expectations beyond the bare annotation.

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, front-loaded sentence that lists exactly what will be reported. Every element earns its place and there is no filler, making it easy for an agent to parse quickly.

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 there is no output schema and no parameters, the description does the necessary work by enumerating the main categories of returned information. It is sufficiently complete for a read-only status/overview tool, though additional detail about the exact shape of counts or failure entries could make it even more precise.

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 parameter semantics are not a burden for the description. The baseline of 4 applies because there is no parameter schema detail missing and no parameter-level explanation needed.

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 conveys that this tool reports the current state of what is loaded, including catalog counts, knowledge index size, stored preferences, and parse failures. It is specific about the resource and content, and the title reinforces that it is an overview. It does not use an explicit verb like 'returns' or 'shows', but the intent is unmistakable and distinguishable from sibling list/search 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 implies when to use the tool: whenever an agent needs a high-level summary of loaded catalog and memory state. However, it gives no explicit when-to-use or when-not-to-use guidance, nor does it contrast itself with siblings such as list_catalog or search_knowledge, so the agent must infer the best choice.

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