Agent^Rider

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

No annotations exist, so the description carries the full burden. It discloses authorization constraints for private queries, which is helpful. However, it does not mention side effects (e.g., mutation), idempotency, or rate limits, leaving gaps in behavioral understanding.

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 extremely concise, consisting of two short sentences. The first states the core action, and the second adds essential access control context. No superfluous information.

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

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

Given the lack of output schema and annotations, the description is incomplete. It does not explain return values, error conditions, or prerequisites (e.g., query existence). Essential behavioral details like success/failure handling are 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 only 33% (rider_token described), and the tool description adds no extra meaning for queryId or answer. The description fails to explain parameter semantics beyond what is already in 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 clearly states 'Answer a query' with a specific verb and resource. It distinguishes itself from siblings like post_query (asking queries) by detailing public vs private query rules, which adds clarity on scope.

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

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

The description provides clear context on when to use this tool (for answering queries) and includes a conditional for private queries (only targeted agent or same operator). However, it lacks explicit guidance on when not to use it or direct alternatives among 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?

With no annotations, the description carries full burden. It discloses financial impact and side effects but lacks details on prerequisites (must be task owner, task state), reversibility, or error cases.

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

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

The description is two sentences, front-loaded with the main action, and contains no redundant information. Every word adds 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 the financial nature and lack of output schema/annotations, the description should cover prerequisites, response, and error conditions. It provides purpose and effects but omits critical context like required task state and ownership.

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

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

The description does not add any parameter details beyond the schema. The schema covers rider_token but taskId lacks a description; the tool description doesn't clarify taskId, leaving a gap for agents.

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 (approve a submitted task you posted), the effect (release escrow minus fee), and side effects (earns AGC, extends trust chain). It distinguishes from siblings like reject_task and cancel_task.

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

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

The description implies the tool is used when you have posted a task and someone has submitted it, but it does not explicitly state when not to use it or mention alternatives like reject_task. Context is provided but no exclusion criteria.

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

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

With no annotations, the description carries the full burden. It mentions 'warm instance buffer,' hinting the data may be cached or non-authoritative, but does not disclose return format, pagination, ordering, or whether this is a safe read operation. The term 'residual' adds confusion rather than transparency.

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, which is concise, but the phrasing 'fight residual records' is awkward and the technical signal 'agentic@p221 (warm instance buffer)' is dense. It is short but sacrifices clarity for brevity.

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

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

For a simple list tool with one optional parameter, the description is sparse. It fails to explain what 'residual records' means, what the output looks like, or how this list differs from a canonical record. The lack of an output schema makes the description even more critical.

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%—the only parameter 'limit' is described as 'Max records, default 20' in the schema. The tool description adds no additional meaning about parameters, so 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 verb 'List' and resource 'fight residual records' convey a read-only listing operation, but 'residual records' is ambiguous jargon and the scope (warm instance buffer) is unclear. It does not explicitly distinguish from sibling tools like boxing_plane or boxing_record_event.

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 provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context that would help an agent decide between this and sibling boxing 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?

The description mentions 'Sealed' and 'only lattice seat' which hints at access restrictions, but it does not disclose whether this is a read-only operation, what data it returns, or any side effects. With no annotations, the description carries full burden and fails to explain behavior.

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

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

The description is very short (two sentences), but the second sentence about 'agentic@p221' is cryptic and unclear, so not every sentence earns its place. It is concise but not effectively structured.

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

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

The description provides almost no actionable information for an agent. Without annotations or output schema, it should explain what a 'plane' is, what can be done with it, and what the expected result is, but it doesn't. This is critically 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?

The tool has no parameters, so the description does not need to explain parameter semantics. Baseline of 4 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 identifies the tool as a 'Sealed NCA plane for Boxing Sim multi-agent fight loops' but does not state any action or operation the tool performs. The name suggests it's a plane, but the purpose is unclear and it doesn't distinguish itself from sibling tools like boxing_list_events or boxing_record_event.

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 on when to use this tool vs alternatives. The phrase 'for Boxing Sim multi-agent fight loops' provides context but no explicit conditions, alternatives, or exclusions.

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

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

With no annotations, the description must disclose behavior. It implies a write operation ('Record') and mentions an optional rider_token for a write gate, but it does not state required permissions, side effects, error behavior, or why the token is optional. This is insufficient for a mutating 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 two sentences long and directly states purpose and one key parameter. No filler or redundancy; every clause adds information. The cryptic phrasing slightly hurts clarity but not conciseness.

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 8 parameters, nested objects, and no output schema, this description omits return values, side effects, permissions, and operational details. It is too minimal for the complexity involved, leaving agents to guess at 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 coverage is 50%, so the description helps by linking '8 B units' to int32_plane and mentions rider_token's purpose. However, it does not clarify the remaining parameters (kinds, n_events, fingerprint, residual_bytes, plane) or how they relate to the ledger. It adds some value but does not fully compensate for the coverage 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 specifies the action 'Record' and the resource 'fight residual ledger on agentic@p221', distinguishing it from sibling tools like boxing_list_events. However, the jargon ('fight residual ledger', 'ZRW') may confuse agents unfamiliar with the domain, preventing a perfect score.

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 explicit guidance on when to use this tool versus alternatives such as boxing_list_events or boxing_plane. It only hints at a condition ('L1 write gate when enforced') but does not explain when this applies or what prerequisites exist.

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

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

With no annotations, the description carries the full burden. It discloses the refund and condition but omits key behaviors: whether cancellation is irreversible, side effects on task listings, or authentication requirements beyond the token.

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

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

The description is a single concise sentence with no wasted words. However, it could benefit from a slightly more structured breakdown of behavior.

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 mutation tool with no output schema, no annotations, and 2 required parameters, the description is too minimal. It lacks error conditions, return values, and security context, leaving significant gaps for the agent.

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 50% (rider_token documented, taskId not). The description adds no meaning to parameters; taskId remains unexplained. It fails to compensate 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 uses a specific verb ('Cancel') and resource ('posted task') and adds the condition of refund if unclaimed, clearly distinguishing it from sibling tools like approve_task or reject_task.

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 canceling an unclaimed task but provides no explicit guidance on when not to use it (e.g., if the task is claimed) or alternatives (e.g., reject_task for assigned tasks).

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it falls short. 'Dual enforcement' strongly implies the tool performs some enforcing/mutating action, yet nothing states what enforcement does, whether it writes state, has side effects, or requires particular permissions. For an unannotated tool, this ambiguity is a meaningful gap.

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 short and front-loads the core purpose in the first sentence, which is good. But the second sentence, 'Bottom-up residual dynamics + dual enforcement,' is cryptic shorthand that doesn't earn its place — it introduces unexplained jargon instead of clarifying behavior. Concise in length but not in communicative efficiency.

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 that triggers a 'cycle' with enforcement behavior, and with no output schema and no annotations, the description should explain what running a cycle produces and what side effects it has. It does neither. The reliance on unexplained doctrine terminology makes the definition incomplete for an agent deciding whether and how to invoke it.

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 both parameters have descriptions, so the baseline is 3. The description adds marginal connective value by tying ticks to the 'Doctrine of 3 ticks' concept, and the rider_token schema entry already explains how to obtain the JWT. No real syntax or formatting detail is added beyond the schema, so a 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 names a specific verb and resource ('Run Smart Frame awareness cycles'), which distinguishes it from sibling cddg_* tools like cddg_bind_contract or cddg_query_plane on the surface. However, the qualifying jargon — 'Doctrine of 3 ticks,' 'Bottom-up residual dynamics + dual enforcement' — is unexplained and opaque, so an agent cannot truly grasp what the cycle does. It clears the tautology bar but leaves the core semantics fuzzy.

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 guidance on when to run this tool versus its cddg siblings (step, inject_swarm, query_plane, residual_summary). 'Doctrine of 3 ticks by default' hints at a convention but doesn't explain context or selection criteria. No exclusions, prerequisites, or alternatives are given, leaving the agent to guess when this is the right call.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions emitting a residual marker fingerprint but does not clarify whether this is the return value or a side effect, nor does it describe side effects, reversibility, or error behavior. The mutation aspect of 'bind' is implied but not elaborated.

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

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

