Server Quality Checklist

Tool Scores

• call_toolC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits but only states the basic operation. It does not mention potential side effects of executing a tool, error handling, server requirements, or whether the call is read-only or mutating. The phrase 'Call' implies execution, but no safety or failure details are given.

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

  Conciseness5/5

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

  The description is a single sentence that conveys the essential action without any fluff. It is front-loaded and every word contributes to understanding the tool's purpose. This is an example of efficient, concise writing.

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

  Completeness2/5

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

  For a generic tool with no output schema, the description is too minimal. It does not explain the return value, how the target tool's response is packaged, or what 'qualified' means. Given the tool's complexity as a dynamic invoker, more context is needed to fully understand its behavior.

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

  Parameters3/5

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

  Schema coverage is 50%, with 'id' described but 'args' undocumented. The description adds the 'server.tool' format for the id, which helps, but does not explain the structure or purpose of 'args'. It partially compensates for the coverage gap but leaves significant ambiguity for a key parameter.

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

  Purpose4/5

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

  The description clearly states the action ('Call') and resource ('a qualified tool (server.tool) on a mounted MCP server'), which gives a precise idea of the tool's function. However, it does not explicitly distinguish this from sibling tools like load_tool or list_providers, though the name and mention of 'server.tool' imply it is for invocation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention alternatives, exclusions, or prerequisites beyond the schema. The implied usage is to call any qualified tool, but the lack of any context for selection makes it weak.

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

• memory_recallA
  3.6/5.0
  Behavior3/5

  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 the default search behavior and scope options, which is useful context. However, it does not explicitly state that the operation is read-only, nor does it describe result characteristics, potential limits, or side effects, leaving key behavioral aspects undisclosed.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with a clear purpose, and every element is informative. The scope options are listed compactly without prose repetition, making it an appropriately sized and structured description.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description should explain what the agent can expect as output and provide guidance on invocation. It fails to describe the return format, how results are scored/ordered, or what a 'custom bucket' means, and it leaves the limit parameter undocumented. This leaves significant gaps for reliable use.

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

  Parameters3/5

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

  With 0% schema description coverage, the description compensates by explaining the scope parameter values (all, project, global, custom bucket) and the default behavior. The query parameter is implied by the purpose, but the limit parameter is left unexplained, so the coverage is only partial.

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

  Purpose5/5

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

  The description clearly states the tool recalls memories by meaning using RAG, which is a specific verb-resource-action combination. It also specifies the default search scope (global + project), which distinguishes it from other memory tools like memory_store, memory_forget, or memory_walk.

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

  Usage Guidelines3/5

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

  The description implies usage when semantic recall of memories is needed but does not explicitly state when to use this tool versus alternatives such as memory_walk or recall_handoff. It provides detailed scope options (all/project/global/custom bucket) but lacks exclusions or alternative tool references.

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

• memory_walkA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description must communicate side effects and operational behavior. It only says 'walk' and specifies direction, leaving unclear whether the operation is strictly read-only, how cycles are handled, or what the traversal returns. The depth limit (max 6) appears in the schema but is not described in prose, so the agent lacks a full behavioral picture.

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

  Conciseness5/5

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

  The description is two concise sentences with no wasted words; the core action is stated first, and the direction parameter clarification is brief and useful. It does not duplicate schema content.

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

  Completeness2/5

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

  The tool has no output schema and no annotations, so the description should explain what a walk yields and any constraints. It omits the meaning/effect of depth, the return format (nodes, edges, paths?), and handling of cycles or graph loops. The note about direction is helpful but insufficient for an agent to confidently invoke the tool without further inference.

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

  Parameters3/5

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

  The description adds meaningful semantic value for the direction parameter by stating the default ('out') and possible values. The 'from' parameter is already documented in the schema as 'The id to start from,' and the description reinforces it as 'from a node.' However, the depth parameter is not explained beyond its numeric bounds, which is especially notable given only 33% schema coverage.

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

  Purpose5/5

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

  The description clearly states the action ('Walk the memory graph from a node along its links'), which is specific and distinct from sibling memory tools like memory_recall or memory_store. It also highlights the direction parameter and default, reinforcing its graph-traversal purpose. The parenthetical 'connected context around a decision' gives a concrete use case, though it is somewhat informal.

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

  Usage Guidelines4/5

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

  The phrase 'connected context around a decision' implies the tool should be used when one needs to explore relationships from a specific memory node. However, it does not explicitly mention alternatives (e.g., use memory_recall for semantic search) or exclusion conditions. It provides a clear context but no comparative guidance.

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

