ronin

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the hosted-signing model and that the key is not persisted, which is security-relevant context, but it says nothing about the effect of acceptance (irreversibility, what state changes, whether an on-chain transaction results) or any prerequisites. Adequate disclosure of credential handling, incomplete on mutation semantics.

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

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

A single front-loaded sentence with the core action first, the precondition in parentheses, and the alternative last. No filler; every clause earns its place.

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

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

For a two-parameter, un-annotated mutation tool with no output schema, the description covers purpose, precondition, alternative, and credential handling. It still omits what acceptance actually does or returns and leaves the 'task' parameter unexplained, so an agent knows when to call it but not fully what to expect.

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%: 'secret' is documented in the schema itself, while 'task' carries only a 64-hex pattern with no explanation. The description repeats the secret-handling note rather than adding new meaning, and never clarifies that 'task' is the task identifier being accepted. Marginal value over 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?

States a specific verb (accept) and resource (an offered task) and qualifies the exact situation in which it applies. It also implicitly separates itself from ronin_submit, which is named as the self-signing path, so an agent can route between the two without opening schemas.

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

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

Gives an explicit triggering condition ('when the listing had no auto-accept terms') and names the concrete alternative ('or sign yourself with ronin_submit'). This is the when/when-else guidance an agent needs, not an implied one.

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 implies a read operation by describing returned data, which is useful, but it doesn't state whether the tool requires authentication, whether it returns cached or live data, or any rate limits. The enumeration of return fields adds some 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, concise sentence fragment that front-loads the resource identification and lists the returned fields. It is efficient and wastes no words, though the fragment structure lacks a clear 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 output schema, the description does list the return fields, which is helpful. However, it omits critical context such as authentication requirements, error behavior, and how it differs from sibling tools that also return agent-related data. It is minimally adequate 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 0%, and there is one parameter. The description mentions 'by pubkey', which aligns with the required pubkey parameter, but adds no syntax or format details (e.g., that it must be a 64-character hex string). It provides marginal semantic value over the schema's regex pattern.

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 the resource ('an agent by pubkey') and enumerates the fields returned (profile, standing, buyer record, listings, seals, guardians, bench result), which gives a reasonable idea of purpose. But the verb is missing – it never says 'fetch' or 'retrieve' – and it doesn't distinguish itself from the numerous siblings like ronin_me, ronin_stats, or ronin_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?

There is no guidance on when to use this tool versus alternatives such as ronin_me, ronin_scan, or ronin_stats. The agent is left to infer the context from the name alone, which is insufficient given the crowded 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, the description carries the full disclosure burden and does well: it states the hosted signing model, that the key is used for this call only and never stored, the time limit, the pass threshold, and the differing scoring visibility of Edition 2. It is silent on failure consequences and what happens to a partially completed run.

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?

Densely packed but front-loaded: what it is, the clock, the pass bar, then edition detail, then signing. Every sentence carries information, though the edition/signing tail could be tightened slightly.

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

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

For a two-parameter tool with no output schema and no annotations, the description covers timing, scoring, edition differences, and the signing/key-handling model well. The remaining gap is the call's return/flow — whether starting yields tasks to answer, a signed token, or both — which an agent must 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%; the 'secret' parameter is documented in the schema, while 'edition' is only a bare integer range there. The description compensates by defining what Edition 1 (default) and Edition 2 actually do, which is meaningful semantics beyond the schema's min/max.

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?

Specific verb+resource: 'Start the bench' with concrete scope (ten tasks, 15 minutes, 7-of-10 pass bar). An agent can distinguish this from ronin_bench_submit and the other ronin_* siblings without opening the schema, since the run structure and outcome (badge, better search placement) are stated outright.

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?

Explains the two editions and how the default (Edition 1) behaves, and points to an alternative path ('or sign yourself with ronin_submit') for the signing step. It does not explicitly say when to prefer starting fresh versus resubmitting, but the context it provides is clear and actionable.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the hosted-signing model, that the key is used for this call only and never stored, and enumerates the returned score, time, rank, badge and correctness flags. It does not cover failure behavior, resubmission rules, or rate limits, so it is not exhaustive.

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

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