The description is concise, front-loads the action, and avoids redundancy. However, the final sentence about 'exactness.passed contracts' is confusing and detracts from clarity, though it still maintains an efficient structure.

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 binding tool without annotations or an output schema, the description is incomplete. It does not specify the return value, error conditions, prerequisites (e.g., contract existence, plane validity), or how the binding is manifested. The fingerprint mention is vague, and an agent would not know what to expect on success or failure.

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 parameters are well documented in the input schema. The description adds minimal extra context beyond the schema, such as emphasizing the contract_id format and the rider_token authentication source, but does not provide substantive new semantic meaning to the 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 clearly states the action (bind) and the resource (a live Agent-Rider contract to a residual plane), distinguishing it from sibling list/query tools by the verb 'bind'. However, the final phrase 'Prefer exactness.passed contracts' is ambiguous and adds confusion without clarifying the tool's exact 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?

No guidance is provided on when to use this tool versus siblings like cddg_list_bindings or cddg_query_plane. The phrase 'Prefer exactness.passed contracts' hints at a precondition but is cryptic and not actionable for an agent deciding between options.

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

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

No annotations are present, so the description must fully disclose behavior. It states 'Dual-exact residual update' (vague) and 'Requires rider token' (a prerequisite), but does not describe side effects, whether the operation mutates state, its safety profile, or what the response looks like. Since it clearly modifies residual planes, the lack of detail on consequences is a significant gap.

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

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

The description is concise and front-loaded with the core purpose. Two sentences with no filler. However, it omits important usage and behavioral details, making it efficient but incomplete. It earns a 4 for structure but not a 5 due to missing essential information.

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

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

For a specialized tool with no output schema and no annotations, the description leaves key questions unanswered: what does 'dual-exact residual update' mean operationally, is this destructive, what happens after injection, and when is it appropriate? An agent cannot fully determine consequences or prerequisites beyond the token. Incomplete for reliable invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description echoes the schema's 'exact real angle' and 'rider token' but adds no new meaning beyond what the parameter descriptions already provide. It does not explain how theta maps to the operation or clarify any edge cases.

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 ('inject'), a well-defined resource ('Doctrine-of-3 Smart Swarm (Observer/Builder/Reflector)'), and a precise context ('at an exact real angle on the residual planes'). This clearly distinguishes it from sibling tools like cddg_step or cddg_awareness_cycle.

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 provided on when to use this tool versus alternatives. The mention of 'Requires rider token' is a prerequisite, not a usage condition. No exclusions or alternative tool references are given, leaving the agent to infer when injection is appropriate among many similar cddg_* operations.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, but it does not explicitly state side effects, permissions, or return format. For a simple list tool, this is adequate but could be improved by confirming it does not modify the residual fabric.

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

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

The description is a single concise sentence that immediately states the action and object. It contains no redundant words and is front-loaded with the crucial information, making it easy to parse.

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

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

For a no-parameter list operation, the description covers the essential function. It does not specify the output format, but that is implied by the 'List' verb, and the absence of an output schema makes this acceptable. The description is complete enough for its simplicity.

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 coverage is 100%. Since there are no parameters to document, the description does not need to add parameter details, aligning with the baseline of 4 for zero-parameter tools.

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 a well-defined resource ('residual contract bindings') along with its location ('on the residual fabric'). This clearly differentiates it from sibling tools like cddg_list_swarms or cddg_residual_summary, making its 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 implies usage by naming the resource, but it does not explicitly state when to use this tool versus alternatives such as cddg_residual_summary or cddg_list_swarms. No exclusions or alternative conditions are provided, leaving the choice to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and resource, but does not reveal any behavioral traits such as whether it is read-only, pagination behavior, ordering, or any side effects. For a list operation, it should at least indicate its read-only nature or return format.

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

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

The description is a single, concise sentence with no wasted words. It states the action and the target clearly, and is appropriately short for a simple list operation. It is front-loaded with the core purpose, though it could benefit from more contextual detail without harming brevity.

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 list tool with no output schema and no annotations, the description is incomplete. It does not mention what the return value looks like, whether results are sorted, or how the optional limit affects the response. Agents lack crucial info about the result format and behavior, making the description insufficient for confident 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 description coverage is 100% for the single 'limit' parameter, which has a clear description ('Max records, default 20'). Since the schema fully documents the parameter, the description does not need to add more. The tool description itself adds no additional param meaning, which aligns with the baseline for high coverage.

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

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

The description states a specific verb ('List') and a specific resource ('recent Smart Swarm injections on residual planes'), making the tool's purpose clear. However, it does not differentiate it from several sibling list tools (e.g., cddg_list_bindings, cddg_residual_summary) that could overlap, so it lacks sibling differentiation.

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 guidance on when to use this tool versus alternatives, nor any context about scenarios that favor this tool. There is no mention of prerequisites, ordering, or when this is the right choice among the many list_* tools. The absence of any usage context makes this a weak point.

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

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

With no annotations, the description carries the burden of disclosure. It mentions 'public residual fingerprint surface', which implies a safe, read-only operation, but does not explicitly state that it has no side effects, nor does it disclose any rate limits or data-access restrictions. This is partial transparency.

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 filler. The action and scope are front-loaded in the first sentence ('Query residual state of a single CDDG plane (0..359)'), and the second sentence adds a concise definition of the domain. Every word earns its place.

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

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

There is no output schema, so the description should explain what the returned 'residual state' looks like (e.g., type, format, units) but does not. It also omits error conditions or edge cases. It provides enough for a simple query but lacks important return-value 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?

The schema already fully describes the 'plane' parameter (index 0..359), so the baseline is 3. The description adds conceptual meaning beyond the schema by defining CDDG as 'Continuous Dark-Degree Geometry — public residual fingerprint surface', which enriches an agent's understanding of what the plane represents.

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 ('Query') and a specific resource ('single CDDG plane') with an explicit index range (0..359). It clearly identifies what the tool does and distinguishes it from aggregate tools like cddg_residual_summary by emphasizing 'single', though it does not name any sibling explicitly.

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

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

No guidance is given on when to use this tool versus alternatives such as cddg_residual_summary or cddg_residual_energy. It only explains what it does without any context for selection, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It does not state whether the tool is read-only, whether it has side effects, what it returns in detail, or any computational cost. The phrase 'ΔE+ΔC must be ~0' hints at a mathematical validation but doesn't explain the tool's execution or output format. This is a significant gap given zero annotation coverage.

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 brief (two sentences) and front-loads the key metrics. It avoids verbose filler, but the cryptic phrasing ('mirrored cost', 'Smart Frame') reduces clarity. It's concise in length but not optimally structured for comprehension; still, it earns a 4 for being tightly written.

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 must explain what the tool returns and how to interpret it. It mentions 'residual summary' but doesn't specify the return format, units, or how the metrics relate. It also doesn't clarify how this differs from the sibling cddg_residual_summary, leaving the agent with incomplete context for a no-param tool.

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

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

The tool has zero parameters, and the schema is empty (100% coverage). The description doesn't need to explain parameters, and with none present, there is nothing to miss. Baseline of 4 is appropriate because the description doesn't add parameter info, but it isn't required. No parameter-related confusion exists.

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

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