• write_handoffA
  3.7/5.0
  Behavior3/5

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

  The description discloses that handoffs are isolated to the current session's lane, which is a key behavioral trait. However, it does not specify side effects like overwriting an existing handoff, persistence semantics, or any constraints on the data, and there are no annotations to fill that gap.

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

  Conciseness5/5

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

  Two concise sentences that are well-structured and front-loaded with the action. No redundant information.

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

  Completeness2/5

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

  While the description explains the tool's purpose and isolation, it lacks details on parameter usage, whether handoffs are overwritten or appended, and how to retrieve them later. The sibling recall_handoff is not mentioned, leaving the agent to infer the full workflow.

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

  Parameters2/5

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

  The description provides no explanation of the goal, state, decisions, and nextAction fields. Schema has no descriptions and 0% coverage, so the agent must rely on parameter names alone. The description adds no parameter-level guidance.

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

  Purpose5/5

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

  The description clearly states the tool's function: saving a handoff for the current session's lane so a future session can resume. It uses a specific verb (Save) and resource (handoff), and distinguishes from the sibling recall_handoff by focusing on the write action.

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

  Usage Guidelines4/5

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

  It explains the context for use (saving session state for future resumption) and notes lane isolation, which implies it should not be used for cross-session shared state. However, it does not explicitly mention when not to use it or recommend the alternative recall_handoff for reading.

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

• recall_handoffA
  3.8/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Load', which implies a read operation, but does not explicitly state the tool is read-only, what happens if no handoff exists ('if any' is vague), or any side effects. The description adds minimal transparency beyond the action itself.

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

  Conciseness5/5

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

  The description is a single, concise sentence that is front-loaded with the primary action and scope. It contains no fluff or redundant information, making it highly efficient.

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

  Completeness4/5

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

  For a simple tool with no parameters and no output schema, the description provides sufficient context: it specifies the lane and the 'if any' conditional. However, it could be slightly more complete by describing what a handoff is or what the return value represents, but this is not critical given the simplicity.

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

  Parameters4/5

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

  The tool has zero parameters, and the input schema is empty (100% coverage). The baseline for 0 params is 4, and the description does not need to explain parameter meanings since there are none.

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

  Purpose5/5

  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 load the latest handoff for the current session's lane, specifically 'app@detached'. It uses a specific verb ('load') and resource ('handoff') with a precise scope, distinguishing it from siblings like write_handoff and memory_recall.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (to retrieve the latest handoff for this session's lane) but does not explicitly state when to use it versus alternatives like memory_recall or write_handoff. No exclusions or alternative tool mentions are provided, so usage guidance is implied rather than explicit.

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

• project_contextA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full behavioral burden. It discloses the return content and the 'no git subprocess' efficiency detail, but it does not explicitly state that the operation is read-only or mention any side effects, permissions, or caveats. This is a moderate disclosure.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence that packs the purpose, key components, and a differentiating feature ('no git subprocess') without waste. Excellent structure and economy.

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

  Completeness4/5

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

  Without an output schema, the description appropriately enumerates the return items (branch, commits, handoff, memories). It maps well to the parameters and provides enough context for a simple aggregation tool, though a bit more detail on ordering or format would be nicer.

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

  Parameters3/5

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

  Schema coverage is 100% and both parameters ('commits', 'memories') have clear descriptions and defaults in the schema. The tool description adds no additional parameter semantics beyond that, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description is specific and action-oriented: 'Orient in THIS project fast' followed by a clear list of what it returns (branch, commits, handoff, memories). It differentiates from sibling tools by emphasizing 'one call, no git subprocess', which is unique among memory/handoff tools.

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

  Usage Guidelines4/5

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

  The description clearly implies the use case: quick project orientation without invoking git subprocesses. However, it does not explicitly name alternative tools or state when not to use this one, so it's clear context but lacks formal exclusions.

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