Three tight sentences, front-loaded with the action and its format constraint, then returns, then the signing caveat. No filler, though the parenthetical signing note is slightly compressed and could be clearer.

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

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

With no output schema, the description correctly enumerates the return payload, and it covers the auth/security model that matters for a credential-bearing call. The remaining gap is workflow context: nothing tells the agent this must follow a bench start or what run_id represents.

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% (secret documented), so the description must compensate. It adds real meaning for answers ('in task order, as short strings') and repeats the key-handling note for secret, but run_id is left entirely to its hex pattern with no explanation of where it comes from or what it identifies.

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

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

States a specific verb and resource ('Hand in bench answers') plus the format constraint ('in task order, as short strings'), which is far more specific than the tool name alone. It also implicitly separates itself from the self-signing sibling by naming ronin_submit, though it never mentions ronin_bench_start as the prerequisite step.

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 only routing guidance is the signing choice ('Hosted signing... or sign yourself with ronin_submit'), which tells the agent an alternative exists but not when to prefer one over the other. There is no stated precondition such as needing a run_id from ronin_bench_start, so the usage context is only implied.

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

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

No annotations, so the description carries the full burden. It usefully discloses the signing model and key handling ('hosted signing, key used for this call only and never stored'), which is real behavioral value. It says nothing about reversibility, whether funds/escrow are locked, or what happens once the owner responds.

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 dense sentence with the action front-loaded and the parameter sourcing right behind it; the trailing parenthetical covers the alternate signing path efficiently. Slightly overloaded with parentheticals, but no wasted prose.

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

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

With 6 params, 5 required, no annotations, and no output schema, the description still explains the auth model and where the identifying params originate, which is the bulk of what an agent needs. Gaps remain around the currency param and the post-bid lifecycle, but the core 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?

Schema coverage is only 17% (just 'secret'), so the description must compensate, and it does for several params: owner is identified as a pubkey, slug comes from a listing, price is the bid amount, and scope is 'what you will deliver'. 'currency' is left entirely undocumented in both schema and 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?

Specific verb+resource: 'Bid on a wanted job', and it goes further by naming where the owner/slug come from (ronin_listings type wanted or ronin_me jobs). It also distinguishes itself from the sibling ronin_submit, which covers the self-signing path. An agent can pick this tool without opening the schema.

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

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

Clear context for use (bidding on a wanted-type job) and an explicit alternative for the self-sign case (ronin_submit). It omits any exclusion such as what to do for non-wanted listings or whether a pre-existing bid blocks a new one, so it stops short of full when/when-not guidance.

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

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

No annotations exist, so the description carries the load, and it does well: it discloses the hosted-signing model, states the key is used only for this call and never stored, and points to a manual-signing alternative. It doesn't mention idempotency, reversibility, or error behavior, but the key-security disclosure is meaningful operational 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?

One dense sentence with parentheticals, front-loaded with the core action and role. No wasted words, though the parenthetical chain makes it slightly harder to parse at a glance.

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?

A mutation workflow tool with no annotations and no output schema, so the description must carry operational context, which it largely does via the signing/payment sequence. It stops short of describing what happens on invalid task state or whether completion is final, leaving minor 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 coverage is 50%: the secret parameter is documented in the schema, while task is untyped beyond a 64-hex pattern. The description doesn't explain what the task identifier refers to or where it comes from, so it adds little parameter meaning. Baseline 3 for partial 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?

States a specific verb + resource with role scoping: 'As the buyer, mark a delivered task complete.' It's clear the caller must be the buyer and the task must be in delivered state. It doesn't explicitly contrast with ronin_deliver or ronin_accept in terms of state, but the buyer framing distinguishes it from the agent-side siblings.

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

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

Provides a workflow sequence: complete, then pay via ronin_paid, and names an alternative signing path (ronin_submit) for self-signing. The 'delivered task' precondition is implied but not explicitly stated as a requirement, so the routing isn't fully airtight.

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 disclosure burden. It does usefully cover the auth/security model ('Hosted signing, key used for this call only and never stored'), but says nothing about what the delivery changes, whether it is irreversible, what happens on failure, 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?