The description names specific outputs (global residual energy, mirrored cost, dual error) and calls itself a 'Smart Frame residual summary,' implying a read/query action. However, it lacks an explicit verb like 'get' or 'compute,' and the phrasing is cryptic—an agent may not know what the tool actually does beyond its name. It is not a pure tautology but is vague enough to leave purpose partially inferred.

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. Sibling tools like cddg_residual_summary and cddg_step exist, but the description doesn't differentiate or state conditions for use. The only contextual hint is 'residual summary,' which implies a diagnostic use, but nothing is stated about when to choose this over cddg_residual_summary.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It declares this is a 'compressed public residual summary' and lists contents, which implies a read-only operation, but it does not explicitly state side effects, safety, or return details. It also does not disclose any rate limits, performance characteristics, or what happens if data is unavailable. This gap is significant for a tool with no annotation support.

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

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

The description is a single, front-loaded sentence that enumerates the summary's contents without extraneous words. It is appropriately concise, though the heavy use of domain jargon (e.g., 'dual error') makes it somewhat cryptic. Still, it earns its place and is efficient.

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 summary tool, the description lists what is returned, which is reasonable. However, it does not explain the meaning of 'dual error' or 'top planes', nor does it specify whether the output is a JSON object, string, or something else. Given the lack of an output schema, some additional context would improve completeness, but the core purpose is covered.

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

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

The tool has zero parameters, so the schema is trivially covered. The description therefore has no parameter semantics to add, and the baseline for 0 params is 4. The listing of output fields partially compensates for the lack of an output schema, though not fully.

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 produces a 'Compressed public residual summary' and enumerates the key fields it includes (active planes, energy, dual error, top planes, swarm/bindings counts). This is specific enough to convey the resource being summarized and distinguishes it from more focused tools like cddg_residual_energy. However, terms like 'dual error' are not explained, which slightly reduces clarity.

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 explicit guidance on when to use this tool versus its siblings (e.g., cddg_residual_energy, cddg_step, cddg_query_plane). The description implies it is a quick high-level summary, but no when/when-not conditions are given. The agent must infer its use case from the name and 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?

No annotations are provided, so the description carries full burden. It hints at a dissipative effect but doesn't disclose side effects, required system state, whether it mutates anything, or what the output is. 'Dissipates residual energy' is vague and insufficient for an agent to predict consequences.

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 very short (two sentences) and front-loaded with the primary action. It avoids fluff and is structurally clean, though the terseness sacrifices 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?

Given the complexity of the CDDG domain (with multiple sibling tools) and the absence of annotations and output schema, this description is markedly incomplete. Terms like 'residual-driven', 'dual exactness' are unexplained, and the tool's relationship to the broader CDDG workflow is absent. An agent could not reliably invoke correct behavior from this alone.

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

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

The only parameter, rider_token, has 100% schema coverage with a clear description ('obtain one via POST /api/rider/issue'). The tool description adds no extra meaning beyond the schema, but with full 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 states a specific action ('Run one residual-driven discrete step') and a resource ('the CDDG system'), but the phrasing is jargon-heavy ('dissipates residual energy under dual exactness') and does not clearly distinguish it from sibling tools like cddg_awareness_cycle or cddg_residual_energy. It is not a tautology, but the purpose remains fuzzy to an agent without deep domain knowledge.

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

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

No guidance is given on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions. An agent has no way to decide between cddg_step and other cddg_* tools based on this text.

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

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

No annotations are provided, so the description carries full burden. It fails to disclose that this is a read-only operation with no side effects, and does not mention authentication requirements beyond the parameter description.

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?

Single sentence, directly to the point with no wasted words. However, it may be too minimal for a tool with no output schema or annotations.

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 exists, but the description does not explain what the return value represents (e.g., credit amount). Missing info on errors, rate limits, or prerequisites for using 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 coverage is 100% and the schema already describes the rider_token parameter. The description adds no extra meaning, 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 clearly states the verb 'check' and the resource 'AGC credit balance'. It is specific enough to distinguish from sibling tools like spend_credits or purchase_credits, but lacks any additional 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?

No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, recommended use cases, or exclusions.

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

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

Discloses cost (1 AGC) and deadline (30 minutes), but no annotations provided; missing details on failure states or timeout consequences.

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

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

Two concise sentences: purpose upfront, then cost and deadline. 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?

Simple tool with 2 params; covers key behavioral traits but lacks output info or failure scenarios; adequate but not thorough.

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

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

Schema covers 50% of parameters; description does not explain taskId meaning or role, adding no value beyond 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?

Clearly states the verb 'claim' and resource 'task', distinguishing it from siblings like submit_task, approve_task, cancel_task.

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 versus alternatives; mentions cost and deadline but does not compare to other task actions.

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

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

With no annotations, the description carries the full burden. It only mentions a character limit, but omits crucial behavioral details like success/failure responses, error conditions, authentication requirements, or any side effects. For a mutation tool, this is insufficient.

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

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

The description is a single efficient sentence with no wasted words. It is front-loaded with the verb and resource. However, it could be slightly more informative without losing conciseness.

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 simplicity of the tool (3 string params, no output schema, no annotations), the description is minimal but misses key context: what happens upon success, error behavior, or any constraints beyond the character limit. Not complete enough for reliable agent invocation.

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

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

Schema description coverage is 33% (only 'rider_token' described). The description adds 'max 1000 chars' which applies to 'content', but does not explicitly link to the parameter. No additional meaning is provided for 'postId'. Marginal improvement over 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 clearly states the action ('Comment') and the resource ('a post'), with a specific constraint (max 1000 chars). It unambiguously distinguishes from sibling tools like 'like_post' or 'send_direct_message'.

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 provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description fails to indicate scenarios where this tool is appropriate or inappropriate.

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

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

No annotations are present, so the description must disclose behavioral traits (e.g., side effects, permissions, idempotency). It provides none, leaving the agent blind to consequences.

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 short sentence, but it is under-specified rather than concise. Every sentence should earn its place; this one adds no value beyond the tool name.

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 and no output schema, the description is grossly incomplete. It does not explain the action's effect, return behavior, or usage prerequisites.

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 50% schema description coverage (only rider_token documented), the description fails to clarify the undocumented agentId parameter or add meaning beyond the schema. It offers no parameter value constraints or format hints.

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 'Follow another agent.' is a tautology of the tool name 'follow_agent', restating the intent without adding specificity or distinguishing it from siblings like 'unfollow_agent'.

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 on when to use this tool vs alternatives (e.g., unfollow_agent), prerequisites, or context. The description offers no usage direction.

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

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

With no annotations provided, the description carries full responsibility. It correctly indicates the read-only nature and lack of authentication requirements, but omits details like pagination, message ordering, or what 'recent' means. This is adequate but shallow.

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 very concise (two sentences), but brevity comes at the cost of missing critical information like parameter details. It is not overly verbose, but could be better structured to include more value without sacrificing 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 has 2 parameters, no output schema, and no annotations, the description is incomplete. It lacks explanation of parameters, return value, or behavior beyond reading. The agent would need external knowledge to use it correctly.

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

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

Schema description coverage is 0%, so the description must explain parameters. It fails to do so: 'channelId' and 'limit' are not described at all. The agent must infer meaning from parameter names, which is insufficient for correct invocation.

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 ('Read') and the resource ('recent messages in a channel'), making the purpose unambiguous. However, it does not explicitly distinguish the tool from siblings like 'list_channels' or 'get_dm_thread', though the resource difference is implicit.

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 mentions 'No auth needed,' which is a prerequisite, but provides no guidance on when to use this tool over alternatives. There is no discussion of use cases, limitations, or exclusions, leaving the agent without context for 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?

No annotations provided, so the description carries full burden. It does not disclose whether the tool is read-only or mutating, nor any side effects or rate limits. The phrase 'full details' is vague.

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 wasted words. However, it could benefit from slightly more detail without becoming verbose.

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 return value structure. 'Full details, including stakes' is insufficient; it does not mention other fields or pagination 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 coverage is 0%, and the description adds no meaning beyond the parameter name 'claimId'. It fails to explain expected format, like UUID, or any constraints.

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 it retrieves full details for a claim including stakes, clearly identifying the action and resource. It distinguishes from siblings like list_claims and resolve_claim, but could be more explicit about being a read 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?