• memory_forgetA
  4.1/5.0
  Behavior4/5

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

  Despite lacking annotations, the description discloses key behavioral traits: 'appends a tombstone' reveals that the memory is not actually deleted but hidden, and 'stops appearing in recall/walk' clarifies the consequence. This goes beyond a simple 'forget' and provides important implementation detail. However, it doesn't mention idempotency or error handling for nonexistent ids.

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

  Conciseness5/5

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

  The description is a single, compact sentence (11 words) that is front-loaded with the primary action and then clarifies the underlying mechanism. Every word earns its place, with no redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core purpose, the behavioral nuance (tombstone), and the observable effect (disappears from recall/walk). It doesn't explain return values or failure modes, but those are less critical for a forget operation. Overall, it is sufficiently complete for a low-complexity tool.

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

  Parameters2/5

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

  The schema has no description for the 'id' parameter (0% coverage), so the description must compensate. The phrase 'by id' is minimal and mostly restates the parameter name; it doesn't explain what kind of id, where to find it, or any format requirements. For a single-parameter tool, it adds little beyond what the parameter name suggests.

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

  Purpose5/5

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

  The description uses a specific verb ('Forget') and resource ('a memory by id'), clearly indicating the operation. It also distinguishes itself from siblings like memory_store, memory_recall, and memory_walk by focusing on the opposite action (forgetting vs. storing/recalling).

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

  Usage Guidelines4/5

  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 (when you want to forget a specific memory by its id), but it does not explicitly mention alternatives or when NOT to use it. No exclusions are stated, but 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.

• search_toolsA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of transparency. It discloses the scope ('every mounted MCP server'), the return format (qualified ids), and a critical behavioral requirement (must load before calling). This goes beyond the schema and gives the agent a clear expectation of how search results are used. Minor gaps include lack of pagination or error behavior, but the provided details are substantive.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, and every clause adds value. No unnecessary words or repetition of schema information.

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

  Completeness4/5

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

  For a relatively simple search tool with two parameters and no output schema, the description is nearly complete. It explains the scope, return format, and required next step. The only notable omission is behavior when no results are found or when limit applies, but the schema partially addresses limit. Overall, sufficient for the tool's complexity.

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

  Parameters2/5

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

  The schema descriptions only cover 50% of parameters (query has a description, limit does not). The description adds no parameter meaning, failing to explain the limit parameter or its effect on result count. Since schema coverage is not high, the description should compensate, but it remains silent on parameter semantics beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Search across every mounted MCP server') and its purpose ('for tools matching a query'), which is specific and distinct from sibling tools like load_tool or call_tool. It also explains the return format (qualified ids) and the next step, leaving no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description implies the usage context: use this when you need to discover tools across mounted servers. It provides a clear follow-up instruction ('load one with load_tool before calling it'), indicating that search results are not directly callable. However, it does not explicitly contrast with alternatives or state exclusions, so it falls 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.

