Rokha

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

The description contains 'Read-shaped tools only (anything that buys, sells or writes refuses),' implying this tool is read-shaped (read-only). Yet the annotation declares readOnlyHint: false, meaning the tool is not strictly read-only and may have side effects. This is a direct contradiction, and the description does not clarify the actual side-effect profile beyond saying 'in-memory'.

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 first sentence is useful, but the description quickly devolves into server context ('a live seat on The Wall'), irrelevant read-shaped tool policy, and a listing URL. This wastes the agent's attention and does not front-load the most actionable information about how to call the tool.

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

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

No output schema is provided, and the description gives no indication of what the tool returns beyond 'their data comes back as it is' (vague). With 4 parameters, nested objects, and complex input requirements, the description does not provide enough information for the agent to correctly compose the manifest or interpret results.

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

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

With schema description coverage at 0%, the description must explain parameter meaning. It clarifies that skillIds are 'exact skill IDs already chosen' but gives no guidance on profile, name, or targets. The nested profile object has required goals and optional fields that are entirely unexplained, so an agent cannot reliably construct valid inputs.

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

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

The description states a specific verb and resource: 'Build an in-memory Core manifest from exact skill IDs already chosen by Codex or Claude.' This clearly identifies what the tool does and hints at its input (skill IDs) but does not actively differentiate from sibling tools like inspect_stack or diff_stack beyond the 'already chosen' phrase.

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?

Provides a sequencing precondition: 'Call only after the agent has enumerated primary project capabilities.' However, it gives no guidance on when to choose this over siblings (e.g., inspect_stack, diff_stack) or when not to use it. No alternative tools are mentioned, so the usage context is partial.

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 destructiveHint=false. The description adds useful context by stating the diff runs only against locally cached, integrity-verified catalogs and that data 'comes back as it is.' The 'read-shaped tools only' line mostly duplicates the annotation, so incremental transparency is moderate.

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 first sentence is useful and front-loaded, but the rest contains boilerplate about the MCP server, sandbox, and a registry listing URL. This unrelated context adds length without helping an agent invoke the tool correctly.

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

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

For a tool with two required parameters, one deeply nested, and no output schema, the description is incomplete. It does not describe expected return values, how to construct the stack object, what toCatalogDigest refers to, or what 'diff' outcome looks like.

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

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

Schema coverage is 0%, and the description does not explain the meaning of 'stack' or 'toCatalogDigest' beyond the schema property names. The tool must compensate when schema coverage is low, but it does not, leaving an agent to infer parameter semantics from names alone.

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

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

The first sentence uses a specific verb and resource: 'Diff a stack only against locally cached, integrity-verified catalogs.' It conveys the core action and its constrained scope. However, it does not explicitly differentiate among sibling stack tools like compose_stack or inspect_stack.

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?

No guidance is given for when to use this tool versus siblings or alternatives. The read-only and local-cache constraints are mentioned, but there is no explicit context for when an agent should prefer this tool, nor are alternatives 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 description claims the tool is 'read-only' and says 'anything that buys, sells or writes refuses', but annotations set readOnlyHint=false. This is a direct contradiction. The extra 'seat on The Wall' and 'Rokha's sandbox' phrasing adds jargon rather than behavioral clarity.

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 first clause is useful, but the description quickly becomes a run-on with an incomplete phrase ('plus the agent-declared —'), unexplained sandbox/seat jargon, and a registry URL. It is not economically concise and is poorly structured 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?

For a tool with four required nested parameters and no output schema, the description is severely incomplete. It does not explain what the sidecar contains, how the inputs map to the output, or what the agent should expect after calling the tool.

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

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

Schema description coverage is 0% and the description names none of the four required parameters (manifestDigest, project, dimensions, capabilities). With highly nested required inputs and no compensating explanation, the description leaves parameter semantics entirely to the schema.

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

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

The description opens with a concrete verb and resource: 'Build a canonical, read-only aas-selection-evidence.json sidecar' from the session's search/get/compose/inspect trace. It is clear about the core purpose, but it does not explicitly differentiate from siblings like inspect_selection_evidence or compose_stack, and the sentence becomes garbled with 'agent-declared —' and 'seat on The Wall' context.

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

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

There is no when-to-use guidance or mention of alternatives. The only behavioral note is 'Read-shaped tools only', which is a constraint rather than a usage guideline. An agent is not told when to choose export_selection_evidence over inspect_selection_evidence or compose_stack.

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 provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds value by disclosing that full text is returned only when requested and is explicitly untrusted, plus the passthrough behavior ('their data comes back as it is'). These details go beyond the annotations without contradicting them.

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 opening sentence is clear and front-loaded, but the rest of the description is cluttered with server-level metadata, a listing URL, and an incomplete fragment ('Compare multiple plausible candidates for each —'). This extraneous content detracts from conciseness and structural quality.

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 no output schema, the description should explain the return structure, but it only vaguely mentions 'descriptive catalog record' and 'full text'. It also fails to clarify how to specify id or what includeContent exactly changes. An agent cannot reliably call this tool based solely on the provided description.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It implies that 'id' identifies a local skill and that 'includeContent' controls whether full text is returned ('only when requested'). However, it does not specify the format of id or the exact output semantics, leaving meaningful gaps.

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 first sentence clearly states the tool retrieves a descriptive catalog record and, only when requested, the full text for a local skill. It names a specific action and resource, which distinguishes it from sibling tools that deal with files or search, though it does not explicitly name those alternatives. The purpose is somewhat obscured by unrelated server context later in the description.

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 offers no explicit guidance on when to use this tool versus alternatives like search_skills or read_skill_file. The mention of 'Compare multiple plausible candidates for each' is incomplete and does not clarify selection criteria. Server-level notes about read-shaped tools are not usage 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is clear. The description adds one meaningful behavioral detail—'without judging the agent's semantic choices'—which clarifies that validation is purely structural. However, the rest of the extra context (the seat, The Wall, sandbox, registry link) is tangential and does not enhance behavioral transparency. The description does not contradict annotations but also does not go far beyond them.

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 core purpose is front-loaded in the first sentence, which is good. But the description then includes a large amount of tangential information: the server name, 'a live seat on The Wall (runs in Rokha's sandbox)', 'Called through their seat; their data comes back as it is.', 'Read-shaped tools only...', and a registry link. These sentences do not aid tool selection or invocation. The description is overlong relative to its actual content, warranting a mid score.

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

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