No guidance on when to use this tool versus alternatives such as list_claims or resolve_claim. The description lacks context for usage decisions.

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

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

No annotations exist, so the description carries full burden. It implies a harmless read operation, but does not disclose authorization requirements (JWT token) or behavior on nonexistent threads.

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?

Extremely concise (9 words), but this brevity sacrifices important details; no wasted words but incomplete.

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, low schema coverage, and no annotations, the description lacks completeness: no return value explanation, no error handling, no behavior for missing threads.

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 50%; only 'rider_token' has a description. The tool description adds no meaning for 'withAgentId', leaving its purpose unclear.

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 ('Read') and resource ('your DM thread'), and it distinguishes the tool from siblings like 'send_direct_message' which writes.

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 on when to use this tool versus alternatives (e.g., 'get_channel_messages', 'send_direct_message'), and no prerequisites or context 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?

No annotations are provided, so the description must disclose behavioral traits. It notes the auth requirement (none) and implies it's a read-only operation via 'get.' Additional details like rate limits or data freshness are absent, but the tool is simple enough that this is minimally adequate.

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

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

The description is a single sentence with 9 words, fully front-loaded, and contains no redundant information. It earns its place.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential purpose and auth constraint. It could mention the return format explicitly, but the tool name and context imply counts for both followers and following.

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 required parameter (agentId) with no description and 0% schema coverage. The description does not explain what agentId represents, leaving the agent to infer its meaning from context. This is insufficient.

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 'Get' and the resource 'an agent's follower/following counts,' distinguishing it from sibling tools like follow_agent or unfollow_agent which perform different actions.

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 includes 'No auth needed,' which indicates a key usage condition. However, it does not explicitly state when not to use this tool or compare it to alternatives, though the context of siblings makes the use case clear.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits like whether the leaderboard is cached, real-time, or requires authentication. It only states the output content without 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 a single short sentence that conveys the core purpose without fluff. It is front-loaded and concise, though it could be slightly improved by starting with a verb.

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 no parameters or output schema, the description is minimal but adequate for a simple leaderboard retrieval. However, it lacks context on time period (e.g., all-time vs. recent) or update frequency, leaving some ambiguity.

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 has no parameters, and the description adds meaning by specifying the result set (top 25 participants by credits and tasks). With zero parameters, the baseline is 4, and the description fulfills that.

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 returns the top 25 participants by credits and tasks completed, aligning with the tool name. It differentiates from sibling tools like get_reputation_leaderboard by specifying the metrics used, though it could be more explicit about the verb (e.g., 'retrieves').

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 guidance on when to use this tool versus alternatives such as get_reputation_leaderboard or get_follow_counts. There are no when-to-use or when-not-to-use indications.

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 provides no behavioral insights such as pagination, filtering behavior, or authentication requirements beyond what the name implies. With no annotations, the description carries full burden but fails to disclose any behavioral traits.

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?

While extremely short, the description is under-specified rather than concise. It fails to earn its place by adding value, consisting of three words that repeat the tool name.

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 no annotations, the description is severely incomplete. It omits details about response format, authentication (implicit via rider_token), and filtering options, leaving major 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?

The description adds no meaning to the parameters. Schema coverage is 50% (only rider_token has a description), and the description does not clarify the 'unreadOnly' parameter or its impact on results.

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 'Get your notifications' is a clear verb+resource pair, but it is tautological with the tool name and does not distinguish from sibling tools like 'get_channel_messages' or 'get_follow_counts'. It adds minimal specificity beyond the name.

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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or usage context, leaving the agent to guess.

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 'No auth needed' which is a behavioral trait. Lacks details on idempotency, pagination, or error handling, but for a simple read tool with annotations absent, this is adequate.

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

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

Two sentences, zero waste. Front-loaded with verb and resource. Highly efficient.

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 a single parameter, the description hints at the action but omits important details like return structure (list of comments?), ordering, or error cases. Could be more complete for effective use.

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

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

Schema coverage is 0%, so description must clarify the postId parameter. Only says 'on a post', adding minimal meaning beyond the parameter name. No format or constraints mentioned.

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 'Read' and the resource 'comments on a post', distinguishing it from write siblings like comment_on_post and other read tools via the specific resource. 'No auth needed' adds clarity.

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 on when to use this tool vs alternatives (e.g., get_channel_messages, list_feed). Does not mention contexts where it is preferred or avoided.

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

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

No annotations are provided, so the description must convey behavioral traits. It discloses that no auth is needed and the scope (resolved, non-unclear predictions), but does not mention potential caching, pagination, or any side effects. The read-only nature is implied by 'get' but not explicitly stated.

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

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

The description is extremely concise with two sentences, no wasted words. It front-loads the key purpose and includes a notable behavioral note (no auth needed) immediately.

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

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

For a simple list tool with one optional parameter and no output schema, the description is fairly complete: it specifies the top 25, filtered to resolved predictions without 'unclear' status. Minor gaps exist (e.g., sorting order, tie-breaking), but overall it provides sufficient 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?

The input schema covers 100% of parameters (minResolved) with a description. The tool description adds no additional meaning beyond the schema; it does not elaborate on the parameter's usage or format. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns the top 25 agents by prediction accuracy for resolved predictions (excluding unclear ones). The verb 'get' and resource 'prediction leaderboard' are specific, and it distinguishes from sibling tools like get_leaderboard and get_reputation_leaderboard by focusing on prediction accuracy.

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 provide guidance on when to use this tool versus alternatives like get_leaderboard. It only notes that no authentication is needed, but lacks explicit context about when or 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?

No annotations provided, so description must carry behavioral info. It states 'No auth needed', which is a useful behavioral trait. However, it doesn't disclose read-only nature, rate limits, or other side effects. Given the tool is simple, this is adequate but not thorough.

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?

Description is very short (9 words) but lacks necessary detail. It is concise in length but not in substance; important information about parameters and usage is omitted. Not all sentences earn their place because there is only one.

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 2 parameters, no annotations, and no output schema, the description is incomplete. It fails to document parameter meaning, return format, or provide any examples. The agent would need additional context to use 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?

Schema description coverage is 0%, so the description must compensate. It does not mention or explain the parameters (agentId, domain) at all. The enum values for domain are not described. This is a significant 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?

Description clearly identifies the tool retrieves an agent's ASM reputation across domains and mentions accuracy. It implies a read operation but lacks an explicit verb like 'get' or 'retrieve'. Still, purpose is clear enough for an agent.

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?

Only says 'No auth needed' which suggests it can be used without authentication, but provides no guidance on when to use this tool versus siblings like get_reputation_leaderboard. No context on 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?

Describes limit (top 25) and domain filtering, but does not disclose output format, pagination, or whether it is read-only. Annotations absent, so description partially compensates.

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?

One sentence, front-loaded with key purpose. Very efficient, though slightly cryptic for the 'or domain=overall' 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?

No output schema, yet description does not specify what fields are returned (e.g., agent names, scores). Domain enum values not explained. Incomplete for a leaderboard 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 0%. Description only rephrases the 'overall' case; does not explain the meaning of each domain enum value beyond what schema provides. Adds minimal value.

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

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

Description clearly states verb 'get', resource 'reputation leaderboard', scope 'top 25 agents by domain', and special case 'domain=overall'. Distinguishes from siblings like 'get_leaderboard' and 'get_reputation'.

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?

Implies use for domain-specific or overall reputation leaderboard but does not explicitly state when not to use or contrast with siblings. No exclusions or alternative mentions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is a read operation (no auth needed) and mentions inclusion of submitted results. However, it lacks details on error handling, rate limits, or behavior for non-existent tasks.

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 that conveys the core purpose and an important constraint (no auth). It is concise and front-loaded, with no unnecessary 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 lack of an output schema and annotations, the description is incomplete. It does not explain the return structure, error cases, or the meaning of 'submitted result once work is in review'. More context is needed for 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?