• generate_imageA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that it writes to an absolute path, uses a configured provider, handles missing setup by providing instructions, and returns the saved file path. It does not mention overwrite behavior or error handling in detail, but the core side effects and return value are covered.

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

  Conciseness5/5

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

  Three sentences with no fluff: the first states the core action, the second explains provider setup, and the third specifies the path requirement and return value. Information is front-loaded and every sentence earns its place.

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

  Completeness4/5

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

  For a tool with five parameters, no output schema, and no annotations, the description is quite complete. It covers the purpose, provider setup, path constraint, and return value. It omits edge cases like overwrite behavior and error conditions, but the essential information for correct invocation is present.

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

  Parameters3/5

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

  The schema already provides 100% coverage for all five parameters with descriptions. The tool description only reiterates that out_path must be absolute, which is already in the schema, so it adds no new semantic value beyond the structured field definitions.

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

  Purpose5/5

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

  The description clearly specifies the verb (Generate), the object (an image from a text prompt), and the resource (saved to an absolute file path). It distinguishes itself from sibling tools because no other sibling performs image generation, and the mention of the image_gen provider adds specificity.

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

  Usage Guidelines4/5

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

  Provides clear context on provider options (codex CLI, OpenAI/Gemini) and setup fallback behavior, which helps the agent understand prerequisites. However, it does not explicitly name alternative tools or state when NOT to use it, so exclusion criteria are missing.

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

• reference_excerptA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It adds important traits such as 'SSRF-guarded and capped' and explains the query-centered behavior ('around query if given, otherwise the head'), which goes beyond the schema. While it doesn't cover error handling or exact output limits, it provides meaningful context for safety and output characteristics.

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

  Conciseness5/5

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

  The description is remarkably concise, using two sentences to convey the action, the query behavior, safety/limits, and intended use. Every clause earns its place, and there is no redundant or filler content.

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

  Completeness4/5

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

  The tool is relatively simple (3 parameters, no output schema, no annotations). The description covers purpose, behavior, and usage adequately, mentioning output type ('plain-text excerpt') and constraints ('capped'). It lacks some granularity (e.g., exact excerpt length or error cases) but is sufficient for straightforward invocation.

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

  Parameters3/5

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

  Schema descriptions cover 2 of 3 parameters (query and radius) with reasonable detail, and the description adds behavior around the query parameter ('around query') and implies safety for URL handling ('SSRF-guarded'). The URL parameter lacks a schema description, but the description's safety note partially compensates. Since coverage is moderate (67%), this is a baseline 3 with slight extra value.

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

  Purpose5/5

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

  The description clearly states the tool's function: fetching a page and returning a focused plain-text excerpt. It specifies the verb ('fetch'), the resource ('page'), and the output ('excerpt'), and the closing phrase 'For reading a specific passage' distinguishes it from sibling tools like reference_inspect and reference_read_source.

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

  Usage Guidelines4/5

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

  The description conveys a clear use case: 'For reading a specific passage,' and indicates the excerpt will center around a query or fall back to the head. However, it does not explicitly state when not to use this tool or name alternatives, 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.

• reference_inspectA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full transparency burden. It discloses live fetching, SSRF guarding, and size caps—critical behavioral traits for a web-fetch tool. It also clarifies non-copy intent. Missing details like whether the page is stored or rate limits are minor gaps for a read-only inspection tool.

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

  Conciseness5/5

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

  Two sentences, with the first enumerating outputs and the second adding safety and usage qualifier. Every phrase earns its place, and the description is front-loaded with the tool's core purpose.

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

  Completeness4/5

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

  For a single-parameter fetch-and-analyze tool, the description adequately covers inputs, outputs, safety, and usage intent. It lists expected return content, mitigating the lack of an output schema. It could mention alternative tools for source-level reading, but that is not essential for the tool's own completeness.

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

  Parameters3/5

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

  The schema already defines the single 'url' parameter as a URI, providing format-level detail. The description adds semantic context that the URL should be a reference page to study, but it does not explicitly link the parameter to the described behavior or add constraints beyond 'web page'. Since schema coverage is 0%, the description only partially compensates.

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

  Purpose5/5

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

  The description uses a specific verb ('Study') and concrete deliverables (title, description, frameworks, headings, top links) to clearly state what the tool does. It distinguishes from siblings by framing it as learning how a reference is built, not copying it, which separates it from reference_excerpt and reference_read_source.

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

  Usage Guidelines4/5

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

  It provides clear context (use to understand how a reference is built) and an explicit when-not ('not to copy it'). However, it does not name alternative tools like reference_excerpt or reference_read_source, so it falls short of the highest bar for explicit alternatives.

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