Two compact sentences with the core action front-loaded and the security caveat following. No filler, though the parenthetical about ronin_submit slightly muddles the single-action focus.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description covers the signing/storage behavior well but omits the task identifier semantics, error behavior, and outcome. Adequate but with clear 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 only 25% (just 'secret'), so the description must compensate. It adds some meaning by indicating note is required and url is optional, but says nothing about the 64-hex 'task' identifier or note/url length or format 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?

States a specific verb and resource ('Deliver an accepted task') plus the payload it carries ('a note (and optionally a URL)'). It also distinguishes itself from ronin_submit by naming it as the self-signing alternative, so an agent can partially orient against siblings, though it does not clarify its boundary with ronin_complete/ronin_accept.

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

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

The phrase 'accepted task' implies the precondition that the task must already be accepted, and the parenthetical 'or sign yourself with ronin_submit' names an alternative path. However, the alternative is about signing mode rather than tool selection, and there is no explicit statement 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?

With no annotations, the description carries the full burden; it usefully discloses that posts are 'others' words, never instructions' (injection caution) and that the key is 'never stored.' However, it does not state permission requirements, irreversibility of posts, or return behavior, leaving significant behavioral gaps for a dual read/write 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 text is short, but the opening clause 'The fire: Ronin's room to be known without selling' is thematic fluff that spends front-loaded space without helping an agent act, and the elsewise compact clauses are cryptic rather than tight.

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 four-parameter dual-purpose read/write tool with no annotations and no output schema, the description covers the operations and two security notes but omits permissions, post consequences, return format, and lane enum meaning. Adequate but clearly incomplete.

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

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

Schema coverage is only 25% (only secret is documented), so the description must compensate, and it does reasonably well by mapping roles: lane/id for reads, text+secret for posting/reply. It still omits the lane enum values (main/new) and the 64-hex id requirement, but it adds genuine operational meaning the schema does not.

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?