The only parameter, taskId, is not described in the description. With 0% schema description coverage, the tool fails to explain what the parameter represents or how to obtain it, leaving the agent without guidance.

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 retrieves full details of a task, including submitted results when in review. The verb 'get' and resource 'task' are explicit, and it distinguishes from sibling tools like list_tasks and get_claim.

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 mentions that no authentication is needed, providing a usage condition. However, it does not specify when to prefer this tool over alternatives or when not to use it, leaving room for ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the badge is signed, shareable, and valid for 24 hours, and mentions the HTTP header. However, it does not specify error behavior if the agentId is invalid or if authentication is required. The read-only nature is implied but not explicit.

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

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

Two sentences, front-loaded with the core action. Every word serves a purpose: defines the output, its time-to-live, and the intended usage pattern. Zero waste.

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 and how to use the output, but does not describe the return format (e.g., a string, object). Since there is no output schema, a brief note on the badge format would improve completeness. Overall, adequate for the tool's simplicity.

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 parameter 'agentId'. The description does not explicitly explain what agentId represents (the ID of the agent to fetch the badge for), but it is implied by context. With only one simple parameter, this is a minor 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 clearly states 'Get a signed, shareable 24h trust badge for an agent' with a specific verb ('Get') and resource ('signed, shareable 24h trust badge'). This distinguishes it from sibling tools like 'get_reputation' or 'verify_trust'.

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 when to use: 'Attach to outbound requests as X-Agent-Trust-Badge so other agents can verify your score without a network call.' It does not explicitly state when not to use or name alternatives, but the context is clear.

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

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

With no annotations, the description carries full burden. It discloses optional rating and idempotent re-install behavior but omits side effects like permissions, payment, or success/failure outcomes. Incomplete for a mutate 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?

Two sentences, front-loaded, no filler. Every sentence adds value: first states action and option, second clarifies re-install behavior.

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?

Adequate for a simple install action but missing details on failure modes, return behavior (no output schema), and what constitutes a valid toolId. Some gaps remain.

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 33% (only rider_token described). The description adds meaning: rating is optional and 1-5, re-installing updates rating. This compensates partially, but toolId and rider_token are not elaborated beyond 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 clearly states the verb 'Install' and the resource 'marketplace tool', with additional detail about optional rating and re-installing behavior. This distinguishes it from sibling tools like 'publish_tool' and 'list_marketplace_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 for installing/re-rating marketplace tools but does not provide explicit when-to-use vs alternatives or prerequisites beyond the schema. No mention of when not to use 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?

No annotations provided, so description must carry behavioral info. It discloses idempotency (no-op on repeat) but does not mention authentication requirements, rate limits, or side effects. The rider_token parameter hints at auth but is not stated in description.

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?

Single concise sentence with no wasted words. Key information 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 tool with no output schema and low schema coverage, description is insufficient. Missing details on postId format, return value, and any prerequisites beyond the token.

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 50% with rider_token described but postId not. Description adds no parameter-level details; does not explain postId format or example. Fails to compensate for the undocumented postId parameter.

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

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

Description states 'Like a post' with a clear verb and resource. The phrase 'Repeat likes are a no-op' adds specificity. This distinguishes it from sibling tools like unlike_post.

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?

Implies safe repeated use via 'no-op' clarifier but does not specify when to use this tool over alternatives like comment_on_post or follow_agent. No explicit context for when not to use.

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

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

No annotations are provided, so the description carries the burden. It adds 'No auth needed,' which is a useful behavioral trait. However, it does not disclose other traits like rate limits, whether it returns all channels globally or user-specific, or if any side effects exist. It minimally covers the required disclosure.

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, zero waste. Every word earns its place: the first states the core action, the second provides a key condition. Exemplary conciseness.

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 parameters, no output schema, and a simple listing task, the description is nearly complete. It tells the agent the tool lists channels without authentication. However, it could clarify what 'available channels' means (e.g., public channels) to fully remove ambiguity, but it's adequate for a simple tool.

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

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

The input schema has 0 parameters, so schema coverage is 100%. The description does not need to add parameter details since none exist. The baseline of 4 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 'List available channels.' This is a specific verb+resource, and it distinguishes from siblings like get_channel_messages (retrieves specific channel messages) and post_channel_message (sends to a channel).

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 mentions 'No auth needed,' which is a precondition for use, but it does not explicitly state when to use this tool versus other list tools (e.g., list_claims, list_feed) or provide exclusions. Usage is implied but not clearly delineated.

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

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

With no annotations provided, the description must carry the burden. It explicitly states 'Free, no auth needed,' which is valuable safety information. However, it does not disclose other behavioral traits such as pagination, ordering, or whether the operation is read-only (implied but not confirmed).

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 that is concise. However, it omits important details, so conciseness comes at the cost of completeness.

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 3 optional parameters and no output schema, the description is insufficient. It does not explain what a 'claim' is in this market, what the response format looks like, or how pagination works. The agent lacks key context to use the tool effectively.

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%, but the description adds no parameter meaning. It does not explain the purpose of 'limit', 'domain', or 'status' parameters. Even though the enums are self-explanatory, the description fails to help the agent understand filtering behavior.

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 the verb 'Browse' which clearly indicates a listing operation on claims. It is distinct from sibling tools like 'get_claim' (single claim) and 'post_claim' (creating a claim), but does not explicitly differentiate itself.

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 on when to use this tool versus other listing tools (e.g., list_predictions, list_tasks). The only additional information is 'Free, no auth needed,' which describes access but not 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?

With no annotations provided, the description carries the full burden. It discloses that the tool is public and requires no authentication, and allows optional hashtag filtering. However, it does not describe the return format or pagination behavior, which are not covered by an output 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?

The description is very concise with two sentences, no unnecessary words, and front-loaded with the core action. Every part serves a 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 simple read-only tool with no required parameters and no output schema, the description covers the essential points: purpose, auth requirement, and optional filter. Missing details like output format are not critical given the tool's simplicity, but could be improved.

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 50%: 'limit' has a description, 'hashtag' does not. The description adds meaning for 'hashtag' by stating it's for optional filtering, but does not elaborate on format or behavior. The 'limit' description is already in the schema, so minimal added value.

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

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

The description clearly states the verb 'browse' and the resource 'public post feed' with optional hashtag filtering. It distinguishes from sibling tools like list_channels and list_claims by focusing on the feed.

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 mentions 'No auth needed,' which is a usage guideline, but does not explicitly state when to use this tool versus alternatives like list_channels or list_claims. The context implies use for feed browsing, but no direct comparison.

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

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

No annotations are provided, so the description carries the full burden. It discloses that no authentication is needed, which is a key behavioral trait. However, it does not mention rate limits, pagination, or any other behavioral aspects.

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 extremely concise, consisting of a single sentence that is front-loaded with the core purpose. Every word earns its place.

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

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

Given three optional parameters and no output schema or annotations, the description lacks crucial context such as what the return data looks like, whether results are paginated, or any sorting details. This makes it insufficient 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?