• tasks_steerA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It openly states that the operation is best-effort and warns that one-shot delegate CLIs may reject mid-run input, including that the tool will indicate when this occurs. This is valuable transparency beyond the raw schema.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the primary action and followed by one essential caveat. Every word earns its place, and the description is appropriately sized for this simple tool.

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

  Completeness4/5

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

  Given the tool's low complexity, the description is nearly complete: it explains the action, target, and the main failure mode ('the tool will say so'). No output schema exists, but for a two-parameter tool, the description adequately covers what the agent needs to know.

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

  Parameters3/5

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

  Schema coverage is 100%, with id and input already described clearly. The description adds the nuance of 'a line of input' (implying line-based stdin) and the best-effort behavior, but it does not substantially extend the parameter meaning beyond the schema.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Send a line of input to a running background task’s stdin.' This clearly defines the action and target, and it distinguishes the tool from sibling tools like tasks_interrupt and tasks_list by focusing on stdin input.

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

  Usage Guidelines4/5

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

  The phrase 'to a running background task' clarifies the intended use case, and the best-effort caveat provides context about limitations. It does not explicitly name alternatives, but the context is clear enough for selecting this tool over interrupt or list siblings.

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

• load_toolA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It reveals the behavior (fetching schema) but does not mention error handling, permissions, or what happens if the id is invalid. It is safe and read-only, but additional context would improve transparency.

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

  Conciseness5/5

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

  A single sentence that conveys the purpose and usage, with no wasted words. Packs essential information efficiently.

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

  Completeness5/5

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

  Given the simplicity of the tool (one parameter, no output schema), the description is complete enough: it states what it retrieves, the format expected, and the reason to use it. No significant gaps.

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

  Parameters4/5

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

  The schema covers the parameter with a description and example, and the tool description adds the 'qualified tool id (server.tool)' format requirement, which clarifies the expected structure beyond the schema's example. This adds meaningful semantics.

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

  Purpose5/5

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

  Clearly states the verb 'Get' and the resource 'full input schema for a qualified tool id', which distinguishes it from siblings like call_tool (executes) and search_tools (finds tools). The 'server.tool' format is explicitly mentioned.

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

  Usage Guidelines4/5

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

  Implies the tool is used when you need to call another tool correctly by first obtaining its schema. Does not explicitly state when not to use it or compare to alternatives, but the purpose is clear from the 'so you can call it correctly' phrasing.

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

• tasks_interruptA
  4.3/5.0
  Behavior4/5

  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 the mechanism (SIGTERM) and the state change (marked interrupted), which is substantial for a simple tool. It doesn't cover edge cases like task not running, but the core behavior is transparent.

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

  Conciseness5/5

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

  A single, front-loaded sentence that conveys all essential information without any filler. Every word earns its place.

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

  Completeness5/5

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

  The tool is simple (1 parameter, no output schema), and the description covers the purpose, the action, and the outcome. No return values need explanation since there is no output schema. The description is complete for this tool.

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

  Parameters3/5

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

  The input schema fully describes the only parameter 'id' with 'the task id to interrupt' (100% schema description coverage). The tool description adds no additional parameter semantics, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description states a specific verb ('Stop'), a specific resource ('running background task'), and the outcome ('mark it interrupted'). It clearly distinguishes from sibling tools like tasks_list and tasks_steer.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use it (when a background task is running and needs to be stopped). It does not explicitly name alternatives or when-not-to-use conditions, but the context is clear.

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