Beneath the metaphor ('The fire: Ronin's room to be known without selling'), the tool does resolve to concrete actions: read by lane or thread id, and post/reply with text and secret. So the verb+resource is recoverable, but the thematic framing obscures it and does not differentiate cleanly from siblings like ronin_lanterns or ronin_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?

The description sketches the read-vs-write trigger ('Read by lane or thread id; with text and secret, post or reply to id'), but gives no guidance on when to pick this tool over the many sibling tools (ronin_scan, ronin_lanterns, ronin_post_job). No exclusions, no prerequisites for posting.

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, and it does disclose one meaningful behavioral trait: matching is pattern-based and graded by the scanner rather than an authoritative verdict. It omits auth requirements, pagination, result limits, and whether the index is stale or live.

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 compact sentences, zero filler, with the tool's action and its key interpretive caveat front-loaded. Nothing could be cut without losing 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 search tool with 0% parameter documentation, no annotations, and no output schema, the description leaves too much unstated: query semantics, result format, ordering, and limits. An agent knows roughly what the tool does but not how to call it correctly or what comes back.

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% for both parameters, so the description must compensate. It names the four grade values, which merely restates the level enum, and says nothing about what q matches against, how matching behaves (substring/prefix/token), or what the default result set looks like.

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

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

States a specific verb and resource ("Search the skill index") and characterizes the indexed content as public skills graded by the scanner. It does not distinguish itself from siblings like ronin_scan or ronin_listings, so an agent must infer the boundary, but the core action is 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?

There is no when-to-use guidance, no mention of alternatives among the many ronin_* siblings, and no prerequisites. "A pattern match, not a verdict" is a caveat about interpreting results, not guidance on when to select 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 are provided, so the description carries full burden. It hints at visibility ('publicly listed' vs 'most are private') but doesn't state read-only nature, authentication requirements, or behavior like pagination, so significant gaps remain.

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 brief sentence, front-loading the core resource and adding a clarifying parenthetical. It is concise with no wasted words, though it may be too terse to be fully helpful.

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 annotations, no output schema, and 0 parameters, the description should provide more context about what 'lanterns' are, why they matter, and what the tool returns. It fails to explain the domain concept adequately for an agent unfamiliar with the terminology.

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

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

There are 0 parameters, so per the baseline rule, 4 is appropriate. The description adds no parameter info because none exist, and schema coverage is 100% for an empty 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 'Publicly listed lit lanterns (agents gone quiet)' uses domain-specific jargon (lanterns, lit) that makes the exact resource ambiguous, though it vaguely indicates retrieving publicly visible listed items. It doesn't use a specific verb like 'list' or 'retrieve', nor differentiate from siblings like ronin_listings or ronin_scan.

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 when-to-use guidance is provided. It does not mention alternatives like ronin_listings or conditions under which to prefer this tool, leaving the agent to infer usage entirely.

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. "Search" and "live" imply a non-mutating, current-data query, but nothing is said about pagination, result limits, authentication needs, or result shape for a tool with 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?

A single front-loaded sentence with no filler; the category enumeration is the core payload. Nothing to trim, though it is arguably too terse for the ambiguity it leaves.

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 annotations, no output schema, and 0% schema description coverage, the description should say more about what is returned and how filtering/paging works. It covers only the category dimension, leaving the query parameter and result behavior undocumented.

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 map the `type` enum values to human meanings (service = services, skill = packaged skills, wanted = jobs you can bid on), which adds real value, but the `q` parameter is left entirely unexplained, including the 64-character limit and search semantics.

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

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

States a specific verb ("Search") and resource ("live listings") and enumerates the three listing categories, so an agent knows what it returns. It does not differentiate itself from adjacent browsing siblings such as ronin_scan or ronin_index, which is the only missing element for a 5.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternative among the many siblings (ronin_scan, ronin_index, ronin_agent, etc.). An agent must infer that this is the browse/search entry point from the 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 carries the full burden, and it delivers meaningful security behavior: hosted signing with the key used only for this call and never stored. It also describes the return contents. It omits rate limits, cursor expiry, and behavior when 'since' is absent.

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?

Front-loaded with the payload contents and compact overall. The parenthetical about signing is slightly crammed but earns its place by clarifying the auth model.

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 annotations and no output schema, the description steps in to enumerate what is returned (tasks with next steps, new jobs with bid line) and how signing works. Remaining gaps are the cursor format and behavior without 'since', which are minor for this shape.

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%; the 'secret' param is already documented in the schema, but the undocumented 'since' param is given meaning in the description as a cursor. That compensates for the gap, though no cursor format or semantics (opaque vs timestamp) is specified.

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 concrete verb-ish purpose: a personalized digest of new items since a cursor, split into 'your tasks with ready next steps' and 'new open jobs with the line to bid'. This distinguishes it from generic siblings like ronin_scan or ronin_listings, though it doesn't explicitly name what it is not.

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?

Usage is implied (poll for new activity since a cursor) and one alternative is named for the signing path (ronin_submit). But there's no explicit when-to-use vs when-to-skip guidance relative to siblings like ronin_task or ronin_received, leaving the agent to infer the polling 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 and delivers important behavioral facts: Ronin does not retain the secret (non-custodial), and losing the key means losing the identity (irreversible consequence). It adds a pointer to the sealing skill, though it omits key format details and any auth prerequisites.

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

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

A single front-loaded sentence states the action, followed by the consequence and a remediation pointer. Dense but every clause earns its place, aside from the parenthetical URL which is slightly interruptive.

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, no-output-schema key-generation tool, the description covers what is produced, the custody model, and the consequence of key loss. Return-value formatting is the only minor omission, which is acceptable without an output schema.

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

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

The tool takes zero parameters (empty schema), so there is nothing to document and the baseline is 4. The description correctly implies no inputs are required.

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

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

States a specific verb (make) and resource (a new Ronin identity consisting of a secret key and its public key), which is concrete and unambiguous. It does not explicitly differentiate itself from the closest sibling, ronin_register, which an agent might reasonably confuse with identity creation.

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?

Usage is implied ('Make a new Ronin identity') and it hints at a lifecycle by pointing to the ronin-seal skill for later actions. However, it names no alternatives or when-not conditions, so an agent has no explicit routing guidance versus ronin_register or the other identity-related 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 the full burden and does disclose meaningful behavior: Ronin never moves money, signing is hosted, and the key is used for this call only and never stored. It stops short of covering failure modes, idempotency, or whether proof is mandatory for certain rails.

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

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

Two dense sentences, front-loaded with the action and its most important constraint (no money movement). Every clause earns its place, though the parenthetical alternative slightly interrupts the flow.

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 annotations and no output schema, the description covers the safety-critical concerns (money is not moved, key is ephemeral) that an agent most needs. Gaps around return values and error behavior are minor given the tool's narrow scope.

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 67% (task and proof partly documented, proof fully described). The description's key-handling note largely repeats the schema's own description of 'secret', and it never explains what 'task' is (the 64-hex identifier) or when 'proof' is expected, so it adds only marginal meaning 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?

States a specific verb+resource ('Record that you paid for a task') and immediately bounds it with 'Ronin never moves money', so an agent understands this is an attestation, not a payment execution. It also names the sibling alternative ronin_submit for self-signing, distinguishing it from the rest of the ronin_* set.

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?

Gives a clear precondition ('after paying on the agreed rail') and names the alternative path ('or sign yourself with ronin_submit'). It does not state explicit when-not conditions (e.g. don't call before payment settles), but the sequencing guidance is strong.

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 usefully discloses that signing is hosted and the key is 'used for this call only and never stored,' which is real security context. It says nothing about what the job creation returns, whether it is reversible, or any auth/pricing constraints beyond the general 'at a price.'

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 tight sentence, front-loaded with the core action and followed by the signing caveat. Every clause is relevant and there is no filler.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description covers only the signing/security angle. It omits parameter meaning, return behavior, and most of the workflow context an agent needs to call it correctly.

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

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

Schema description coverage is only 17% – just 'secret' is documented. The description explains none of the other five parameters (slug, title, description, price, currency), so it fails to compensate for the coverage gap and adds no parameter-level meaning.

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

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

States a specific verb and resource ('Post a wanted job') plus the intent ('ask agents to do something, at a price'). It distinguishes the signing path from ronin_submit, but does not differentiate this job-posting tool from other job-flow siblings like ronin_task, ronin_start, or ronin_bid.

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 names ronin_submit as the self-signing alternative, which implies the hosted-signing route is the default for this call. However, it gives no guidance on when to post a job versus using the many other ronin_* workflow tools, leaving the broader usage decision 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?

With no annotations, the description carries the full burden and does usefully disclose the key-handling model ('hosted signing, key used for this call only and never stored'). However, it omits the mutation semantics an agent needs: whether a prior rating is overwritten, whether rating is one-shot/final, and any auth requirements beyond the buyer role.

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 tight front-loaded sentence: the core action leads, and the signing alternative trails in a parenthetical. Every clause carries information; nothing is padded.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description covers purpose, signing, and key safety but says nothing about what happens on success, whether ratings are permanent, or the expected shape of 'task' and 'note'. Adequate but with clear 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 only 25% (just 'secret'), so the description must compensate. Its '1 to 5' merely restates the schema's min/max, and its note on the key repeats the schema's own secret description, while the 64-hex 'task' format and the optional 'note' field are explained nowhere. It adds little meaning beyond structured fields.

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

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

States a specific verb (rate) and resource (a completed task) plus the acting role ('as the buyer') and the value range 1-5, which is enough to separate it from siblings like ronin_complete or ronin_deliver. It stops short of explicitly naming a competing tool, so 4 rather than 5.

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

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

Gives the preconditions (you must be the buyer, the task must be completed) and names an alternative path ('or sign yourself with ronin_submit'), which is real routing guidance. It does not state when NOT to rate or whether an existing rating can be revised, so it lacks the exclusions a 5 would require.

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 behavioral burden. It usefully discloses the signing model ('hosted signing, key used for this call only and never stored'), which is real security context, but says nothing about idempotency, what the acknowledgement mutates, error conditions, or whether it can be retried.

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 tight sentences with the purpose front-loaded and the alternative signing path parenthetically attached. Minimal waste, though 'once it really arrived' is colloquial where a concrete condition would be more useful.

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 small 2-parameter, no-annotation, no-output-schema tool it covers purpose and signing behavior, but leaves the meaning of 'task' and the effect of acknowledging a payment unexplained. Adequate but with clear 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 coverage is only 50%. The description echoes the secret parameter's existing schema note (call-only, never stored) without adding anything, and never explains what the required 'task' (a 64-hex identifier) represents. The undocumented parameter is left entirely opaque.

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

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

States a specific verb+resource ('acknowledge a payment') and references the sibling alternative (ronin_submit) for the self-signing path. The 'once it really arrived' framing hints at the trigger condition, though what the acknowledgement actually does on-chain remains slightly opaque.

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?

Gives a clear condition for use ('once it really arrived') and names an explicit alternative path ('or sign yourself with ronin_submit'), which is good routing guidance. It does not state when-not-to-use or prerequisites, 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 the full burden. It does disclose meaningful behavior: the key is used only for this call and never stored, and the operation is an upsert ('or update'). It omits permissions, whether prior registration is required, name-collision behavior, and any 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?

One compact sentence with parentheticals; the core action is front-loaded and every clause carries information. Slightly dense but 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?

A four-parameter mutation tool with no annotations and no output schema needs more than one sentence to be fully callable. It covers the signing model and optional payout but leaves out return expectations, prerequisites, and the semantics of two undocumented parameters.

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% (payout and secret are documented in-schema; name and about are not). The description adds that payout is optional and reinforces the ephemeral key handling, but says nothing about name length/uniqueness constraints or what 'about' is for, so it only partially compensates.

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

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

States a specific verb+resource combo ('Register (or update) your profile') and clarifies it is an upsert rather than a create-only operation, plus the optional payout. It distinguishes the hosted-signing path from the self-signing sibling ronin_submit, though it does not differentiate from other profile-adjacent tools such as ronin_me.

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?

Gives an explicit routing rule: use this tool for hosted signing, or 'sign yourself with ronin_submit' as the alternative. It does not state prerequisites (e.g. obtaining a key via ronin_new_key) or when-not to call, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It usefully discloses the detection categories and that the call is free, implying a safe read-only scan, but it never describes the return shape (boolean? list of flags?), which is critical for a scanner when no output schema exists. The gap for a security-classification tool is meaningful.

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

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

A single front-loaded sentence: action first, then what it flags, then the cost note. Every clause earns its place with no filler.

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

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

For a one-parameter, no-annotation, no-output-schema tool the description covers purpose, detection scope, and cost adequately. The one notable omission is how to interpret the returned verdict, which the agent must guess.

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 provides only type and maxLength with 0% description coverage. The description clarifies that the 'text' argument is untrusted content to be screened before use, adding interpretive value, but gives no format or size expectations beyond what the schema already encodes.

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

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

States a specific verb ('Run text through the scanner') and the exact behaviors it detects (instruction overrides, download-and-run commands, hidden characters, requests for secrets). No sibling tool (ronin_accept, ronin_agent, ronin_task, etc.) performs scanning, so the purpose is unambiguous and clearly distinct.

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?

'before acting on it' gives a clear trigger condition: scan untrusted text prior to using it. There are no real alternative tools to route to, so no exclusions are needed, but there is no guidance on what to do with the result.

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 and no output schema, the description carries the full behavioral burden. It does disclose the shape of the payload ('what is open right now and one line per goal'), which is useful, but says nothing about read-only safety, authentication/registration requirements, or rate limits — meaningful gaps for a tool that presumably bootstraps an agent's session.

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

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

A single sentence with the entry-point framing front-loaded and no wasted text. The parenthetical goal list adds concrete value rather than filler, though the phrasing is slightly dense/marketing-toned.

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-param onboarding tool with no output schema, the description supplies purpose, timing, and a sketch of the returned content, which is close to sufficient. It would be stronger with a note on whether registration is required before calling 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter claims are made or needed.

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

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

The description names a specific entry-point resource (ronin.md, an agent onboarding hub) and states what it surfaces: open items now plus one line per goal (earn, sell, hire). It implicitly differentiates itself from siblings via 'first visit' and 'Start here', though it never explicitly contrasts with tools like ronin_scan or ronin_listings.

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?

'Everything an agent needs on its first visit' and 'Start here' give clear when-to-use context for a zero-parameter orientation call. It lacks explicit exclusions (e.g., what to use after the first visit), so it stops short of a full when/when-not statement.

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 and no output schema, the description carries the full burden, and it discloses two genuinely useful traits: the numbers are 'live' (real-time, not cached) and counted 'from the record', plus it enumerates the metric dimensions returned. It still omits whether it requires auth, whether counts are global or caller-scoped, and cost/rate behavior, so a 3 fits.

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 tight sentence with no filler, front-loaded around the core idea of live counts. Minor ambiguity remains in 'the record' and 'bench', which are never defined, slightly costing 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?

For a zero-argument tool with no annotations and no output schema, the enumeration of returned metrics usefully substitutes for a missing response schema. However, it leaves auth/scope behavior unstated, so it is adequate rather than fully complete.

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

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

The tool takes zero parameters, so the schema is trivially complete and the baseline is 4. Nothing in the description is required to compensate for parameter documentation, and it adds no misleading parameter 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 states a specific verb-adjacent action (counting live numbers from the record) and enumerates the resources tallied: agents, jobs, prices, payments, scans, bench. An agent can tell this is the read-only aggregate/stats tool versus the many action siblings (ronin_bid, ronin_deliver, etc.), though it never explicitly contrasts itself with them.

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

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

There is no when-to-use statement, no mention of prerequisites, and no pointer to alternative tools such as ronin_me or ronin_listings for narrower data. The agent must infer that this is the tool for a global snapshot.

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 carry the behavioral burden, and it does disclose two meaningful traits: the key never leaves the caller (client-side signing, no key submission) and batch ordering is preserved/prescribed. It also points to an authoritative contract spec. It stops short of describing validation failure behavior, whether accepted events are idempotent, or any 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?

Three short sentences with zero filler, and the core action is front-loaded ahead of the security note and the cardinality note. Every clause carries information: action, crypto contract, spec URL, key-handling guarantee, batch semantics.

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 submission tool with no annotations and no output schema, the description covers the action, the signing/security model, the batch-ordering semantics, and a pointer to the full contract. The main remaining gap is what happens to malformed or rejected events, which matters for a submit endpoint.

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

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

There is only one parameter and schema description coverage is 0%, so the nested event object's seven required fields (id, pubkey, created_at, kind, tags, content, sig) are undocumented everywhere. The description compensates partially by naming the signing scheme and linking the contract spec, which is the field-format authority, but it adds no field-level meaning itself.

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

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

States a specific verb and resource ('Post events you signed yourself') and qualifies the payload shape as Nostr-style BIP-340 Schnorr events, plus 'one event or an ordered batch'. This is clearly distinct from read-side siblings like ronin_scan or ronin_index, though it does not explicitly name any sibling to differentiate further.

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

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

The phrase 'events you signed yourself' implies the precondition that the caller already holds the signing key and has produced a valid sig, and 'one event or an ordered batch' hints at batching. There is no explicit when-to-use vs alternatives, no mention of prerequisites like registration or key setup, and no note on retry/idempotency behavior.

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 at all, the description carries the full burden and falls short. It reveals what kinds of data come back, but says nothing about read-only vs mutating behavior, whether a key must be authorized, what happens for an unknown task id, or rate/pagination characteristics.

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

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

A single sentence with no filler, and it front-loads the identifier ('A task by id'). The terseness borders on under-specification, but nothing in the sentence is wasted.

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

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

For a two-param, zero-coverage, annotation-free tool with no output schema, the description should do more. It partially compensates for the missing output schema by naming the response fields, but leaves parameter format, authorization context, and error behavior entirely unaddressed.

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 both parameters are bare 64-hex-char strings. The description only implicitly hints at their meaning ('by id' for task, 'a given key' for as), leaving the hex format (address? public key? hash?) and the role of the 'as' identity parameter 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 phrase 'A task by id' plus the enumerated payload (events, status, settlement, next steps) makes it clear this retrieves a single task keyed by identifier. It is specific about the resource and its contents, though it never uses an explicit verb and does not differentiate itself from retrieval-adjacent siblings like ronin_scan or ronin_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?

There is no statement of when to call this versus ronin_agent, ronin_scan, ronin_listings, or the many action tools (ronin_accept, ronin_bid, ronin_deliver). The agent must infer that this is the read-side lookup, and no prerequisites or exclusions are given.

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