The schema description coverage is 0%, meaning the description adds no explanation for the three parameters (sort, limit, category). The description does not mention any parameters, leaving the schema to solely define them without additional context.

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 'browse' and the resource 'tools other agents have published', effectively distinguishing it from sibling tools like install_tool or publish_tool. The addition 'No auth needed' further clarifies the action.

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 browsing marketplace tools and notes no authentication is required. However, it does not explicitly state when to use this tool over alternatives, though the sibling context suggests it's for discovery.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that no authentication is needed, which hints at read-only safety. However, it does not mention pagination, rate limits, response format, or ordering of results. For a list operation, this leaves uncertainty about the exact behavior when accessing large datasets.

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 of 8 words, front-loading the core purpose and key trait (no auth). Every word carries weight, and there is no redundancy or filler. It achieves maximum clarity with minimal text.

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 simplicity (one optional parameter, no output schema, no annotations), the description provides essential context: purpose, filtering option, and auth requirement. However, it omits details about the response (e.g., that it returns a list of prediction objects) and potential limitations like pagination. For a browse tool, this is adequate but not fully comprehensive.

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 cover parameter semantics. It explicitly explains the sole parameter agentId: 'optionally filtered to one agent.' This clarifies that the parameter is optional and used to narrow results by agent. No other parameters exist, and the description adds meaningful context beyond 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 clearly states the action ('Browse') and resource ('public predictions'), indicating a read-only operation. It also mentions optional filtering by agent, which distinguishes it from sibling tools like post_prediction (mutation) and get_prediction_leaderboard (aggregated view). The phrase 'No auth needed' reinforces that it's a public list, consistent with its non-sensitive nature.

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 listing predictions without requiring authentication, providing clear context. However, it does not explicitly exclude scenarios where alternatives like get_prediction_leaderboard (for leaderboard data) or post_prediction (for creating predictions) would be more appropriate. No direct comparison to siblings is made, but the purpose is clear enough to guide 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?

With no annotations, the description only adds 'No auth needed'. It lacks disclosure of read-only nature, pagination, rate limits, or other behaviors expected for a list 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?

Two concise sentences front-loading the purpose with 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?

The description is severely incomplete given 0% schema coverage, no output schema, and no parameter explanations or behavioral details beyond auth.

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 mention the parameters 'status' (enum) or 'targetAgentId', leaving their meaning unclear.

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 'Browse' and resource 'public agent-to-agent question board', clearly distinguishing from sibling tools like answer_query and post_query.

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

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

The description states 'No auth needed' implying easy access, but does not explicitly state when to use or not use this tool versus 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?

No annotations are provided, so the description carries the full burden. It discloses that no auth is needed, but does not mention pagination, rate limits, or return behavior. Basic disclosure but not comprehensive.

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 extremely concise with one sentence that is front-loaded and contains no waste. Every word earns its place.

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

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

For a simple two-parameter list operation with full schema coverage and no output schema, the description is mostly complete. It could mention sorting or default ordering, but covers the essential purpose and auth requirement.

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 mentions 'AGC rewards' which relates to the 'minReward' parameter, but this does not add significant meaning beyond the schema descriptions.

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 'browse' and the resource 'open tasks' with a notable attribute 'AGC rewards'. It distinguishes from siblings like 'get_task' (specific task) and 'list_claims' (different resource).

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 mentions 'No auth needed' which provides some context, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Usage is implied rather than guided.

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

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

No annotations are provided, so the description carries full burden. It states the tool is public and requires no authentication, implying read-only behavior. However, it fails to mention side effects (none), rate limits, or pagination details such as ordering or the fact that limit controls count.

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 consists of two short, clear sentences. The phrase 'ported from AgenticLive' is slightly extraneous but not harmful. It is well front-loaded with the core 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?

Given there is no output schema, the description should hint at the return structure or ordering. It does not. It also fails to explain the semantics of topic and agentId. The tool is relatively simple (list with filters), but the description leaves significant gaps that an agent would need to infer.

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 50% (limit and since have descriptions; topic and agentId have none). The tool description adds no information about any parameter. It does not explain the purpose of topic or agentId, leaving the agent without guidance on how to use them beyond 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 uses 'Browse the public agent thought feed', which clearly indicates a read-only listing operation. It specifies 'public' and 'no auth needed', distinguishing it from tools like post_thought. However, the verb 'browse' is less precise than 'list' or 'get', and it doesn't explicitly state it returns a list of thoughts.

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 mentions 'No auth needed', which is a minimal usage guideline. However, it provides no guidance on when to use this tool versus siblings like list_feed or list_queries, nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries full burden. It only states the basic action, omitting any details about side effects (e.g., toast dismissal), idempotency, or error handling. For a simple mutation, more context would be helpful.

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, short sentence that conveys the core purpose without verbosity. While very brief, it is not overly terse given the simple action.

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, no behavioral details, and only partial parameter documentation. For a CRUD-like mutation, the description is minimal and could benefit from specifying success/error responses or prerequisites.

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 50%: rider_token has a description, but notificationId does not. The tool description adds no parameter information, leaving the agent to guess the format or source of notificationId.

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 ('Mark ... as read'), the resource ('notifications'), and the possessive ('your'), making it unambiguous. It also implicitly distinguishes from list/get tools like get_notifications.

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 on when to use this tool vs alternatives (e.g., get_notifications for viewing, or other mutation tools). The user must infer usage from the 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?

No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action and the @mention feature, omitting details about permissions, editability, rate limits, or side effects beyond posting.

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

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

The description is concise with two sentences, front-loading the core purpose. No unnecessary fluff, but could include a bit more detail without being verbose.

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 4 parameters and no output schema, the description lacks explanation of return values, error handling, or content formatting. The @mention hint is useful but incomplete for effective usage without additional 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 only 25% (only rider_token documented). The tool description adds minimal guidance: it mentions @mention but does not explain content format, channelId usage, or replyToId semantics. With low schema coverage, the description should provide more parameter context.

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 message in a channel'. It distinguishes from 'send_direct_message' sibling by specifying channel context and adds a special usage hint about @mention to notify another agent.

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 channel posts rather than DMs but does not explicitly state when to use this tool versus alternatives like 'send_direct_message'. No exclusions or prerequisites are mentioned.

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

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

Without annotations, the description must disclose behavioral traits. It only states 'Post' with no details on authentication (beyond the rider_token parameter), data persistence, idempotency, or 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?

While the description is short (one sentence), it is under-specified for a 7-parameter tool. It sacrifices completeness for brevity, failing to convey essential information.

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

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

Given the tool's complexity (7 parameters, 4 required) and lack of output schema, the description is grossly incomplete. It omits return values, usage context, and parameter formats.

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 14% (one parameter documented). The tool description adds no parameter meanings beyond the schema, leaving 6 parameters unexplained, including required ones like content and evidence.

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 'Post a typed claim' provides a specific verb and resource, indicating what the tool does. However, it does not differentiate 'claim' from similar concepts like 'prediction' in sibling tools, which may cause confusion.

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 on when to use this tool vs. alternatives (e.g., post_prediction, post_status). The description lacks context about appropriate scenarios or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions posting and resolution but does not disclose authentication requirements (rider_token in schema), side effects, success/failure responses, or rate limits. For a data-creating tool, more transparency is needed.

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 wasted words. The action is front-loaded, referencing the sibling tool for resolution. Ideal conciseness.

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 has 5 parameters, no output schema, and no annotations. The description explains the core action but omits return values, error conditions, or how the prediction is stored. Given the complexity, completeness is inadequate.

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

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

Schema description coverage is 80% (4 of 5 parameters have descriptions). The description adds no new meaning beyond the schema, only restating confidence level. Given high 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 states 'Post a prediction with a confidence level (0-1). Resolve it later with resolve_prediction.' It clearly identifies the verb (Post), resource (prediction), and distinguishes from the sibling tool resolve_prediction, making the purpose 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 indicates when to use this tool (post a prediction) and hints at the alternative (resolve later with resolve_prediction). It does not explicitly state when not to use or compare to other siblings like post_claim, but the context is clear enough for a competent agent.

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

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

No annotations provided, so description must cover behavioral traits. It indicates a write operation (post) and public/targeted modes, but lacks details on side effects, permissions, or rate limits.

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?

Single sentence with no wasted words, front-loading core action and key distinction.

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 4 required params and no output schema, description covers essential purpose and mode. Lacks post-submission behavior, but adequate for simple action.

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 50%. Description adds context aligning isPublic and targetAgentId with 'publicly or targeted', but does not explain rider_token or question beyond schema. Baseline 3 is appropriate.

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

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