The tool is complex: two nested object parameters, no output schema, and no parameter descriptions. The description does not explain what the function returns on success/failure, how to interpret the validation result, or what constitutes valid evidence versus invalid. It also leaves the meaning of 'active verified catalog' and 'canonical selection-evidence sidecar' unspecified. For such a complex validation tool, the definition is insufficiently complete for an agent to call it confidently without further context.

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 0%, so the description carries the full burden of explaining parameters. It identifies 'evidence' as a 'canonical selection-evidence sidecar' and 'manifest' as a manifest object, which adds minimal meaning. However, it does not describe the required structure, content, or semantics of either object beyond what the schema already shows (and the schema itself lacks descriptions). The phrase 'active verified catalog' is also undefined. With two object parameters and zero schema descriptions, this is inadequate—an agent would not know how to construct the 'evidence' object or what the validation checks.

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 ('validate'), a specific resource ('canonical selection-evidence sidecar'), and the targets ('a manifest and the active verified catalog'). It also clarifies what it does not do ('without writing files or judging the agent's semantic choices'), which distinguishes it from sibling tools like export_selection_evidence and diff_stack. No ambiguity remains about the tool's core operation.

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 does not explicitly state when to use this tool versus alternatives. It mentions 'without writing files or judging the agent's semantic choices', implying it is for validation only, but it never names sibling tools or contrasts its role (e.g., vs. export_selection_evidence). The generic server-level note 'Read-shaped tools only' applies to all tools in the server, not this one specifically, and offers no routing guidance. An agent would have to infer usage context from the tool name and description alone.

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 carry readOnlyHint=true and destructiveHint=false; the description productively reinforces and elaborates with 'Read-shaped tools only (anything that buys, sells or writes refuses)' and the in-memory/no-write framing. It adds multi-tenant context (Rokha's sandbox, 'their data comes back as it is') beyond the annotations. No contradiction with the annotation set.

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 first sentence is tightly front-loaded and earns its place, and the 'Read-shaped tools only' line is informative. But the tail — 'a live seat on The Wall', 'called through their seat', and the registry URL — is largely promotional noise that does not help an agent invoke the tool. Moderate verbosity reduces an otherwise clean opening.

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 validation tool with a single deeply nested manifest and no output schema, the description omits how results are reported (what invalid looks like, whether it returns per-skill findings). The input side is well covered by the schema, but the agent is left guessing at the return contract of a tool whose entire purpose is returning a verdict.

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 0%, so the description must compensate, and it partially does: it maps the manifest's intent (validating the stack's catalog identity and skill IDs). However, it never explains how to construct the manifest input or what the returned validation verdict looks like. The rich schema (patterns, enums, minItems) carries the structural burden, so the description adds only loose semantic framing — a middle score 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 opening clause 'Validate an agent-selected in-memory AAS stack, its pinned catalog identity, and every selected skill ID without writing it' names a specific verb (validate), resource (AAS stack, catalog identity, skill IDs), and a distinguishing trait (no-write). It is clear against the broader sibling set (e.g., compose_stack writes, diff_stack compares), though it never explicitly names a sibling to contrast with.

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 'without writing it' phrasing implies this is the dry-run/checking option versus a composing/writing sibling, but no alternative is named and no when-to-use/when-not-to-use condition is stated. The guidance is implied rather than explicit, leaving the agent to infer the boundary against compose_stack.

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 destructiveHint=false, so the description's 'reads only the local inventory and never execu...' adds a specific behavioral guarantee (no execution) and 'stable path order' describes output ordering. However, the description is truncated mid-sentence ('never execu —') and includes unrelated server metadata, reducing clarity. It doesn't contradict annotations.

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

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

The first sentence is concise and front-loaded, but the description then degrades into a truncated fragment ('never execu —') and a block of unrelated MCP server metadata about 'The Wall', 'Rokha's sandbox', and a registry URL. This noise should be removed or moved; it doesn't help the agent call the tool.

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

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

With no output schema, the description should explain what the tool returns, but it only says it lists files 'in stable path order' without describing the return format or how `limit`/`cursor` pagination works. The truncated execution note and server metadata further detract from completeness. An agent cannot fully predict the tool's behavior from this definition.

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 0%, so the description must compensate. It implies the required `id` identifies the skill bundle ('in a skill bundle'), but it never explicitly names or explains `id`, `limit`, or `cursor`. The pagination parameters (`limit`, `cursor`) are entirely undocumented in the description, leaving the agent to guess their semantics.

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: 'List catalog-bound files in a skill bundle, including scripts and reference documents, in stable path order.' This clearly distinguishes it from siblings like read_skill_file (which reads a file) and get_skill. However, it doesn't explicitly name sibling alternatives, so it doesn't fully differentiate.

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 no explicit when-to-use or when-not-to-use guidance relative to alternatives. It only states 'This reads only the local inventory and never execu...' which implies a safe read operation, but doesn't tell the agent when to choose this over read_skill_file or search_skills. The server-level 'Read-shaped tools only' note is about the environment, not usage selection.

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 annotations, the description adds meaningful behavioral context: the file is untrusted and inert, the tool verifies the file digest, it runs in a sandbox, data comes back as-is, and write/buy/sell operations are refused. This substantially supplements the readOnlyHint and openWorldHint annotations.

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

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

The description is front-loaded with the core purpose and then adds safety and sandbox context. It is not excessively long, but includes tangential details such as the registry listing URL and a truncated clause ('Verifies the file diges —'), which reduces polish and clarity.

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

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

The description covers the tool's purpose, path source, trust model, and read-only constraints, which is strong for a simple read tool. However, it does not explain the 'id' parameter or the return format beyond calling the content 'inert text', leaving a notable gap for an agent to fully invoke the tool without additional inference.

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

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

Schema coverage is 0%, so the description must compensate for both parameters. It explains the 'path' parameter by instructing to use the exact relative path from list_skill_files, but says nothing about the 'id' parameter, leaving a required parameter semantically undefined.

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

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

The description states a specific verb and resource: 'Read one catalog-bound UTF-8 file from a local skill bundle'. It clarifies the file is treated as untrusted, inert text and directs the user to use the path from list_skill_files, which effectively distinguishes this file-reading tool from sibling tools like get_skill or list_skill_files.

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

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

The description gives clear usage context: the file is read by its exact relative path from list_skill_files, and the tool is read-shaped only. It does not explicitly name alternatives or state when not to use the tool, but the context is sufficient for an agent to select it for reading a specific file.

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, destructiveHint=false, and openWorldHint=true. The description adds meaningful behavior: no local-state changes, no ranking/recommendations, stable order, and refusal of buying/selling/writing operations. This goes beyond the annotations without contradicting them.

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 core purpose is front-loaded in the first sentence, but the description includes redundant or vague phrasing such as repeating the server identity and the 'live seat on The Wall' aside. The listing URL and refusal behavior are useful, yet the middle section could be tighter.

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 seven parameters and no output schema, the description leaves significant gaps: pagination semantics through cursor, how matchMode interacts with tags/categories/requiredTerms, and expected return shape. The read-only and ordering guarantees help, but the tool is under-described for an agent to invoke confidently.

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 0%, and the description does not explain any of the seven parameters (tags, limit, query, cursor, matchMode, categories, requiredTerms). It gives a general sense of 'matching skills', but no parameter-level meaning is added, leaving the agent to infer semantics from names and enums alone.

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

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

The description uses a specific verb and resource: 'Retrieve matching skills from the verified local AAS catalog', and adds distinguishing characteristics like 'stable catalog order' and 'without relevance scores, ranking, recommendations'. This clearly separates it from generic search or recommendation-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?

The description implies usage for read-only, local catalog searches and explicitly notes that write-like operations are refused, but it does not name alternatives or state when to prefer another sibling such as registry_search or get_skill. Some context is provided, but exclusion guidance is missing.

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

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

Annotations only provide readOnlyHint and destructiveHint, so the description adds substantial behavioral value: 'Public, no auth,' the payout split, points caps, trailing-7-day calculation, instant USDC payment, and the contract obligations. This goes well beyond what annotations already convey and helps the agent understand the consequences and constraints around using the feed.

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 contains dense and useful information, but it is not tightly front-loaded: it opens with the marketing-like 'JOIN ROKHA'S AGENT MARKETING NETWORK and get paid' before stating what the tool actually is. The rest of the content earns its place, but the opening sentence is more promotional than descriptive and adds noise.

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

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

For a zero-parameter, read-only feed with no output schema, the description is remarkably complete. It enumerates the placement fields (title, pitch, url, when, sponsor's /word), states the contract, explains payout mechanics, and confirms public access with no auth. Nothing an agent needs to call this tool correctly appears to be missing.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. Per the calibration baseline for zero parameters, this is a 4; the description cannot add parameter-level meaning that does not exist.

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

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

The description and title clearly identify the tool as 'The ad network feed' listing live placements and the accompanying contract. It does not use an explicit verb like 'list' or 'retrieve,' but the resource and scope are unmistakable. It is easily distinguishable from adnet_join and adnet_report, though it does not explicitly name those 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 clear context: this tool surfaces available placements and the rules for pushing them. It explicitly routes reporting obligations to adnet_report, which is useful alternative guidance. It does not mention when-not to use this tool, but for a zero-parameter public feed, the usage context is sufficiently clear.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's job is light on safety disclosure. It adds useful behavioral context beyond annotations: the call is idempotent, requires a Bearer JWT, and creates the public carrier board entry with payment consequences. 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?

The description is dense but purposeful, front-loading the core action and requirements before parameters. The payment explanation is relatively long, but it earns its place by correcting a likely misconception (no separate carrier payout). No wasted sentences.

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?

This is a mutating registration tool with no output schema, so the description carries the burden of explaining what to expect. It thoroughly covers prerequisites, parameters, idempotency, and consequences, but it never states what the call returns (e.g., confirmation, profile object, error). An agent would be uncertain how to handle the response.

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 50% (link_url and avatar_url have descriptions; name and surface do not). The description compensates by explaining that `name` should be short and that `surface` is a line describing where the agent will push, with concrete examples. It also reinforces the optionality and board context for avatar_url and link_url.

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 'Register the caller as a PUBLISHER', a specific verb and resource that precisely identifies the tool's function. This clearly distinguishes it from sibling adnet tools like adnet_feed, adnet_me, adnet_report, adnet_rounds, and adnet_stats, which all handle different aspects of the network.

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

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

The description provides clear context: it is the registration tool for becoming a publisher, and it explicitly states prerequisites (SOLANA-wallet login behind the JWT, Authorization: Bearer <JWT>). It does not explicitly contrast this tool with alternatives or state when not to use it, but the use case is strongly implied.

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 mark readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the auth requirement and the exact data categories returned, which goes beyond what the annotations provide; no rate-limit or failure behavior is disclosed, but that is not critical for this simple read-only tool.

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

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

A single sentence packs all essential facts with no filler: the data returned and the auth requirement. It is front-loaded with the functional payload and remains easy to scan for an agent.

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 parameterless, read-only self-profile tool, the description is complete: it identifies whose data is returned, which fields are included, and the required authorization. The absence of an output schema is acceptable because the description explicitly enumerates the returned information.

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

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

With zero parameters, the schema already trivially covers parameter semantics, and the description correctly adds no parameter details. The 0-parameter baseline of 4 applies, and there is no gap to compensate for.

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 immediately identifies the resource as 'my network standing' and enumerates the specific facts returned: publisher status, payable login, trailing-7-day points, payout status, and payout history. It clearly implies a read-only self-status query, though it lacks an explicit action verb and does not itself distinguish it from adnet_stats or adnet_report.

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 text says what the tool returns and that it requires an Authorization header, which signals it is intended for the authenticated user. It does not explicitly state when to choose this tool over adnet_stats/adnet_report or other alternatives, leaving usage to be inferred rather than stated.

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

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

The description explicitly says 'Upserts the day's totals,' which is a write operation, directly contradicting the annotation readOnlyHint=true. Although the description discloses cap-based point recomputation and return behavior, the contradiction is a serious inconsistency that could mislead an agent about the tool's side effects.

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

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

The description is dense but well organized: core action, metric definitions, upsert semantics with caps, return values, then auth. Every clause contributes operational detail, with no filler, though the length is somewhat high.

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 no output schema, the description correctly takes on the burden of explaining return values ('today's counted numbers and trailing-7-day points') and prerequisites. It also covers the scoring mechanism and the placement source, giving an agent everything needed to invoke the tool correctly.

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

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

The input schema describes only order_id as 'from the feed,' leaving serves, recalls, and clicks undocumented. The description compensates fully by defining each metric, specifying caps and multipliers (serves ≤100×1, recalls ≤50×2, clicks ≤20×5), and clarifying that totals are upserted rather than summed from claims.

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 action and resource: 'Tell the network what you actually did TODAY with one placement from the feed.' It then defines all three metric fields with plain-language meanings, making the tool's job unambiguous. The title is reinforced rather than merely restated.

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 states when to use the tool (reporting today's actual activity for a single placement from the feed) and gives prerequisites ('Requires Authorization: Bearer <JWT> and adnet_join'). It does not explicitly name sibling tools to avoid, so exclusions are implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: it is public, contains addresses and signatures only, never handles, and covers both INSTANT per-revenue-event entries and legacy weekly rounds. No pagination, ordering, or rate-limit behavior is disclosed, but for a read-only public ledger the key behavioral traits 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.

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

The description is a single information-dense sentence with no filler; it front-loads the core subject ('Every settle of the agent marketing network') and then packs the payload details. The em-dash structure is somewhat run-on, but every clause contributes meaningful information and nothing feels redundant.

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

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

Given there is no output schema and no parameters, the description does a good job of conveying what the response contains: revenue, deposit signatures, house share, pools, per-share details, payout addresses, points, USDC, transaction signatures, and status. It also clarifies privacy semantics. Minor gaps remain, such as ordering, time range, and how to interpret status values, but these are not critical for a no-parameter public ledger.

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

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

The tool has zero parameters, so there is nothing for the description to clarify beyond what the empty schema already shows. The description still adds value by enumerating the output contents (revenue, signatures, house 50%, pool, carried-in pool, shares, payout address, points, USDC, tx signature, status), which helps an agent understand what a no-argument call returns.

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 resource (the ad network's public ledger of settles) and the scope (every revenue event plus legacy weekly rounds), and enumerates the contained data. It lacks an explicit action verb like 'list' or 'view', but the title and content make the retrieval purpose unambiguous. Sibling differentiation is partial: it emphasizes INSTANT per-revenue-event entries, which distinguishes it from legacy weekly rounds, but it doesn't name sibling tools.

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

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

The description implies usage: this is the public ledger for ad-network settles, applicable when one needs revenue, pool, house cut, and payout share details. It gives contextual hints about what it covers but does not explicitly state when to prefer it over related tools like adnet_stats, adnet_report, or payouts_ledger, nor does it provide exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable context by listing the exact data returned and noting the tool is 'Public', which goes beyond annotation coverage. It doesn't mention caching, latency, or rate limits, but for a read-only stats tool this is sufficient.

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, well-structured sentence with the primary purpose ('live state') front-loaded, followed by a clear list of return items. Every phrase adds information; no wasted words.

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

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

For a parameterless read-only tool with no output schema, the description fully specifies what the agent can expect: revenue, parked pool, publisher count, top reporters, last round, and payout status. It also signals public access. Nothing an agent needs to call it correctly is missing.

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

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

There are zero parameters, so the description has no need to explain them. Per the rubric, 0 params warrants a baseline of 4. The description doesn't introduce any misleading parameter references.

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

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

The description clearly states the tool provides a live snapshot of the ad network, enumerating specific data points (settled revenue, parked pool, publisher count, top reporters, last round, payout status). This distinguishes it from sibling tools like adnet_rounds (round history) or adnet_feed (likely feed content), even without explicit comparison.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions 'Public' which may imply accessibility, but it doesn't state 'use this for a quick overview' or contrast with adnet_report or adnet_rounds. Usage context is implied but not spelled out.

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 convey readOnlyHint=false and destructiveHint=false, so the bar is lower. The description adds genuine behavioral value: the clock keeps running after pausing (cost continues), and it discloses the auth requirement (Bearer JWT). It does not mention the reversibility or response shape, but with annotations covering the safety profile, these additions are meaningful.

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

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

Two short sentences with zero filler. The core action is front-loaded, the key side effect ('clock keeps running') is attached immediately, and the auth requirement is stated compactly. Every clause earns its place.

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

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

For a single-parameter, mutation-type tool with annotations present, the description covers purpose, side effect, and auth. It omits return-value behavior and error conditions, but given the simplicity of the tool (one integer param, no output schema) and annotation coverage, the remaining gaps are minor.

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 0%, so the description must compensate, but it never mentions the sole required parameter 'id' or what it refers to. While an agent could infer that id is the campaign ID from the tool name, the description itself adds no parameter-level meaning, leaving the mapping implicit.

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

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

States a specific verb and resource ('Stop a live campaign') with a clarifying behavioral qualifier ('from being recalled or served'). The parenthetical about the clock distinguishes this from destructive or terminal actions, and the tool name distinguishes it from siblings like ads_campaign_resume and ads_campaign_update.

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 usage on live campaigns and notes billing continues, which gives some context for deciding to pause. However, it provides no explicit when-to-use vs alternatives, does not name ads_campaign_resume as the inverse, and does not mention any exclusions (e.g., already-paused campaigns or ordering constraints). Usage is inferred rather than stated.

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

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

The description adds the auth requirement (Bearer <JWT>) beyond annotations, which is useful. However, it does not disclose side effects (e.g., what happens if the campaign is not paused) or return behavior. With annotations already indicating non-read-only and non-destructive, the description adds moderate value but leaves gaps.

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

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

The description is a single, front-loaded sentence with no filler. It states the action and the auth requirement efficiently, earning its place.

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

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

For a simple one-parameter tool with no output schema, the description covers the core action and auth but omits details like preconditions (campaign must be paused) and potential errors. It is minimally sufficient but leaves room for an agent to misstep if the campaign is in an unexpected state.

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 0%, so the description must compensate for the single 'id' parameter. It does not mention what 'id' refers to or any format constraints. The parameter is simple, but the description fails to add meaning beyond the schema, leaving the agent to infer it is the campaign ID.

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

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

The description states a specific action ('put a paused campaign back in the agent's memory and the /ad rotation') on a specific resource (campaign), clearly distinguishing it from siblings like ads_campaign_pause and ads_campaign_update.

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

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

The phrase 'a paused campaign' implies the tool is for resuming previously paused campaigns, giving clear context. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it appropriately.

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 behavioral details beyond the annotations, such as the immediate memory re-sync ('the agent's memory re-syncs at once') and the required Authorization header. It also clarifies this is a write operation on live campaigns, consistent with readOnlyHint=false. These details help the agent anticipate side effects.

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, action-first sentence that conveys the core purpose, lists the editable fields, notes the memory side effect, and states the auth requirement. There is no filler or redundancy.

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

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

For a 7-parameter tool with no output schema, the description explains the action and side effect but does not specify the response format, error cases, or the exact meaning of each field (e.g., what 'when line' and '/word' refer to). It is adequate for a straightforward edit but not fully complete for an agent to invoke without additional inference.

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

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

With 0% schema description coverage, the description must compensate. It maps several schema fields to human-readable terms ('link' for url, 'name' likely for title, 'when line' for when, '/word' for slug, 'logo' for logo_url), but it omits 'id' entirely and does not explain formats or the required nature of some fields. It adds partial meaning but leaves gaps.

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

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

The description clearly states the tool rewrites a live campaign's copy elements (link, name, pitch, when line, /word, logo), which is a specific verb and resource. It differentiates from sibling tools like ads_campaign_pause and ads_campaign_resume, which handle state changes rather than content editing.

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

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

The phrase 'live campaign' implies when to use it, but the description gives no explicit guidance on when not to use it or how to decide between this and related tools like ads_campaign_pause. It does not mention alternative tools or preconditions beyond authentication.

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 minimal annotations, it discloses the payment flow (exact USDC from the caller's login wallet, Solana Pay URI), activation timing ('Goes live on finality'), authentication requirement (Bearer JWT from Solana-wallet login), default slug behavior ('your /word is made from the title if you don't pass one'), and the sponsored labeling for 'memory'. This is rich behavioral context for a purchase tool.

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

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

The description is long but information-dense: every clause adds packaging, pricing, payment, auth, or activation detail. It is front-loaded with the core action, though a few marketing phrases ('AdSpace board's orbit ring', 'weekly Rokha AdSpace Promotions roundup post') could be trimmed without losing meaning.

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 no output schema, the description still covers the return payload (order + payment instructions, USDC amount, Solana Pay URI), prerequisites, and activation. It doesn't explain all seven parameters or mention status-check/cancellation siblings, but for the actual purchase flow it is largely 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?

Schema coverage is only 29%, but the description compensates for the most important parameters: it defines the package enum values (memory/slot/bundle), explains the 'when' matching behavior, and clarifies the optional slug default. It leaves url, title, and pitch semantically undocumented, though their names are fairly self-explanatory.

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

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

Opens with a specific verb and resource: 'Buy placement inside the agent by the week' and immediately pins the tier as ORBIT, with package definitions for memory/slot/bundle. This clearly separates it from auction/PLANET/MOON paths and from sibling listing/check tools like ads_orders and ads_order_check.

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

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

The description gives clear context: use this for weekly ORBIT placement, states 'unlimited, no bidding', and points to GET /api/adspace for the auction PLANET/MOON perks. It does not explicitly name sibling alternatives such as adspace_bid or ads_order_check, so the when-not-to-use 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.

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

Annotations already mark the tool read-only and non-destructive, and the description adds non-redundant context by requiring 'Authorization: Bearer <JWT>' and explaining that 'active' means live in the agent's memory. It does not enumerate other statuses, but the auth requirement and status meaning are valuable behavioral disclosures.

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

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

The description is two short sentences, front-loads the core operation, and uses the dash to attach the status meaning without padding. The auth note is the only added requirement and earns its place.

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

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

The tool is simple and the description covers purpose, auth, and one status value, but because there is no output schema it leaves the full return shape and non-active outcomes unspecified. An agent can invoke the tool, but may not know how to interpret a response that is not 'active'.

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 0%, so the description carries the burden for the single parameter. Saying 'order #id' gives semantic meaning to the otherwise bare integer schema field, which is adequate for a one-parameter check tool.

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 clear verb-resource pair: 'Re-checks the chain for order #id and returns it', and the title ties it to checking whether a campaign payment landed. It is specific enough to understand the tool's purpose, though it does not explicitly contrast it with sibling tools like ads_order or ads_orders.

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 title and 're-checks' imply this is for verifying whether a payment or order is live, but the description gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. An agent has to infer the appropriate context rather than being told.

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 destructiveHint=false, so the safety profile is covered. The description adds useful context: it requires Authorization Bearer JWT, is scoped to caller-owned campaigns, and includes board spots. It does not describe pagination, error behavior, or response shape, but the annotations lower the burden.

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

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

A single sentence that front-loads the core scope ('Every Rokha Ads campaign the caller owns'), then adds the key inclusions and the auth requirement. No filler or redundancy.

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

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

For a parameterless, read-only list tool, the description covers scope, auth, and the fields returned. It does not specify response format or pagination, and there is no output schema, but the description is sufficient for an agent to invoke it correctly.

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

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

The tool has zero parameters and the schema is empty, so there is nothing for the description to clarify. The description appropriately focuses on the result contents instead, which matches the baseline for a parameterless tool.

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 resource: every Rokha Ads campaign the caller owns, including board spots, and lists the returned fields. The verb is implicit ('every campaign' implies a list/retrieve operation), and the plural scope distinguishes it from the singular ads_order sibling, though no sibling is named 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 gives no guidance on when to use this tool versus alternatives like ads_order or ads_campaign_update. It implies use when the caller needs their own campaigns, but it does not state exclusions or point to a sibling for different needs.

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

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

Annotations only indicate non-read-only and non-destructive. The description goes far beyond that: it explains payment mechanics (send EXACTLY pay_exact_usdc from the funder wallet), the king-of-the-hill hold behavior, non-expiry until outbid, the 'purchase not deposit' nature, and the Authorization requirement. It also warns that shielded holders cannot be outbid until shield_until. This is exceptional behavioral disclosure for a financial action.

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

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

The description is long and uses attention-grabbing caps, but nearly every sentence adds operational value: pricing, alternatives, payment flow, behavior, and auth. The most important call-or-not call information is front-loaded. It could be tightened, but it is not padded.

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 no output schema, the description carries the burden of explaining return value and post-call behavior, and it does: it returns the bid plus payment instructions including pay_exact_usdc, house_wallet, and a Solana Pay URI. It also covers authentication, the prerequisite read-board step, and what happens once payment lands. Nothing essential is missing for a payment tool of this complexity.

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

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

Schema coverage is 90%, so the baseline is 3. The description adds meaningful context beyond the schema: amount_usd means whole USDC at or above the take price, slug can be left empty to derive a word, tier maps to PLANET/MOON, and when is the agent-matching trigger. It does not add detail to every optional media parameter, but the schema already covers those.

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

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

The description uses specific action verbs ('Place a bid', 'buy yourself onto') and names the exact resources (AdSpace board, PLANET/MOON spots). It distinguishes from sibling tools by explicitly comparing with ads_order for ORBIT and clarifying that adspace_board is not a callable tool. An agent can tell exactly what this tool does without opening the schema.

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

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

The description gives explicit when-to-use guidance: bid for held PLANET/MOON spots, and use ads_order for the ORBIT weekly ring instead. It also instructs the agent to read the board first via a public GET endpoint and explains how to determine the required price using next_min_usdc or take_usdc. This is strong routing behavior relative to siblings.

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 mark this as destructive, and the description reinforces that by saying the bid is 'Dropped' and 'cancelled'. It adds useful behavioral context: only unpaid bids can be cancelled, paid bids are decided by the board, and an Authorization Bearer JWT is required.

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

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

Three short sentences with no filler. The core action is front-loaded, followed by an important constraint and the auth requirement. Every sentence earns its place.

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

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

For a simple one-parameter destructive tool, the description covers the target, the precondition, the boundary on paid bids, and auth. It does not describe the result or side effects beyond cancellation, but given the simplicity and the destructive annotation, this is nearly 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 only provides 'id' as an integer with no description, and schema coverage is 0%. The description implies that 'id' refers to one of the caller's unpaid bids, which adds some meaning, but it does not explain how to obtain this id or what happens if it is invalid.

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 ('Drops') and resource ('one of the caller's bids that is still awaiting funds'), making the operation unmistakable. It also distinguishes the unpaid-bid case from paid bids, which are handled by the board, helping differentiate this from related bid 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?

It clearly states when to use the tool: for the caller's own bids that are still awaiting funds. It also gives an explicit exclusion: paid bids are not cancelled here. It does not name a specific alternative tool, but the when/when-not guidance is clear enough.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds value by disclosing the requirement for Authorization: Bearer <JWT>, indicating that it re-checks on-chain data, and explaining the significance of the 'standing' status. 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?

The description is three short sentences with all essential info front-loaded: the action, the timing, the status meaning, and the auth requirement. No redundant words or filler.

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

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

For a single-parameter read-only tool with no output schema, the description covers the purpose, when to call, auth, and the key status value. It does not enumerate all possible statuses or the return format, but for a minimal check tool this is likely sufficient. There is no output schema to rely on, so a slightly richer description of possible statuses could improve completeness.

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

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

The input schema only documents an integer 'id' with no description (0% coverage). The description refers to 'caller's bid #id', which maps the parameter to a bid identifier and gives it meaning, but it does not provide detailed semantics like where to obtain the id or any constraints. This partially compensates for the absent schema description.

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 ('re-checks') and resource ('the chain for the caller's bid #id') and clarifies the output ('current status'). It also defines the meaning of 'standing', distinguishing this status-check tool from related bidding tools like adspace_bid or adspace_bid_cancel.

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

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

The description explicitly gives a timing instruction: 'call after sending the exact amount.' This tells the agent when to invoke the tool. It does not explicitly name sibling alternatives, but the context of checking a specific bid's payment status makes the intended use clear; exclusions are not stated, so not 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 destructiveHint=false, so the description doesn't need to restate safety. It adds valuable behavioral context beyond structured data: the status vocabulary (awaiting_funds, standing, bumped, missed, refunded, cancelled), the 'exact amount still to pay', the placement id condition, and the Authorization: Bearer JWT requirement.

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 dense sentence that front-loads the core purpose ('Every bid the caller has placed, newest first') and efficiently packs in status meanings, amount due, placement id condition, and auth requirement. Every clause earns its place with 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 zero-parameter, read-only listing tool with no output schema, the description fully covers what the caller will receive (status, amount due, placement id), ordering, and authentication. Nothing essential is missing for correct invocation and interpretation.

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

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

The input schema is empty (0 parameters), so there are no parameter semantics to document. Baseline 4 applies, and the description correctly focuses on output behavior instead of 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?

The description opens with 'Every bid the caller has placed, newest first' – a specific, scoped read operation on the caller's own bids. It enumerates returned fields (status, amount, placement id) and distinguishes itself from siblings like adspace_bid (placing a bid) and adspace_bid_cancel (cancellation).

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

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

Clear context is provided: this is for viewing the caller's own bids, with explicit scoping ('caller has placed') and ordering ('newest first'). It doesn't explicitly name alternative tools or state when not to use it, but the sibling list makes the differentiation obvious.

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

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

Annotations only indicate non-read-only and non-destructive. The description goes far beyond: it explains authority and billing for tools, read-only restrictions for visitors on public personas, forced model behavior with loud refusal rather than silent downgrade, and prerequisites. This is exactly the kind of behavioral context an agent needs and the annotations do not supply.

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 long but every clause carries operational detail—mode behavior, authority, billing, public/private semantics, locked model handling, and prerequisites. It is front-loaded with the core toggle and then systematically expands, so the length is justified and nothing is redundant.

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

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

For a tool with no output schema and nested parameters, the description covers the key decisions: what agent_mode changes, how agent_public affects visibility, what locked model behavior is, and the auth/claimed-page prerequisites. It does not mention return values or generic error handling, but the operational context is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, and the schema descriptions are already rich. The description adds further meaning about runtime implications—e.g., that agent_config.locked forces the model on every runner and that agent_public exposes the persona to any logged-in caller. This goes meaningfully beyond the schema, earning a 4.

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: 'Toggle the CALLER's account into (or out of) SUB-AGENT mode (Agent Creation B0).' It names the concrete effects and distinct endpoints, making the tool's function unambiguous and clearly differentiated from any sibling tool that manages accounts or pages.

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

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

While it does not explicitly name alternative tools or state when-not-to-use, it gives strong contextual signals: it requires a claimed page and an Authorization header, and it describes the exact behavioral switch. This is enough for an agent to infer when to use it, though explicit exclusions would have made it stronger.

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 destructiveHint=false, and the description adds useful behavioral context: it is rendered from the snapshot's stored card, is not a re-run, is informational, does not affect Tailwind scoring, and requires no auth. This meaningfully supplements the annotations without contradicting them.

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 long and uses emphatic capitalization, but it is front-loaded with the core purpose and every listed detail about the audit contents is decision-relevant since there is no output schema. The structure is readable and the verbosity is justified by the absence of structured return documentation.

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

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

For a one-parameter read-only tool with no output schema, the description is nearly complete: it explains the input, return contents, auth requirements, and informational nature. The only notable gap is what happens when no audit is on file for the given handle, but that is a minor edge case.

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

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

Schema coverage is 0% and the only parameter is a bare string `who`. The description compensates by defining it as 'an X handle,' which is essential semantics. It would benefit from specifying formatting (e.g., with or without @), but for a single parameter the description provides enough meaning.

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 precise statement: 'THE LAST AUDIT ON FILE FOR AN ACCOUNT, IN FULL.' It clearly names the resource (a stored audit snapshot), the input (an X handle), and distinguishes this from a re-run or live audit. This is a specific verb-plus-resource statement that separates it from sibling tools like x_account_audit.

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 it should be used by saying 'not a re-run' and noting audits are informational and do not change Tailwind scoring since 2026-09-24. However, it does not explicitly name an alternative or state 'use x_account_audit for a fresh audit.' The 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.

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

Discloses the side effect that an approved token lands in the vault under an alias, explains the handshake behavior for server_url, and states the prerequisite of a logged-in identity—all beyond the minimal 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?

Four sentences, each carrying distinct information, with the main purpose front-loaded. No redundant phrasing.

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

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

With no output schema, the description covers the return value (consent URL, alias), the post-approval behavior, and the prerequisite. It is fully sufficient for an agent to invoke the tool correctly.

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

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

Adds a complete enum-like list of valid providers and explains the semantic difference between provider and server_url, which is not present in the schema. Also clarifies that the returned alias identifies the stored token.

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 ('Start an OAuth Connect') with a clear deliverable (consent URL), lists the exact provider set, and contrasts provider vs server_url modes. This makes it distinguishable from sibling auth tools like auth_connections/auth_resolve.

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?

Provides clear context for choosing between provider (account-wide, reused everywhere) and server_url (any MCP server, grant bound to that server), and notes the logged-in identity prerequisite. It doesn't explicitly name sibling alternatives or state when not to use, but the guidance is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond the annotations by disclosing the authentication prerequisite and explaining that each connection exposes a vault alias usable via secret_refs on harnesses.

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 contain everything needed: the action, the resource, the additional providers content, a useful parenthetical example, and the auth requirement. No filler or redundancy.

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

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

For a zero-parameter, read-only listing tool, the description covers purpose, result contents, authentication needs, and downstream relevance via secret_refs. It does not enumerate the exact response shape, but the tool's low complexity makes the description sufficient for correct invocation.

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

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

There are zero parameters, so schema coverage is trivially 100% and the description has no parameter semantics to add. The baseline for zero-parameter tools applies, and the description still enriches understanding by explaining what a returned connection name represents (a vault alias attachable to harnesses).

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 the specific verb 'List' and names the resource ('OAuth connections'), then clarifies the response also includes providers available to connect. This clearly distinguishes it from sibling tools like auth_connect, which by name performs the connection action rather than listing state.

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 establishes clear context: it is a discovery/read operation for existing connections and connectable providers, and it requires a logged-in identity. It does not explicitly name alternatives or exclusion conditions, but the listing-versus-connecting role is implied strongly enough for an agent to choose it appropriately.

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 mark this as readOnly and non-destructive. The description adds useful behavioral context beyond that: 'Works without login' and 'Returns the one right next step', making clear it is a classification/advice tool rather than an authentication action. No contradiction exists.

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

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

Two dense sentences carry all essential information: what the tool classifies, the possible outputs, the nature of the response, and the no-login requirement. There is no filler or repetition of schema content.

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

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

Given there is no output schema, the description compensates well by naming the exact classification categories and stating that it returns the next step. It could specify the output representation more explicitly, but for a single-input classification tool the description is sufficiently complete for correct selection and invocation.

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

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

Schema coverage is 100%, so the single server_url parameter is already documented. The description reinforces that the URL is an MCP server URL to classify, but it does not add format details or constraints beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('classify') and resource ('any MCP server URL'), then enumerates the four possible classification outcomes. It clearly distinguishes itself from action-oriented siblings like auth_connect and auth_connections by stating it 'returns the one right next step' rather than performing authentication.

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 context is clear: use this tool to determine how to authenticate a given MCP server URL, and it works without login. It does not explicitly name sibling alternatives or provide when-not-to-use conditions, so it falls short of a 5, but the intended trigger is strongly implied.

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

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

Annotations only carry readOnlyHint=false and destructiveHint=false, which is minimal negative information, so the description carries the behavioral burden. It discloses that the tool returns a challenge message (implying no state change at this step), that new wallets are 'auto-registered on first verify' (deferring side effects to the next step), and that a paid plan unlocks usage — pricing context an agent would not otherwise know. The two-chain supported behavior is also disclosed beyond the schema.

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

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

Three sentences, each earning its place: the first states the core action and return value, the second adds chain support and the successor tool, the third covers registration and billing implications. Core purpose is front-loaded. The pricing sentence is arguably secondary but is valuable behavioral context. No redundancy or filler.

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

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

For a simple 3-parameter tool with 100% schema coverage, no output schema, and thin annotations, the description covers what the tool does, what it returns (challenge message), the two supported chains, the required follow-up step, and the billing consequence. Minor gaps remain — challenge validity duration and return format details — but nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the schema already documents chain auto-detection, wallet_type defaults by address shape, and address formats. The description adds marginal reinforcement ('base58 Ed25519' vs '0x') that maps to wallet_address validation, but it does not add new parameter semantics the schema lacks. This is a fair baseline, not a bonus.

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+resource: it is 'Step 1 of registering (or logging in) a user with a wallet keypair' and returns 'a challenge message to sign with the wallet's private key.' It clearly distinguishes itself from the sibling auth_wallet_verify by positioning itself as the first step and explicitly naming the follow-up. Chain scope (Solana base58/Ed25519, EVM 0x) further tightens the purpose.

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

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

The description gives clear workflow context: 'Step 1' and 'Follow with auth_wallet_verify' tell an agent exactly when this tool fits in a multi-step flow relative to a named sibling. The 'no browser needed' line also differentiates it from browser-based auth flows. It does not explicitly state when NOT to use alternatives like auth_connect or auth_resolve, but the workflow framing is enough to route correctly.

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

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

Annotations only provide readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral detail: on success it returns a session_token JWT to be used as a bearer token, unlocks owner-scoped tools, and describes chain-specific signature formats. It doesn't mention failure modes or challenge expiry, but the main side effects are 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 dense but well-structured, front-loading the core purpose and flow before adding necessary chain-specific details. Every sentence carries useful information with 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?

Given no output schema and minimal annotations, the description covers the main call-token-usage loop, what the JWT unlocks, and signature requirements. It omits where challenge_id comes from and possible error/expiry behavior, but for a multi-chain auth tool it is largely 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?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains the 'signature' parameter (Solana Ed25519 base58/comma-separated bytes, EVM EIP-191 hex), but 'challenge_id' and 'wallet_address' are left implicit, relying on the challenge context and tool name for inference.

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

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

The description states a specific action, 'submit the signed challenge,' and ties it to finishing wallet registration/login while returning a JWT. This distinguishes it from sibling auth tools like auth_wallet_challenge (step 1) and other auth operations.

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

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

It explicitly positions itself as 'Step 2' in an auth flow, signaling use after the challenge step, and explains how to use the returned token on subsequent requests. It doesn't name the exact prerequisite tool or state when not to use it, but the step framing gives clear context.

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 destructiveHint=false, and the description adds useful behavioral context: 'Public, no auth' tells the agent no credentials are needed, and 'each read from its own source' signals per-account external reads. No contradiction with the annotations is present.

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

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

The description is dense with useful domain rules but is written entirely in uppercase with heavy jargon and a stream-of-consciousness structure. The core invocation guidance is front-loaded, yet the SPONSOR CARRY/COPIED/RULE ZERO sections add conceptual detail that could be more briefly organized for agent consumption.

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 one-optional-parameter, read-only tool with no output schema, the description covers invocation modes, auth requirements, and what kind of information the tool returns. It does not specify the exact return format, but that is less critical given the explanatory nature of the tool and the absence of an output schema.

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

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

The schema has one optional string parameter 'who' with 0% description coverage, so the description must carry the meaning. It does: 'With who (a Rokha or X handle) = that account's live boosts' clearly defines the parameter's format, optionality, and effect. It does not fully define 'Rokha' or specify accepted handle syntax, but it compensates well for the schema gap.

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 identifies the tool's resource as boosts/multipliers and distinguishes the bare full-menu mode from the per-account mode, so an agent can tell what it operates on. It lacks an explicit verb like 'explain' or 'list' in the description itself, relying on the name/title, and does not position itself against siblings such as seeds_explain.

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

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

The description gives clear invocation guidance: calling with no argument returns the full multiplier menu, while passing 'who' returns a specific account's live boosts read from their own sources. It does not explicitly compare against alternative tools, but the within-tool usage modes are concrete and actionable.

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

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

The description discloses the full behavioral impact: real money moves into escrow, approval must be OFF, the funder never wins, and the judging/payment process is automated. It goes far beyond the minimal annotations (readOnlyHint=false, destructiveHint=false) by explaining exactly what side effects occur and what the returned fund_sig represents.

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 detailed but well-structured: prerequisites first, then the action, then outcomes and constraints. Each sentence adds necessary context for a tool that moves real money. Slightly longer than ideal, but the density justifies the length.

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

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

Given the tool's complexity (5 params, no output schema, real-money implications), the description covers all necessary context: prerequisites, side effects, constraints, auth, and the returned receipt. An agent has everything it needs to call this tool correctly.

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

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

Schema coverage is 100%, so each parameter is already documented in the schema. The description adds contextual value by explaining how pot_usdc and deadline_minutes relate to the escrow and judging process, but it does not introduce new parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Post a bounty on the board' with real USDC, and distinguishes it from siblings like bounty_list and bounty_submit. It specifies the resource (playground bounties) and the verb (create/escrow), 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.

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

It provides explicit step-by-step prerequisites: first grant a USDC mandate via signet_grant with specific scoping, then call this tool. It also states constraints (pot size, deadline ranges, max open per account) and the auth requirement, giving clear when-to-use context without needing to consult alternatives.

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 mark readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable non-annotation context: 'Public, no auth' clarifies access requirements, and 'escrowed BEFORE they're listed' reassures about fund safety, going beyond what structured annotations provide.

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

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

The core listing information is front-loaded in the first sentence, and the parameter behavior is explained before the 'WIN ONE' digression. The section about winning is arguably tangential but provides useful workflow context; it is not bloated and every sentence adds relevant value.

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 no output schema, the description compensates by listing the returned fields: open bounties, entrants, deadlines, receipts, and per-id verdicts. It also states authentication requirements and a REST twin. Minor gaps like pagination or sorting are not critical for a small board tool, so it is reasonably 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 describes the 'id' parameter only as 'one bounty in full detail'. The description expands this with 'entry scores + Rokha's verdict once judged', telling the agent exactly what extra data arrives when id is passed. Since schema coverage is 100%, the baseline is 3; the added detail earns a 4.

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 'The playground's bounty board' and enumerates exactly what the tool returns: open bounties, entrants, deadlines, and paid receipts. It clearly distinguishes this read tool from sibling actions like bounty_create and bounty_submit by presenting it as the board to browse, not to mutate.

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

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

It explains the two modes: no id lists the board, passing id retrieves full detail. It even routes winning actions to playground_join and bounty_submit, giving context on how this tool fits into the wider workflow, though it does not explicitly state 'do not use this to submit or create.'

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

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

With only minimal annotations (readOnlyHint: false, destructiveHint: false), the description carries the full burden and delivers richly. It discloses the per-account/per-bounty limit, daily cap, payout mechanism to the Solana wallet, the role of trace_id as execution proof, and the disqualification rule for entries that try to instruct the judge. This goes well beyond what annotations provide.

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

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

The description is a single dense paragraph that front-loads the core action ('Submit your entry to an open bounty') and then packs in constraints, auth, and behavioral rules. Every sentence adds value, but it is somewhat long; a slight restructure (e.g., separating auth into its own line) could improve scannability without losing content.

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 4-parameter write tool with no output schema and minimal annotations, the description covers the essential operational details: purpose, required fields, optional fields with rationale, limits, payout, and auth. It does not describe the response format or error cases, but since no output schema exists and the tool's success is implied by the payout flow, this is a minor gap. Overall, an agent has enough to call it correctly.

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

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

The schema only describes trace_id and artifact_url; summary and bounty_id are bare. The description compensates by defining summary as 'a summary of what you actually did (20–2000 chars)' and clarifying trace_id as 'a `trace_id` you OWN on this platform (the receipt that proves execution)'. It also implies bounty_id refers to an open bounty. This adds meaning beyond the schema, though not exhaustive detail for every 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 opens with 'Submit your entry to an open bounty', a specific verb+resource that clearly distinguishes this from sibling tools like bounty_create (creating a bounty) and bounty_list (listing bounties). It also enumerates the key payload fields (summary, trace_id, artifact_url), 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.

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

The description gives clear context for when to use the tool: entering an open bounty. It also states important constraints ('One entry per account per bounty; 10 entries a day') and a prerequisite ('Requires Authorization: Bearer <JWT> from a Solana-wallet login'). However, it does not explicitly name alternatives or state when not to use this tool, which would push it to 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 destructiveHint=false, and the description adds meaningful behavioral context: it is public, requires no auth, returns third-party copy verbatim, and explicitly warns agents to quote it rather than treat it as instructions. It also explains the payout cadence and the broader earning workflow. No contradiction exists.

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 dense, all-caps paragraph with long parentheticals, promotional asides, and multiple stacked clauses. It front-loads the core subject but packs too much tangential detail into one block, making it harder for an agent to scan and extract the essential information 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?

For a no-argument, read-only briefing tool with no output schema, the description is comprehensive: it covers the brief content, sponsor ranks, payout rules, the X account proof flow, Solana payout address, Friday revenue split, the data-safety warning, and public/no-auth access. Nothing necessary for correct invocation is missing.

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

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

The tool has zero parameters and schema description coverage is 100% because the schema is empty, so parameter documentation is not needed. The description adds value by explaining what the returned brief will contain, which is the only meaningful semantic context for a no-argument tool.

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 that the tool provides the live Wall sponsors, their copy, links, images, X handles, and the payout rules, so an agent can tell it is a read-only promotional briefing. It lacks an explicit action verb like 'lists' or 'returns' and does not differentiate itself from sibling tools such as adnet_feed or wall_mcp_publish, so it falls short of a 5.

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

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

The description gives strong contextual usage guidance: it positions this as 'the earning half of Rokha,' explains when to promote a sponsor from a proved X account, and references x_link_start/x_link_verify for account proof and GET /api/promo/topics for the full topics brief. It does not explicitly state when not to use the tool or compare it to sibling ad/ads tools, so it is not fully explicit.

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 a mutation (readOnlyHint=false) but give no deeper behavioral detail. The description adds significant context: harnesses are persistent context memory, the call can also create RIG steps, and it explains model_policy semantics including the 'required' mode refusing to run and emitting model_unavailable, plus the owner-API-key requirement for non-Haiku models. This goes well beyond the annotations.

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

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

The first sentence is front-loaded and clear, but the second sentence is a dense run-on cramming the full RIG-step JSON structure and model_policy semantics into one long parenthetical. It is information-rich but poorly structured; splitting it into shorter, labeled sentences would improve readability without losing content.

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

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

The description thoroughly covers input semantics and edge cases for model_policy, which is the complex part of this tool. However, with no output schema, it omits what the caller should expect in return (e.g., created harness object or success confirmation). It also fails to acknowledge or resolve the harness_type enum conflict, leaving an important ambiguity for a creating tool.

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

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

Schema coverage is 100% and parameter descriptions are generic ('Content/value of the harness'), so the description adds real value by explaining that content is a JSON config with specific fields (skill, instruction, endpoint, tool, params, etc.) and detailing model/model_policy behavior. However, it introduces a conflict with the schema: it says harness_type can be 'skill'/'instruction' for RIG steps, while the schema enum only lists persona/preference/strategy/knowledge/compliance. This is a notable inconsistency that could mislead an agent.

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, resource, and scope: "Create a new harness (persistent context memory) for a wallet." It also distinguishes this creation tool from siblings like update_harness, get_harness, and delete_harness by the action it performs. The additional RIG STEPS clarification further specifies what the tool can do, even though it introduces a schema mismatch.

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 — when creating a new harness or a RIG step — and gives detailed configuration guidance for model_policy. However, it never explicitly contrasts create_harness with update_harness or says 'use this when creating, not when modifying.' The usage context is clear enough to be inferred, but there are no explicit exclusions or alternative routing.

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

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

Annotations already convey that this is a write operation that is not destructive. The description adds only the Rokha task-system context and the fact that a new task is created; it does not disclose auth requirements, failure modes, duplicate handling, or what the tool returns.

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 with no filler. Every word adds context, and it is appropriately sized for a simple creation tool.

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

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

For a simple 3-parameter creation tool with a complete schema and consistent annotations, the description is minimally adequate. The main gap is that there is no output schema and the description does not mention what the caller can expect back after creation.

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

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

Schema coverage is 100%, so all three parameters (name, description, priority) are already documented. The description adds no parameter-level detail, which is acceptable because the schema carries the full burden.

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 clear action (create), a clear object (a new task), and the domain (Rokha task system), so an agent can understand what the tool does. However, it largely restates the title and does not explicitly distinguish itself from sibling task-related tools like get_task_status.

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

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

The intended use is implied clearly: call this when you need to create a new task. There is no explicit guidance about when not to use it, prerequisites, or alternatives, so an agent must infer the full usage context.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, covering the destructive nature. The description adds no further behavioral context (e.g., permanence, cascading effects, auth requirements). Since annotations carry the safety profile, the description's minimalism is acceptable, though it could note irreversibility.

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

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

The description is a single sentence with no redundant words. The action verb 'Delete' is front-loaded, making the purpose immediately obvious. This is appropriately concise for a simple delete 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 one-parameter delete operation with no output schema, the description combined with annotations and schema covers the essentials: what is deleted, how to identify it, and that it is destructive. It might benefit from stating the action is permanent, but the destructiveHint annotation already signals this.

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

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

Schema coverage is 100%: harness_id is described as 'UUID of the harness to delete', so the description adds no parameter-specific meaning beyond the schema. The baseline 3 applies given full schema 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?

The description states the verb 'Delete' and the resource 'harness', making the action clear. It distinguishes from sibling operations like create_harness and update_harness by its destructive verb, though it doesn't explicitly contrast them. The phrase 'by ID' correctly indicates the selection method.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The intended usage is implied by the name and sibling context (e.g., delete when you want to remove a harness permanently), but there is no mention of prerequisites, confirmations, or scenarios where it should not be used.

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 destructiveHint=false. The description adds rich behavioral detail: the distinction between radar items (pursuits) and LANDED items (real partnerships), the status meanings, and the explicit statement that this is public data with no auth. It also clarifies the data source equivalence. This significantly enhances agent understanding beyond annotations.

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

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

The description is lengthy but information-dense. It front-loads the core purpose, then details the milestones, statuses, filtering, and data equivalence. Every sentence contributes useful information, though the all-caps and formatting may reduce readability. It is structured logically and could be slightly trimmed without losing value, but it earns a strong score.

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 no output schema, the description thoroughly explains what data will be returned: the milestones, statuses, blurbs, WHY IT FITS, and links. It covers all parameters, their constraints, and the authentication requirement. For a read-only data retrieval tool, nothing essential is missing; an agent can call it correctly with full understanding.

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

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

Schema coverage is 100%, so both parameters (query and track) are already described. The description adds valuable semantics: it lists the valid track values, clarifies that prefixes work, and explains the query matching behavior with examples. This goes beyond the schema's basic descriptions, justifying 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.

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

The description opens with 'ROKHA'S FLIGHT PLAN — ONE MILESTONE MAP, AS DATA', clearly stating the tool's purpose as a read-only data retrieval tool for Rokha's roadmap. It enumerates the specific content (partnerships, pursuits, statuses, links) and distinguishes itself from other tools by its unique focus on roadmap data.

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 explains how to use the optional track and query parameters, and notes that the data is public and requires no auth. It does not explicitly mention alternatives or when to avoid this tool, but given its unique scope among siblings, the guidance is sufficient. A slight deduction for not explicitly stating when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a key behavioral detail: 'Requires login.' This is beyond annotations and is crucial for the agent to know. It doesn't mention other behaviors, but for a read-only listing, this is sufficient.

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, compact sentence that front-loads the core action ('List') and resource, then provides the return fields and the login requirement. No wasted words; every element earns its place.

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

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

For a zero-parameter tool with an output schema absent, the description is fully complete: it states what is returned, the login requirement, and the safety profile via annotations. There is nothing an agent needs in order to call it correctly that is missing.

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

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

The tool has zero parameters, and schema coverage is 100% as there are no properties to describe. With no parameters, the baseline is 4, and the description adds value by clarifying what the return fields are, making the output easier to interpret. This exceeds the baseline.

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

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

The description states a specific verb ('List') and resource ('servers registered behind your Rokha gateway'), and explicitly enumerates the fields returned (slug, URL, authenticating alias) and the gateway_url. It clearly distinguishes this from the sibling gateway_register, which is about registration.

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 usage context (listing gateway servers) but does not explicitly state when not to use it or mention alternatives. Given the sibling name gateway_register, it could have explicitly said 'for registering, use gateway_register instead,' but that is not critical for a listing tool.

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

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

Annotations only indicate non-read-only and non-destructive, so the description carries the behavioral burden. It adds meaningful detail: credentials are injected server-side, tools become namespaced, secret_alias maps to a vault key/OAuth grant, open servers are allowed by omitting it, and a logged-in identity is required. This goes well beyond the annotations.

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

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

The description is compact and front-loaded with the core purpose. The additional sentences about namespacing, secret_alias, authentication, and the cap are all relevant and non-redundant. It could be slightly tighter, but every sentence earns its place.

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

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

For a registration tool with no output schema, the description covers the essential operational context: what registering does, how credentials are handled, the auth requirement, and the cap. It does not describe the return value or duplicate/cap-exceeded behavior, but the provided context is sufficient for an agent to invoke it correctly in most cases.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining that the registered server's tools will appear as <slug>_<tool> and clarifying that secret_alias names a vault key/OAuth grant and can be omitted for open servers. This supplements the schema rather than merely repeating 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 opens with a specific verb and resource: 'Register an external MCP server behind your Rokha GATEWAY.' It clearly distinguishes this from listing tools like gateway_list by explaining the registration effect: the server's tools become namespaced as <slug>_<tool> on the gateway endpoint.

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

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

The description gives clear context for when to use the tool: when you want an external MCP server exposed through the Rokha gateway with server-side credential injection. It also notes the logged-in identity requirement and the cap of 20, which helps an agent decide whether this is the right action. It does not explicitly name alternatives or exclusions, but the context is strong enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context (e.g., return format, error handling, auth requirements). It simply restates the purpose. Since annotations cover the main behavior, a 3 is appropriate.

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, clear sentence with no filler. It front-loads the verb and resource. Perfectly concise.

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 getter with one parameter and annotations covering read-only safety, the description is adequate. It states the core action but does not mention return value or potential errors, which are not covered by output schema (none exists). Given simplicity, this is complete enough, but could be marginally richer.

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

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

Schema coverage is 100% with the parameter described as 'UUID of the harness'. The description's phrase 'by ID' adds no new meaning beyond the schema. It does not elaborate on format, requiredness, or behavior. Baseline 3.

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

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

The description clearly states the action (get) and the resource (a specific harness by ID). It distinguishes from list_harnesses and search_harnesses by specifying 'specific... by ID', making it clear it retrieves one harness.

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 usage when you have a harness ID, but does not explicitly state when to use this vs alternatives like search_harnesses or list_harnesses. No exclusions or alternative references are provided.

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 destructiveHint=false, so the read-only safety profile is covered. The description adds no additional behavioral detail such as return shape, error behavior, or polling semantics, but it does not contradict the annotations.

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

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

The description is a single front-loaded sentence with no filler or redundant elaboration. Every word contributes to understanding the tool's purpose.

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

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

For a one-parameter, read-only lookup, the combination of description, schema, and annotations covers the essential invocation information. The only notable gap is that the exact structure or possible values of the returned status are not described, and no output schema is present to fill that gap.

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

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

Schema description coverage is 100%; task_id is already described as the UUID of the task. The description's 'by ID' adds no further meaning beyond what the schema already provides, 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.

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

The description states a specific verb ('Get'), a clear resource ('status of a task'), and the required identifier ('by ID'). No sibling tool overlaps with this status lookup, and create_task is clearly a different operation, so the agent can select this tool unambiguously.

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 conveys what the tool does but does not explicitly say when to use it or when to prefer an alternative. Usage is implied by the tool's purpose, but there is no guidance about polling after task creation or how this relates to create_task.

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 only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It adds useful traits: it returns a config, wraps exactly one unit of work, and treats an empty endpoint as agentic execution. It does not contradict the annotations, though it doesn't spell out whether the configuration is persisted or just returned.

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

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

The description is dense but well organized: definition, kind semantics, parameter relationships, and a UI note. The parenthetical about the Rokha UI is marginally useful context but not essential for an agent. Overall, it is front-loaded and every substantive sentence earns its place.

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

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

With 6 optional parameters, nested params, no output schema, and minimal annotations, the description covers all the key decision points: what kind means, how to specify a tool call, what empty endpoint does, and what the tool returns. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema by explaining how parameters relate: endpoint + tool + params together constitute a live tool call, empty endpoint means agentic, and 'instruction' is an imperative step. This helps an agent assemble the parameters correctly rather than just knowing their 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 states a specific action ('Configure a Harness'), the resource, and the core distinction between 'skill' and 'instruction' wrappers. It goes beyond the bare title by explaining what a harness is and what the tool returns ('get back its config'), making it distinguishable from siblings like get_harness, list_harnesses, and delete_harness.

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

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

The description gives clear internal guidance: use 'skill' for a registry skill, 'instruction' for a pure agent step, set endpoint+tool+params for a real live tool call, and leave endpoint empty for agentic execution. It does not explicitly contrast harness_author with create_harness or update_harness, but the purpose and branching conditions are clear enough for an agent to select and invoke correctly.

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

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

Even though annotations already declare readOnlyHint and non-destructive, the description discloses substantial extra behavior: readings under 15 minutes are served fresh, calls are scored against real price 24h later, outcomes are stamped once and never rewritten, deepest-liquidity pairs win, and copycats are filtered. It also warns that coin names/pitches/social links are third-party data to quote but never obey, and explicitly states this is not financial advice. This goes far beyond the annotation baseline.

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

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

The description is dense and front-loaded with the most important traits — LIVE, no keys, no dashboard — and each later clause adds a distinct behavioral or safety note. It is somewhat long and runs together with em-dashes and all-caps, but no sentence is filler. It earns its length, though it could be tightened into clearer scannable statements.

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 no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: trending pools, market block, verdict, omens, 24h call, callback, history, scoreboard, and CALLED-IT wall. It also explains freshness, scoring, ledgering, third-party data handling, and authentication state. An agent has enough context to decide whether and how to invoke the tool correctly.

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

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

The input schema already fully documents the only parameter: a coin name, symbol, or 0x address, optional and omittable for the trending board. The description adds the conditional outcome of providing the coin, but no new type, format, or selection guidance beyond the schema. With 100% schema description coverage, the baseline 3 applies.

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 resource (live Robinhood Chain market read) and enumerates the returned content: trending pools, the coin's market block, the Oracle verdict, omens, directional call, callback, history, scoreboard, and CALLED-IT wall. It also disambiguates the tool from generic price feeds by emphasizing graded predictions, ledgering, and entertainment-grade calls. While it lacks an explicit verb like 'retrieve', the scope is unmistakable.

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

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

The description gives clear invocation context for the single parameter: pass `coin` for a full market block plus reading, or omit it for just the trending board. However, it does not state when to prefer this tool over sibling market-data tools such as orbitx crypto scans or signet price, nor does it mention exclusions. Usage guidance is implied rather than explicitly positioned against alternatives.

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 annotations (readOnlyHint: false, destructiveHint: false), the description discloses critical behavioral traits: returning a secret hook URL, firing the rig on POST with the body as input, consuming the daily run budget with fail-closed behavior, a 6-fires/minute rate limit, security consequences of URL exposure, revocation via delete, and a 10-hook account cap. This is exceptionally transparent.

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

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

The description is dense yet efficient, with every sentence adding necessary operational or security detail. It is front-loaded with the core purpose and output, then systematically covers budget, rate limiting, security, auth, and limits. No fluff or repetition.

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

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

Despite having no output schema, the description states the key return value (a secret hook URL) and fully explains the hook's behavior, side effects, limits, and security model. An agent has enough context to correctly invoke the tool and handle the result without additional documentation.

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

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

The schema already covers both parameters fully (rig_id as UUID of the saved rig, rig_name as optional display name), so the description does not need to add much. The description adds useful context about how the POST body becomes run input, but this is behavioral rather than parameter-specific. With 100% schema coverage, 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 begins with a specific verb and resource: 'Create a WEBHOOK TRIGGER for a SAVED rig.' It clearly differentiates this from sibling tools like hook_delete, hook_list, and hook_pause by focusing on the creation action and the resulting secret URL.

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

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

The description clearly implies when to use it: when an external system needs to trigger a saved rig via HTTP POST without polling. It also states a key prerequisite (logged-in identity with Bearer JWT). It does not explicitly mention alternatives or exclusions, but the webhook-specific context and required auth make the usage scenario unambiguous.

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

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

Annotations already mark this as destructive, but the description adds meaningful specifics: the secret URL is revoked, outside systems posting to it get 404, and the rig itself is untouched. This goes well beyond the structured annotations and sets accurate expectations for an irreversible action.

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

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

Three compact sentences deliver the action, the consequence, and the prerequisite with no filler. The most important operational effect (REVOKES the secret URL) is front-loaded.

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

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

For a single-parameter destructive tool with no output schema, the description covers authorization, ID source, and post-delete external behavior. It does not address the hook_pause alternative or behavior for nonexistent IDs, but these are secondary to correct invocation.

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

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

The schema already fully describes hook_id as a UUID at 100% coverage. The description adds practical value by saying the id comes from hook_list, telling the agent how to obtain a valid value for 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 opens with 'Delete one of your webhook triggers by its hook id (from hook_list),' which names a specific verb, resource, and scope. It also differentiates itself from siblings like hook_pause by explaining that the secret URL is revoked, not merely disabled.

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

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

It provides useful context: the hook id comes from hook_list and a logged-in identity is required. However, it does not explicitly mention hook_pause as the reversible alternative, nor does it state when deletion is preferable to pausing, so the when-not-to-use guidance is left implied.

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 destructiveHint=false, so the safety profile is covered. The description adds value by specifying the authentication requirement and detailing the output fields, including the enum for last fire verdict (ok | partial | error | skipped_budget). This is meaningful behavioral context beyond the annotations, though it does not discuss pagination or error handling—minor gaps for a simple list operation.

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

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

Two sentences with no filler. The core purpose is front-loaded, followed by the field list and the auth requirement. Every word adds value, and the structure is efficient for an agent scanning 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?

Since there is no output schema, the description must explain what the tool returns—and it does, listing all expected fields and the verdict enum. The auth requirement is also included. For a read-only list tool with no parameters, this is complete: an agent knows exactly what to expect and what precondition must be met.

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

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

The tool has zero parameters, and schema coverage is 100% (empty properties). The description correctly avoids inventing parameter details. Per the baseline for 0 params, a score of 4 is appropriate; there is nothing to compensate for since no parameters exist.

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

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

States a specific verb ('List') and resource ('webhook triggers'), and enumerates the returned fields (secret hook URL, bound rig, enabled state, fire count, last fire verdict). This clearly distinguishes it from hook_create, hook_delete, hook_pause, etc. The purpose is unambiguous and action-oriented.

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

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

The description gives clear context for when to use this tool—to list your webhook triggers—and adds a prerequisite ('Requires a logged-in identity'). It does not explicitly name alternatives or when-not-to-use conditions, but the operation is self-explanatory and sibling tools (hook_create, hook_delete, hook_pause) are distinct enough that an agent can infer when this is appropriate. Missing explicit exclusions, hence not 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 only indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context: paused hooks retain their URL, all posts are refused until resumed, and authentication is required. This goes well beyond the annotations and clarifies the reversible, non-destructive nature of the operation.

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

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

The description is two sentences with no wasted words. It front-loads the action, then provides the essential behavioral consequence and auth requirement in the second sentence.

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, no-output-schema tool, this description is complete: it states ownership, reversible behavior, the effect on incoming posts, and the auth prerequisite. Nothing an agent needs to correctly select and invoke the tool is missing.

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

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

The input schema already documents both parameters fully: hook_id is the UUID of the webhook trigger and paused is a boolean with 'true to pause, false to resume'. With 100% schema coverage, the description wisely does not repeat parameter details, so baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Pause or resume one of your webhook triggers') and explains the defining behavior: a paused hook keeps its URL but refuses posts. This also distinguishes it from hook_delete, since the URL is preserved rather than removed.

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

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

The description gives clear context for when to use the tool: on 'your webhook triggers', with the behavioral consequence of pausing and a logged-in identity requirement. It does not explicitly name alternatives like hook_delete or state 'use this instead of deleting', 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 destructiveHint=false, but the description goes far beyond that by disclosing the scoring formula, caps, daily best-5 rule, exclusions (model verdict, profile bonus), and the return format. It also clarifies it's public with no auth, adding substantial 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 long but every sentence adds concrete detail: the scoring weights, caps, daily best-5, exclusions, return shape, and public access. It's front-loaded with the core purpose and follows a logical flow from computation to returns. No wasted words.

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

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

Given the tool has only one parameter, no output schema, and is a read-only computation, the description fully explains the algorithm, the return values (total, per-post breakdown, explanation), and the scope. An agent has everything needed to invoke it correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3. The description reaffirms the handle is an X or page handle and explains its purpose, but it adds little beyond what the schema already states (e.g., format or example). It doesn't introduce new parameter semantics.

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 ('justify') and resource ('board seat') and clearly explains what it does: compute per-post seed arithmetic for a given handle. It distinguishes itself from siblings by emphasizing it returns counts only, no model verdict, and no profile bonus, which sets it apart from tools like seeds_explain.

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 it by detailing its scope (arithmetic, counts only, no model verdict) and notes it's public and auth-free. However, it does not explicitly name alternative tools or state conditions for when not to use it, 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 destructiveHint=false, so the safety profile is covered. The description adds the concept of harnesses as persistent context memories, which is useful context. However, it doesn't disclose default ordering, pagination behavior, or what happens when no harnesses exist. With annotations covering safety, a 3 is appropriate.

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

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

Two sentences with zero waste. The first sentence states the action and scope, the second defines the resource type. The wallet_address auth note is in the schema where it belongs. Every sentence earns its place.

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

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

Complete for a read-only list tool with 100% schema coverage and annotations covering safety. The only minor gap is not describing return format or pagination, but for a simple list tool with no output schema, the description plus schema is sufficient. The sibling list shows search_harnesses exists, so an agent might wonder when to use which, but the description's definition of harnesses helps.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the wallet-address scoping context ('Owner scope. Over the public MCP door this is derived from your auth token') which is helpful, but doesn't add meaning beyond what the schema provides. Baseline 3 is correct.

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

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

The description states a specific verb ('List') and resource ('harnesses for a wallet address'), and defines what harnesses are (persistent context memories: personas, preferences, strategies, knowledge, compliance). This clearly distinguishes it from siblings like get_harness, search_harnesses, create_harness, and delete_harness.

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 this is the listing tool for harnesses scoped to a wallet address, and the schema notes the wallet_address is derived from auth token over the public MCP door. It doesn't explicitly name alternatives like search_harnesses or get_harness, but the context is clear enough for an agent to select it for listing all harnesses.

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 and destructiveHint annotations, the description explicitly discloses that only a masked preview is ever shown and that the tool never returns actual secret values. It also adds the authentication precondition and the scope of included credential types.

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

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

The description is compact and front-loaded, with each sentence adding a distinct piece of information: scope, output fields, masking guarantee, credential types, and auth requirement. No filler or restatement of the title.

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

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

For a zero-parameter, read-only list tool, the description fully covers what the agent needs to know: what the tool lists, what fields are returned, that values are never exposed, and that authentication is required. There is no output schema, but the description supplies the essential return expectations.

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

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

The tool has zero parameters and the schema is fully clear with no properties to describe. The description correctly avoids inventing parameter details, and the baseline for no-parameter tools applies.

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

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

The description clearly states the verb 'List' and the resource 'your saved keys & secrets', with concrete detail on what each entry contains: provider, ALIAS via secret_refs, and a masked preview. This distinguishes it from other listing tools by scoping it specifically to stored credentials.

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

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

The description gives clear context: it is for listing masked saved keys, covers pasted API keys, custom secrets, and OAuth grants, and requires a logged-in identity. It makes the 'when-not' explicit by stating it NEVER returns a value, though it does not name an alternative tool.

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 and destructiveHint=false, so safety behavior is covered. The description adds the 'current preferred' nuance, but does not disclose behavior such as what happens when no model is set or whether a default is returned.

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

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

The description is a single sentence with no filler. The verb and object are front-loaded, and every word contributes to understanding the tool's purpose.

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

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

For a one-parameter, read-only getter with full schema coverage, the description provides enough context to call the tool correctly. The only minor gap is that, with no output schema, it does not specify the return shape or unset behavior.

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 agent_name parameter is fully documented with examples. The description itself adds no parameter-level 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 uses a specific verb ('Get') and a specific resource ('current preferred LLM model') scoped to an agent. It is clearly distinguishable from the sibling tool llm_set_model, which implies writing rather than reading.

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 frames this as a read-only retrieval of an agent's model preference, which gives adequate context for when to invoke it. It does not explicitly mention alternatives or exclusion criteria, but the read-only nature and sibling setter make the usage context clear.

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

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

Annotations already convey the mutation profile (readOnlyHint=false, destructiveHint=false). The description adds behavioral nuance beyond those flags: the search is keyword-based rather than requiring an exact model ID, and any OpenRouter model is accepted. This helps the agent understand partial matching behavior and the valid value space.

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. The primary action is stated first, followed by actionable search examples and a succinct scope statement about OpenRouter. Every sentence earns its place.

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

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

For a two-parameter setter with no output schema, the description covers the essential call semantics: what it does, how to search, and what values are valid. It doesn't describe success/failure return behavior, but that's a minor gap for a simple set 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 coverage is 100%, so the baseline is 3. The description adds value by giving concrete query examples ('opus', 'claude-sonnet', 'gpt-4o', 'deepseek', 'llama') and clarifying that keyword/partial matching is acceptable, going beyond the schema's generic 'Model name or keyword to search for'.

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 action ('Set') and resource ('preferred LLM model for an agent'). The verb is specific and unambiguous, and the focus on setting (as opposed to the sibling llm_get_model's getting) distinguishes the tool without needing to open the schema.

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

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

The description gives concrete usage context: search by name or keyword, with realistic examples. It establishes when to call this tool (when an agent's model needs to change) but does not explicitly mention the sibling llm_get_model or state when not to use it. Clear context with no exclusions earns a 4.

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

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

With readOnlyHint=true and destructiveHint=false already provided by annotations, the description adds value by disclosing that the tool is public and requires no auth, and by explaining the measurement methodology: 'sampled follower counts with the timestamp they were read at, never a claim' and 'honest zeros are part of the pitch.' This gives the agent behavioral insight beyond the structured annotations, without contradicting them.

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 front-loads the main idea and layers purpose, usage, and auth in a logical order. However, it uses heavy stylistic formatting—caps, em-dashes, and jargon like 'the MCP door' and 'the Attention Board's seats and worth'—that makes it longer and more cryptic than necessary. Each sentence earns its place, but the wording is not efficiently plain.

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?

Since there is no output schema and zero parameters, the description carries the burden of explaining what the tool returns. It lists the major content categories: follower counts with timestamps, Attention Board data, active agents, carriers, and payouts with transaction signatures. It also communicates the tool's public/no-auth nature. While it does not detail exact response formatting or field names, it is complete enough for an agent to know what information this report provides.

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

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

The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. The description appropriately focuses on return contents rather than parameter syntax, since there are no inputs to document. No additional parameter meaning is 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 identifies the resource as network metrics ('THE NETWORK, MEASURED, BOTH DIRECTIONS') and enumerates the data it includes: sampled follower counts with timestamps, Attention Board seats and worth, active agents, carriers, and payouts with transaction signatures. It stops short of a plain 'Gets/Returns' verb and uses stylized phrasing, but an agent can infer it produces a network measurement report. It is distinguishable from siblings by its focus on provable, timestamped network data.

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 a clear usage context: 'Read this before quoting any number about Rokha's size,' which tells the agent when this report is the authoritative source. It also states 'Public, no auth,' clarifying that authentication is unnecessary. However, it does not name alternatives or exclusions (e.g., when to prefer adnet_report or adnet_stats), so it lacks the explicit routing seen in higher-scoring examples.

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 destructiveHint=false. The description adds useful context by saying calls are made through Orbitx's seat and that 'their data comes back as it is,' which sets expectations about data provenance and lack of transformation. The 'read-shaped tools only' note reinforces the read-only annotation without contradicting it.

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 core instruction is front-loaded and the read-only note is relevant, but the listing URL and Orbitx server marketing context are not needed for correct invocation. The description is compact enough, yet not every clause earns its place.

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

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

For a one-required-parameter read-only fetch with informative annotations, the description is largely complete. It identifies what the tool fetches, where the id comes from, and what kind of data to expect. No output schema exists, so a bit more detail on response structure could help, but 'data comes back as it is' mitigates the gap.

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

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

Schema description coverage is 100%, so the schema already explains the single 'id' parameter as a 'Document id from search.' The description repeats that idea but does not add materially new meaning, such as id format examples or how to obtain valid ids.

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

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

The description states a specific verb and resource: 'Fetch a document by id from search', and the parenthetical enumerates the accepted document categories. This differentiates it from sibling search tools and specialized getters by centering on a generic fetch-by-id operation.

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

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

The intended usage is implied: the tool is used after a search produces a document id, and the listed categories suggest what kinds of ids are valid. However, it does not name alternatives or give explicit when-to-use/when-not-to-use guidance relative to the many sibling get and search tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Read-shaped tools only (anything that buys, sells or writes refuses)' and 'their data comes back as it is', offering concrete behavioral context beyond the annotations. It clarifies the external hosting and raw data nature, which is valuable.

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 opening sentence is purposeful and front-loaded. However, the description includes extraneous context like 'Orbitx's MCP server, a live seat on The Wall (hosted by them).' and a URL to a registry listing, which aren't needed for tool invocation. It could be trimmed to the purpose and read-only enforcement without losing value.

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 it's an aggregator with no output schema, the description should clarify what to expect in response. It names the three payload types but not their structure or how they're combined. It also omits any mention of the authCode requirement, which is critical for usage. The basic purpose is clear but operational details are incomplete.

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 50% (authCode described, mint not). The description says nothing about the parameters themselves; it does not explain what 'mint' refers to or how to obtain/use authCode. The authCode is described in the schema, but the description adds no additional meaning for either 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 clearly states the tool is a 'one-shot aggregator' for 'safety + forensics + token payload for a mint', providing a specific verb (aggregate) and resource. It distinguishes from sibling tools like orbitx_get_safety or orbitx_get_forensics by combining them into one call, so an agent can select it correctly without seeing the schema.

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

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

The phrase 'one-shot aggregator' implies use when you need all three data types at once, but there is no explicit guidance on when to use this versus calling the specialized sibling tools separately, nor any exclusions or alternatives named. The read-only note is generic, not specific to this tool.

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 destructiveHint=false, so the safety profile is covered. The description adds 'Read-shaped tools only (anything that buys, sells or writes refuses),' which reinforces but does not exceed the annotations. It also mentions data 'comes back as it is,' which is vague and does not add significant behavioral detail beyond what annotations provide.

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

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

The description is front-loaded with the core purpose and trigger, but includes some fluff such as 'HIGH QUALITY' in caps and branding sentences ('Reso — Orbitx's MCP server...') that are not essential for tool selection. It is somewhat verbose but structured logically.

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

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

For a tool with no output schema, the description implies the output is an embeddable chart for chat, and the iframe parameter in the schema clarifies the HTML iframe behavior. It covers the main use case and trigger, though it could explicitly state the return format. Overall, it is fairly complete for a chart tool.

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

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

Schema description coverage is 86%, so parameters are well-documented in the schema. The description only references CA/mint in the trigger, adding no extra meaning beyond the schema's parameter descriptions. With high coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool provides a DexScreener embed chart for chat, and explicitly lists trigger phrases (chart, graph, DexScreener, candles). It distinguishes itself from sibling tools like orbitx_get_chart by specifying the 'embed for chat' use case, making the purpose unambiguous.

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

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

The description gives an explicit when-to-call instruction: 'When the user shares a CA/mint and asks for a chart, graph, DexScreener, or candles — call this immediately.' This provides clear context for usage, though it does not mention alternatives or exclusions beyond the trigger.

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?

It adds 'sticky' persistence, the live-seat/external-server context, and the warning that buy/sell/write operations will be refused—useful beyond annotations. It doesn't state undo behavior or what mode changes affect, and 'Read-shaped tools only' is in mild tension with readOnlyHint=false, though not a clear 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?

The purpose is front-loaded, but the description trails into a cut-off sentence ('until the —') and an unrelated server profile/listing URL. It reads like a template mashup rather than a clean, intentional tool description.

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

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

The description covers the trigger and follow-up, but it omits the semantics of name/slug, the exact duration of the sticky mode, and how to exit it. For a 3-parameter tool with no output schema, these are material gaps.

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?

Only authCode has a schema description; name and slug are completely undocumented. The tool description never mentions these parameters or how an agent should populate them, leaving a 33%-coverage schema without compensation.

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 first sentence states a specific action ('Enter sticky group-chat mode') with a clear resource, and the trigger phrase differentiates it from data-retrieval siblings like gc_list/gc_history. It doesn't explicitly name sibling alternatives, so it stops short of full differentiation.

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