• design_layerA
  4.4/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the disclosure burden. It communicates that the tool is an opt-in retrieval mechanism and enumerates the content of each layer, which is helpful. However, it does not describe return format, pagination, error behavior, or explicitly state that the operation is non-mutating, though the 'pull' wording implies read-only.

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

  Conciseness4/5

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

  The description is front-loaded with the main purpose and then packs all six layer definitions into a single, dense sentence. While it is effective and every clause adds value, the run-on structure with semicolons and dashes reduces scannability; a bulleted list would be clearer.

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

  Completeness5/5

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

  For a tool with only one parametrized enum, no output schema, and no annotations, the description is remarkably complete. It covers the purpose, lists all layer options with their contents, specifies the prerequisite call (design_core first), and discloses the opt-in feature (features.rag). There are no significant missing details for the agent to invoke it correctly.

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

  Parameters4/5

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

  The single parameter layer has 100% schema coverage and an enum, but the schema description is terse ('which layer to load'). The tool description adds substantial meaning by elaborating on each enum value with concrete contents (e.g., 'donts (the vibecoded-tells catalogue...)' and 'scaffolds (occupancy-correct section scaffolds...)'), going well beyond the schema.

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

  Purpose5/5

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

  The description specifies a concrete action ('Pull ONE deeper design layer on demand, by name') and enumerates each of the six distinct layer options, giving clear resource scope. It also differentiates from the sibling design_core by positioning this as 'deeper' and 'on demand', so the agent knows exactly what this tool does relative to its nearest alternative.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance: 'Call design_core first; pull a layer only when the build needs it.' It also notes the opt-in gating ('features.rag') and points to the generate_image tool for image generation, which gives the agent contextual usage direction and a cross-tool reference.

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