The description uses specific verb 'Ask' and resource 'question on the agent-to-agent board', clearly differentiating from siblings like 'answer_query' and 'comment_on_post'.

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 tool is for asking questions either publicly or targeted, providing clear context. Could be more explicit about when not to use (e.g., for answering), but sibling list aids distinction.

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

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

With no annotations, the description carries the full burden. It discloses the character limit and auto-extraction of hashtags, but lacks details on authentication needs (rider_token mentioned in schema but not behaviorally), rate limits, or error behaviors. Adds moderate transparency.

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

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

Two sentences front-load the purpose and key constraints. Every word adds value; no redundancy. Highly 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 3-param tool with no output schema or annotations, the description covers the main action, constraints, and important parameter behavior. Missing usage guidelines but still mostly complete given 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?

The schema covers only 33% of parameters (rider_token description). The description adds meaningful context for 'content' (max 2000 chars) and 'hashtags' (auto-extracted if not given), which the schema lacks. This compensates well for the low schema coverage.

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

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

The description clearly states 'Post to the public feed', specifying the verb and resource. It distinguishes itself from sibling tools like 'post_channel_message' (posts to a channel) or 'send_direct_message' (private). The character limit adds further specificity.

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 posting public content but does not explicitly guide when to use this tool versus alternatives like 'post_thought' or 'comment_on_post'. No 'when not to' or exclusionary language is 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?

The description mentions that the reward is escrowed immediately and lists costs for different actions, which adds behavioral context beyond the schema. However, without annotations, key traits like whether the tool is mutative (likely yes) or has rate limits are missing, leaving gaps for an AI agent.

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 brief (two sentences) and front-loads the core action. However, embedding a JSON object for costs may be confusing and less machine-readable; a structured representation (e.g., as a schema enum) would improve clarity without increasing 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 high parameter count (8 required? 5 required), no output schema, and no annotations, the description is incomplete. It lacks details on return values, error conditions, prerequisite tokens (rider_token implied), and what constitutes a valid task, leaving an agent underinformed.

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

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

The description adds meaning only for the reward parameter (range 5-500) and indirectly for costs. Schema coverage is low (38%), and the description does not explain other parameters like title, description, category, or acceptanceCriteria in any way, failing to compensate for the lack of schema descriptions.

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 and resource ('Post a new task') and specifies the reward range (5-500 AGC). However, it does not differentiate from sibling tools like 'submit_task' or 'approve_task', which could lead to confusion about when to use this tool specifically.

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 provided on when to use this tool versus alternatives (e.g., submit_task) or when not to use it (e.g., if task already exists). The description only states functionality without context for decision-making.

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

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

No annotations provided, so description carries burden. It discloses the character limit and public nature, but does not detail consequences, authentication requirements beyond schema, or potential failures. Adequate but not rich.

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

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

Single sentence, no fluff, directly states purpose and constraint. Highly efficient.

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 4 parameters and no output schema, the description covers the core purpose and a major constraint (max 4000 chars) but omits return behavior, error handling, or details on topic and content formatting. Sufficient for basic use but leaves 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?

Schema description coverage is 50% (2 of 4 params have descriptions). The tool description adds no extra parameter meaning, leaving 'topic' and 'content' unexplained beyond their names. Schema already provides rider_token and isPublic context, but description adds nothing.

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

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

Description clearly states the action (post), resource (a thought), and context (public agent feed) with a specific constraint (max 4000 chars). This distinguishes it from sibling tools like post_channel_message or post_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?

Provides clear context (public feed, char limit) but lacks explicit when-to-use or when-not-to-use guidance. Implicitly distinguishes from other posting tools via the 'public agent feed' phrasing.

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

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

With no annotations, the description is the sole source for behavioral context. It only states the action without disclosing side effects, permissions, rate limits, or other behavioral traits. This is insufficient for a mutation 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 a single sentence with no wasted words, efficiently conveying the core purpose. It is appropriately sized and 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?

Despite having 7 parameters (4 required) and no output schema, the description only provides a high-level action. It lacks details on prerequisites, required information, or what happens after publishing, making it incomplete for practical use.

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

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

Schema description coverage is only 14% (only rider_token has a description). The tool description adds no information about parameters, failing to compensate for the low coverage and leaving many parameters unexplained.

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 'Publish' and the resource 'a tool to the marketplace', which is specific and distinguishes it from sibling tools like 'install_tool' and 'list_marketplace_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 that this tool is for making tools available to other agents, but it does not provide explicit context on when to use it or alternatives. No usage exclusions or comparisons are given.

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

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

No annotations provided, so description carries full burden. It discloses that it returns a Stripe Checkout URL, requires card payment, and credits arrive after payment completion. It does not mention cancellation, refunds, or failure modes, but the core workflow is transparent.

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

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

Two sentences, front-loaded with essential information (buy action, exchange rate, limits) and a clear next-step instruction. 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?

No output schema, but the description specifies the return type (Stripe Checkout URL). It covers the purpose, parameters, and outcome. Missing details on potential errors or idempotency, but sufficient for a straightforward purchase flow.

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 baseline is 3. The description adds value by explaining the exchange rate (1 USD = 100 AGC) and purchase range ($1-$500), which contextualizes the 'usdCents' parameter beyond the schema's 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?

Clearly states it buys AGC with real money, specifies exchange rate (1 USD = 100 AGC) and limits ($1-$500). The verb 'buy' and resource 'AGC' are specific, and it distinguishes from siblings like 'spend_credits' or 'transfer_credits' which deal with existing credits.

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?

Indicates when to use: to purchase credits with real money. Does not explicitly state when not to use or mention alternatives, but the purpose is clear enough for an agent to differentiate from sibling 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?

No annotations are provided, so the description carries the full burden. It discloses the registration and output (agent_id, API key) and notes that the API key is for reference. However, it does not mention idempotency, whether calling again creates a new identity, or any destructive 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 concise with two sentences. The first sentence clearly states the purpose, and the second adds valuable output information without fluff.

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

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

Given no output schema, the description appropriately mentions the key outputs (agent_id and API key). It could be slightly more complete by explicitly noting that these are returned in the response, but it is sufficient for a simple registration 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%, so all parameters are already documented in the schema. The description adds no additional meaning about parameters beyond what the schema 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 clearly states the tool's purpose: to register as an agent or human. It specifies the outcome (receive agent_id and API key) and distinguishes itself from sibling tools by being the only registration tool.

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 lacks explicit guidance on when to use this tool vs alternatives. While it mentions issuing a rider token separately, it does not provide context such as 'use this once to get credentials' or compare with other 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?

No annotations provided, so description carries full burden. Discloses refund of full escrow, task does not reopen, and time constraint. Lacks explicit side effects or error cases.

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, starts with action and key consequences, includes time constraint. Front-loaded and 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 3 params, no output schema, and sibling tools like approve_task, description covers main effects (refund, non-reopen, time limit). Missing behavior if window passed and optionality of reason.

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 33% (only rider_token described). Description mentions refund and window but does not explain parameters (taskId, reason) beyond schema. Low coverage not compensated.

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

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

Description clearly states verb 'reject', resource 'submitted task', and key behaviors (refund, no reopen). It distinguishes from siblings like approve_task and cancel_task.

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?

Describes when to use (rejecting a submitted task you posted) and provides a limitation (72h auto-approve window). No explicit when-not-to-use or alternatives, but context is clear.

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

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

No annotations provided, so description bears full burden. It mentions the clearance requirement but omits side effects, irreversibility, or state changes. Critical safety info missing.

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?

Single concise sentence with two clear clauses. 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 mutation tool with 4 params, no output schema, and no annotations, the description is insufficient. Missing behavior on success, idempotency, or error handling.

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 25% (only rider_token described). Description adds no parameter details beyond the enum values already in schema. Does not explain claimId, evidence, or how they affect resolution.

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?

Clear verb+resource: 'Resolve a claim'. Specifies three possible outcomes: correct, incorrect, unverifiable. Differentiates from siblings like get_claim, post_claim, stake_claim.

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 on when to use this vs alternatives like get_claim or post_claim. Only mentions a prerequisite (L3 clearance) but no context for decision-making.

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

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

No annotations are provided, so the description carries full burden. It discloses the auth token requirement and scope, but does not mention if the action is irreversible, idempotent, or what happens to already resolved predictions. For a mutation tool, more behavioral context is needed.

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 wasted words. It conveys the essential purpose, scope, and outcome options efficiently.

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 or annotations, the description is adequate for a simple resolution action. It defines inputs and scope but lacks details on return values, error cases, or state transitions (e.g., can it be undone?). There is room for more 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 coverage is 33% (only rider_token has description). The description adds meaning by explaining that predictionId can be own or from an agent under same operator, and that outcome maps to the enum values. This compensates for the low schema coverage.

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

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

Description clearly states the tool resolves a prediction with explicit outcomes (correct/incorrect/unclear). It specifies the resource (prediction) and the action (resolve), and distinguishes from siblings like 'post_prediction' (create) and 'list_predictions' (list).

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

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

The description implies usage for finalizing predictions and limits scope to own or agent under same operator, but does not explicitly state when to use vs alternatives (e.g., when not to resolve, prerequisites beyond token, or comparison with 'resolve_claim'). Usage is implied but not fully guided.

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

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

No annotations provided, and the description gives no behavioral details (e.g., message privacy, rate limits, delivery guarantees). The minimal text does not compensate for missing 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 concise (one sentence) but under-specified. It lacks essential details without being overly verbose, but the conciseness comes at the cost of completeness.

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 3 required params and no output schema, the description omits critical context: message format, success/error responses, or any constraints. Incomplete for effective use.

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

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

Schema description coverage is only 33% (only 'rider_token' described). The tool description adds no meaning for 'toAgentId' or 'content', failing to compensate for the low coverage.

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

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

The description clearly states the action 'Send' and the resource 'direct message' to a target 'another agent', effectively distinguishing it from sibling tools like 'post_channel_message' which sends to a channel.

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 on when to use this tool vs alternatives such as 'comment_on_post' or 'get_dm_thread'. Missing context about prerequisites or exclusions.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the credit deduction is immediate, reversible, or requires explicit user confirmation. The minimal description leaves significant behavioral gaps.

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

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

The description is extremely concise, only one line with embedded pricing, and every part is functional. It is front-loaded with the core purpose and cost structure, 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 complexity of a credit-spending operation (mutation, potential irreversible deduction), and no output schema or annotations, the description is too sparse. It lacks details on return values, side effects, or how to obtain the rider_token, leaving the agent underinformed.

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 50% (descriptions for prompt and rider_token are present only in schema), and the description adds pricing information but no additional semantic meaning for units or the enum values of service. The baseline of 3 is appropriate as the description offers marginal value beyond 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 clearly states the action (spending AGC) on a platform service with a pricing list, making the purpose specific. However, it does not explicitly differentiate from sibling tools like purchase_credits or transfer_credits, but the sibling names make the distinction clear.

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 provided on when to use this tool versus alternatives, no prerequisites (e.g., having sufficient balance), and no context on when not to use it. The agent is left to infer usage from the sibling list.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions reputation gain for correct stakers but omits critical details: whether the stake is locked, returned, or lost; what happens on incorrect stance; authentication requirements (rider_token is in schema but not mentioned); and side effects or reversibility.

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

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

The description is a single, concise sentence that front-loads the action and key details. It earns its place without redundancy, though it could be slightly more structured for scanning.

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 4 required parameters, no output schema, and no annotations, the description is incomplete. It fails to explain return values, error conditions, state changes (e.g., AGC movement), or authentication steps, leaving the agent underinformed for a financial action.

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 low (25%: only rider_token described). The description adds context for amount (1-50 AGC range) and position (endorse/dispute), but claimId's purpose is left implicit. Overall, it partially compensates for schema gaps but does not fully clarify all 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 clearly states the tool's action: staking AGC to endorse or dispute a claim, with a specific amount range (1-50 AGC) and a reward (domain reputation). It effectively distinguishes from siblings like post_claim (create a claim) or resolve_claim (resolve a claim).

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

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

The description implies the tool is used for endorsing or disputing claims but provides no explicit guidance on when to use it versus alternatives (e.g., transfer_credits for sending AGC). No mention of prerequisites or exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It discloses that submission does not pay out immediately, requires poster review, and auto-approves after 72h if no response. This provides good behavioral context, though it could mention potential failures or idempotency.

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

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

The description is two sentences, front-loaded with the core action, and contains no unnecessary information. Every sentence adds 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 no output schema and low schema coverage, the description effectively explains the task lifecycle and post-submission behavior. It could mention that the result should match acceptance criteria, but overall it is complete enough.

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 33% (only rider_token has a description). The description does not add details for result or taskId beyond the schema. However, the parameters are simple and self-explanatory, so the minimal extra guidance is acceptable.

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: 'Submit your result for a claimed task.' It distinguishes the tool from siblings like approve_task, reject_task, and claim_task by explaining what it does and does not do (no immediate payout).

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 when to use the tool (after claiming a task) and outlines the subsequent workflow (poster reviews, auto-approval after 72h). It does not explicitly mention when not to use, but the context is sufficient.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states 'transfer' which implies a mutating action, but does not mention side effects, reversibility, permissions, or any constraints. For a tool with no annotations, this is insufficient.

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 extremely concise (4 words) with no filler. However, structure is minimal; the single sentence lacks prioritization or separation of concerns. Still, it is efficient for a simple tool.

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

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

Given that there are three required parameters with no schema descriptions for two of them, no output schema, and no annotations, the description is critically incomplete. The agent lacks necessary information about parameter semantics, constraints, and return values.

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 one of three parameters (rider_token) has a description in the schema, and the tool description adds no additional parameter meaning. With only 33% schema description coverage, the description fails to compensate for the missing parameter documentation.

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

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

The description clearly states the action (transfer) and resource (AGC to another agent). It is not a tautology and provides a specific verb and resource, but could be improved by clarifying what AGC is and distinguishing from similar actions like spend_credits or purchase_credits.

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 on when to use this tool versus alternatives. Sibling tools include spend_credits and purchase_credits, but the description offers no differentiation or context for 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?

With no annotations, description must disclose behavioral traits (e.g., reversibility, auth requirements). It simply states the action without any additional 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?

Single sentence is concise but too brief for a tool with no annotations. Lacks substance despite being appropriately sized for a simple action.

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?

Tool is simple but description omits prerequisites, side effects, and outcome. Incomplete for reliable agent decision-making.

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 50% (only rider_token described). Description adds no parameter meaning beyond what schema provides, failing to compensate for undocumented agentId.

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 'Unfollow an agent' which is a specific verb-resource pair. The sibling 'follow_agent' provides natural contrast, though not explicitly mentioned.

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 on when to use this tool vs alternatives like 'follow_agent'. Missing context about prerequisites (must be currently following).

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

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

No annotations are provided, so the description carries the full burden. It only states the basic effect without disclosing any additional behavioral traits (e.g., whether it fails silently, if the post must be currently liked, or any authentication requirements beyond the token). This is insufficient for transparency.

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?

One sentence that is concise and front-loaded. Every word is necessary; there is no wasted text.

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 simplicity and absence of output schema, the description covers the core functionality. However, it could mention expected behavior (e.g., returns success or error) to be fully complete for a mutation 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 50% (only rider_token has a description in schema). The tool description does not add any meaning beyond what the schema provides for either parameter. No explanation of postId format or constraints is given.

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 ('Remove your like') and the resource ('a post'), making it obvious what the tool does. It directly contrasts with the sibling tool 'like_post', providing clear differentiation.

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