• doctorA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses a key safety behavior—'Never prints secret values'—and implies a read-only nature by using 'Report'. It also indicates the output format switch via json:true, adding transparency about behavior without contradicting any annotations.

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

  Conciseness5/5

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

  The description is a compact three sentences: the first front-loads the primary action and scope, the second gives a usage hint, the third states a critical safety guarantee. Every sentence 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.

  Completeness4/5

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

  The description covers the tool's purpose, contents, output format option, and a key behavioral constraint. It does not formally specify the return schema or list field types, but given there is no output schema and the tool is a general status reporter, the description is enough for an agent to understand its functionality.

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

  Parameters4/5

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

  The schema only defines a boolean 'json' parameter with no description coverage. The description compensates by explaining exactly what 'json:true' does ('structured output'), which is more meaningful than the schema alone. It does not specify defaults or return format details, but the essential semantic is conveyed.

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

  Purpose5/5

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

  The description states a specific action ('Report Vibecoders status') and enumerates the exact contents covered (capabilities, delegation providers, mounted servers, optional API keys, tool groups, session's lane). This clearly distinguishes it from sibling tools like delegate or list_providers, which have narrower scopes.

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

  Usage Guidelines4/5

  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 it: to get a comprehensive status report. It also instructs how to request structured output ('Pass json:true'). It does not explicitly mention alternatives or exclusions, but its scope is self-evident from the enumerated fields.

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

• memory_storeA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does disclose key behaviors: 'durable' persistence, 'RAG-recallable later', and 'build a graph you can walk' – indicating long-term storage and recall implications. It also notes the default scope. Lacks details on idempotency or return value, but core behavior is well-covered.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the primary purpose and immediately actionable usage. Every sentence contributes value – scope explanation and graph-building tip – with zero redundancy.

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

  Completeness4/5

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

  For a write tool with no annotations or output schema, the description is largely complete: it covers purpose, scope options, graph-building usage, and use cases. Minor gaps around duplicate-id behavior and return responses exist, but they don't hinder selection or invocation.

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

  Parameters4/5

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

  Schema coverage is high (86%), so baseline is 3. The description adds meaningful guidance beyond the schema: it explains the purpose of id and links for graph building ('Pass a stable id and links to build a graph you can walk') and ties type values to use cases (decisions, facts, gotchas). This enhances understanding of parameter relationships.

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

  Purpose5/5

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

  Clearly states 'Save a durable memory to the graph (RAG-recallable later)' – a specific verb (save), resource (durable memory to graph), and benefit (later recall). Lists explicit use cases (decisions, facts, gotchas) and distinguishes itself from sibling read/deletion tools like memory_recall and memory_forget.

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

  Usage Guidelines4/5

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

  Gives explicit usage context: 'Use for decisions, facts, gotchas, and links between them.' Explains scope values (project/global/custom) and recommends passing id and links for graph construction. Does not explicitly mention when not to use or alternative tools, 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.

• reference_read_sourceA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description must disclose behavior itself. It states the tool is SSRF-guarded and capped, and that a reason is required, which gives meaningful safety and size constraints. However, it does not define the cap size, error behavior, or output format beyond 'full source', leaving some ambiguity.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that packs the action, resource, constraints, and usage guidance with no wasted words. Every phrase adds value.

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

  Completeness4/5

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

  For a simple 2-parameter tool with no output schema, the description covers purpose, when to use it, and key behavioral constraints. It doesn't explain exact return structure or error cases, but the core information needed for correct selection and invocation is present. Sibling tools are named for context.

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

  Parameters3/5

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

  The schema covers the 'reason' parameter with a description, but the 'url' parameter has no schema description. The tool description adds that the URL is SSRF-guarded and that reason is required, partially compensating. Yet it doesn't clarify acceptable URL formats or what counts as a valid target, leaving the 50% coverage gap only partially filled.

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

  Purpose5/5

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

  The description clearly states the tool fetches and returns the FULL source of a page (HTML/text), using a specific verb and resource. It explicitly contrasts with siblings (inspect/excerpt) by calling itself an 'escape hatch', distinguishing its role and scope.

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

  Usage Guidelines5/5

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

  It provides clear usage context: use when inspect/excerpt are not enough, and requires a reason. This tells the agent when to select this tool over alternatives like reference_inspect and reference_excerpt, and what prerequisite must be satisfied.

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

• web_searchA
  4.4/5.0
  Behavior4/5

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

  No annotations, so description must carry transparency. It discloses provider resolution behavior, that results are ranked, synthesized answers are optional per provider, and setup fallback. Missing rate limits/error details, but covers key operation traits.

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

  Conciseness5/5

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

  Three focused sentences: purpose, provider context, fallback guidance. No filler.

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

  Completeness4/5

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

  Tool has 4 params and no output schema; description explains what it returns (ranked results, maybe summary) and how provider is selected. Slight gap on exact return structure, but acceptable.

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

  Parameters4/5

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

  Schema already covers all 4 params with descriptions (100% coverage), baseline 3. Description adds context about provider options (e.g., gemini CLI no API key) and auto-resolving, enriching the provider param beyond the enum.

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

  Purpose5/5

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

  States 'Search the web for a query and return ranked results', a specific verb-resource combination. Distinguishes from siblings like search_tools by explicitly targeting web content. Also notes synthesized answer when provider offers.

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

  Usage Guidelines4/5

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

  Gives clear context: uses configured provider, and if none set up, explains how to enable. Doesn't explicitly contrast with alternative tools like search_tools, but the web-search scope is unambiguous.

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

• list_providersA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosure. It explicitly states that only providers with CLI installed are included and clarifies the billing model (subscription-based, not metered API). This adds meaningful behavioral context beyond the tool name, though it does not discuss error conditions or return structure.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose, and every clause adds value. No redundancy or filler.

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

  Completeness5/5

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

  For a zero-parameter, no-output-schema tool, this description fully covers what the agent needs to know: what it lists, why it matters, and how it differs from metered APIs. It is complete for the tool's simplicity.

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

  Parameters4/5

  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 appropriately focuses on what the tool returns rather than parameter details, which are unnecessary here.

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

  Purpose5/5

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

  The description specifies the exact action ('List delegation providers') and the resource scope ('whose CLI is installed') plus the additional detail about billing. It clearly distinguishes itself from sibling tools like 'delegate' by focusing on provider enumeration rather than executing delegation.

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

  Usage Guidelines4/5

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

  The description provides clear context about when this tool would be relevant (checking providers and billing before delegation) and even clarifies the underlying model of delegation. However, it does not explicitly mention when to use it over alternatives or provide exclusion criteria, so it stops short of a full 5.

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

• tasks_listA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses behavior beyond the bare listing: results are newest first, and passing an id returns full output. It could mention return format or error handling, but for a simple list tool, these are sufficient.

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

  Conciseness5/5

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

  The description is only two sentences, with the main purpose front-loaded in the first sentence and parameter guidance in the second. Every word earns its place; there is no fluff or repetition of schema details.

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

  Completeness5/5

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

  Given the tool's simplicity (one optional parameter, no output schema), the description fully covers purpose, ordering, and optional parameter behavior. It is complete enough for an agent to select and invoke the tool correctly. No additional context is needed.

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

  Parameters4/5

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

  The schema already provides 100% coverage for the 'id' parameter. The description adds valuable context by specifying 'a prior tasks_list' as the source of the id and that it returns 'full output,' which builds on the schema's description rather than repeating it. This justifies a score above the baseline of 3.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and identifies the exact resource ('background delegations') with a clarifying filter ('started with delegate background:true'). It also specifies ordering ('newest first'), which distinguishes it from sibling tools like tasks_steer or tasks_interrupt.

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

  Usage Guidelines4/5

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

  The description clearly states what the tool does and when to use it: to list background delegations. It also provides guidance for the optional id parameter ('Pass an id to get that task’s full output'), though it doesn't explicitly contrast it with alternatives like tasks_steer or tasks_interrupt.

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

• delegateA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden. It discloses billing implications, read-only safety default, write mode boundaries (files under cwd), background behavior, and immediate return of a task id for background tasks. This is comprehensive behavioral disclosure.

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

  Conciseness5/5

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

  The description is three sentences, each earning its place. It front-loads the main purpose, then clarifies modes and background behavior, then gives a prerequisite. No fluff or redundancy.

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

  Completeness4/5

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

  Despite lacking an output schema and annotations, the description covers the tool's core behavior, modes, background task management, and prerequisites. It does not specify the return format for non-background tasks, but the description is otherwise complete for a delegation tool of moderate complexity.

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

  Parameters4/5

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

  The schema covers all 6 parameters, so baseline is 3. The description adds meaningful context beyond the schema by explaining mode semantics, background return behavior, and the requirement to check list_providers for the provider parameter, enriching an already fully documented schema.

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

  Purpose5/5

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

  The description uses a specific verb+resource: 'Hand a task to another coding agent via its CLI.' It clearly distinguishes the tool's purpose from siblings by mentioning delegation, billing via subscription, and referencing list_providers/tasks_* tools for related functionality.

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

  Usage Guidelines4/5

  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: 'Call list_providers first to see what is installed' is an explicit prerequisite. It also explains mode and background usage, but does not explicitly compare to alternative tools or state when not to use delegate.

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

• design_coreA
  4.7/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the transparency burden. It discloses that it loads content, and mentions the opt-in requirement. However, it does not specify whether it modifies state or returns data, relying on the verb 'load' to imply context loading. 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.

  Conciseness5/5

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

  The description is concise and well-structured. It front-loads the main action and resource, then elaborates on contents and usage sequence. Two sentences cover all essential information without redundancy.

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

  Completeness5/5

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

  Given the tool has no parameters, no output schema, and no annotations, the description effectively covers its purpose, when to invoke it, and its relationship to design_layer. The opt-in flag is also disclosed. It is complete for an agent to decide when and how to use it.

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

  Parameters4/5

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

  The tool has zero parameters, so schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description correctly avoids discussing parameters.

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

  Purpose5/5

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

  The description clearly identifies the tool as loading the 'design-intelligence core' with specific contents (standard, tells principle, build non-negotiables). It distinguishes itself from the sibling tool design_layer by indicating this is the first call and design_layer is a subsequent layer pull.

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

  Usage Guidelines5/5

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

  Explicitly instructs to 'Call this FIRST when building ANY UI, website, page, component, or visual' and provides the alternative/next step: 'then pull a layer with design_layer'. Also mentions the opt-in feature (features.rag) as a prerequisite.

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