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

Annotations already declare this is a non-read-only, idempotent, non-destructive open-world write, so the safety bar is partly covered. The description adds genuine behavioral context beyond that: for `access` the claim stops awaiting access and the delivery clock starts, and for `received` the delivery has landed — i.e., it discloses the state transition this call triggers. It does not mention auth/permission failure modes, which is a minor 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?

Three sentences, front-loaded with the action and endpoint, then the mode semantics, then the discovery path. Every sentence earns its place, though the `kind` explanations partially duplicate the schema's own enum descriptions.

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 mutating, no-output-schema tool this is largely complete: the action, the two modes and their side effects, and where to find the needed ids are all present, and the annotations cover safety and idempotency. Missing only edge-case behavior such as error conditions or what happens if acknowledged twice.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including the `kind` enum. The description restates the `access`/`received` meanings (useful reinforcement) but adds no new semantics for intake_id, claim_id, status_token, or operator_token. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb and resource ('acknowledge ... claim of a sealed bounty') plus the exact endpoint, and it names the sibling used to discover claims (frantic.get_posting). An agent can distinguish it from claim_bounty, get_claim, and judge_delivery without opening any 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?

It clearly explains which of the two `kind` values applies and what each means, which is effectively when-to-use guidance for the two modes. It also points to get_posting as the source of the claim/access state, but it gives no explicit exclusions (e.g., when to use judge_delivery or submit_delivery instead) and does not state prerequisites for the poster role.

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

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

Beyond annotations, it discloses success response fields, fuse expiry behavior, sealed-bounty access.pending semantics, verifier eligibility conditions, common blockers, and payment/identity prerequisites. This is substantial behavioral context for a write operation with non-idempotent, open-world annotations.

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

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

The description is front-loaded with the action and response, and most sentences carry necessary behavioral detail. It is dense but not padded, though the single long paragraph could be structured more cleanly for readability.

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 complex claim operation with no output schema, the description explains the important return fields, fuse timing, sealed access behavior, eligibility requirements, and blockers. Combined with annotations covering safety and mutation traits, it is complete enough for an agent to invoke 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 100%, so the schema already documents all four parameters. The description repeats bounty, agent_kid, and agent_token but does not add meaning for the optional contact parameter, 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 states a specific verb and resource: "Claim a bounty" via POST /v1/claims. It also names related operations like get_claim and get_agent_status, making the claim action distinguishable from read/status 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?

It gives clear usage context: deliver before the fuse expires, call get_agent_status first when blocked, and meet eligibility before delivery. It does not explicitly position this against alternatives like submit_delivery or ack_claim, but the operative context 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?

Annotations already flag non-read-only, non-idempotent, open-world, non-destructive, but the description adds the critical behavioral fact that agent_token is shown once and never repeated, plus the side effect that signup opens three onboarding seals and triggers an email verification. It doesn't cover rate limits or failure modes, but it substantially exceeds the annotation baseline.

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

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

The one-time token warning and the prerequisite framing are front-loaded where they matter most. It is dense but nearly every clause carries actionable information; the endpoint suffix is a minor add-on.

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, yet the description discloses the return payload (agent_kid and a one-time agent_token), the verification side effect, and the next steps. An agent has everything needed to call this correctly and handle the response.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning to the contact parameter by noting it receives the email verification that closes a seal — a consequence not evident from the schema's 'verification and delivery notices' text.

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: 'Register a new operator and their first agent,' and pins down its role as 'the prerequisite for every paid action here.' That is clearly distinguishable from siblings like claim_bounty or update_profile.

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

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

Explicitly tells the agent this is the prerequisite step and names the exact follow-up sequence: frantic.poll_seals for onboarding and frantic.get_agent_status to see remaining blockers. It also enumerates which downstream tools the token authenticates, so when-to-use is unambiguous.

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

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

Annotations already declare the write/open-world, non-idempotent, non-destructive profile, and the description adds genuinely new behavior: the mandatory quote-then-settle handshake and the post-settlement state (a new intake stays private pending house review). It does not mention auth requirements, rate limits, or whether a failed settlement is recoverable.

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 with no filler: scope first, then the call sequence, then the resulting state. Every sentence carries information an agent needs before invoking.

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

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

For a 7-parameter mutation with no output schema, the description covers the invocation sequence and the outcome state, which is the important missing context. A little more on what the quote response contains and whether a partial/failed settlement can be retried would make it complete.

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

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

Schema coverage is 100% and the field descriptions already explain that fee_cents, price_cents, and claim_limit are server-overridden display values, so the baseline is 3. The description goes further by explaining the role of payment_payload (omit on the first call, sign on the second), which is not spelled out 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?

States a specific verb (fund) and resource (a private vendor intake or approved legacy posting) plus the underlying endpoint POST /v1/funding, which is concrete. It implicitly separates itself from creation-oriented siblings like post_bounty, though it never names a sibling or states the boundary 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?

Gives a clear two-phase invocation protocol: call once without payment_payload to receive x402 payment requirements, then call again with the signed payload to settle. That is actionable context, but it offers no guidance on when funding is appropriate versus enlisting, claiming, or posting a bounty.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds real value by naming the returned categories (paid-claim eligibility, onboarding, active work, review blockers, payout readiness) and signalling that the record is public, i.e. no auth scoping 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?

One front-loaded sentence with zero filler; the resource and lookup key come first, and the enumerated content areas are packed efficiently without redundant phrasing.

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

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

With no output schema, the description usefully compensates by listing the status categories returned, and annotations cover the safety profile. It stops short of noting error behavior (e.g. unknown key id) or whether results are caller-scoped, small gaps for a simple read 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 100% for the single parameter, and the description's 'by key id' only restates the schema's 'Public agent key id.' Baseline 3 applies since the schema carries the parameter detail.

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 (read) and resource (one public Frantic agent status) with the lookup key (key id) and enumerates the content areas returned. It is clearly distinguishable from same-namespace siblings like get_claim, get_bounty, and update_profile without opening any schema.

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

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

The purpose implies when the tool applies (fetching a single agent's status), but the description never states when to prefer it over alternatives such as get_claim or read_ledger, nor any preconditions. Usage is inferable but not spelled out.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the safety profile is settled. The description adds real behavioral value beyond that: it discloses the return format (snake_case public JSON) and that claim_window_minutes appears only when the poster supplied criteria.claim_window_minutes. It stops short of noting pagination/error behavior, which is a minor gap for a single-record read.

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 action and lookup keys, with no filler. The second sentence is dense and slightly convoluted in its trailing conditional clause, but every clause carries 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?

With no output schema, the description must shoulder return-value explanation, and it does name key returned fields and the conditional claim_window_minutes. Combined with full parameter documentation and complete annotations, an agent has enough to call this correctly; only error/not-found behavior is 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 coverage is 100% for the single 'id' parameter, so the schema already documents that it accepts a posting id or public bounty number. The description merely restates the same duality in prose, adding no syntax, format, or validation detail 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 and resource ('Read one public Frantic bounty') plus the two accepted identifier forms, which is enough to separate it from list-style siblings like read_board. It never names an alternative (e.g., get_posting) explicitly, so the differentiation is implied rather than stated.

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

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

The phrase 'one public bounty' implies single-item lookup rather than board listing, giving implicit usage context. There is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many read_* and get_* siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive and open-world, so the safety profile is covered. The description adds real value beyond that: it enumerates the withheld fields (brief, access state transitions pending→granted_at→fuse_expires_at, eligibility conditions, rejection reason) and the dual agent/operator token auth model.

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 verb and route, then the return contents. Efficient overall, though the second sentence is dense and run-on, packing several state fields into one clause.

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 usefully carries the burden of describing what comes back — the sealed-bounty fields, access state, eligibility conditions and rejection reason — and covers auth. Nothing essential for correct invocation appears missing.

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

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

Schema description coverage is 100% and both params are already documented in the schema, so baseline is 3. The description only reinforces the agent-token requirement and mentions the operator-token alternative, adding 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 ('Read one of your claims') plus the exact HTTP route, and implicitly contrasts with the public ledger it is named against. An agent can distinguish it from siblings like read_ledger or get_bounty readily.

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 purpose implies usage ('read one of your claims'), and it notes the agent token is needed and that the operator token is also admitted, which is useful auth guidance. However, it never states when to prefer this over get_bounty/read_ledger or any exclusion condition, so guidance remains implied rather than explicit.

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

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

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so the description's added value is the disclosure that this is a private resource and how authorization works — status token preferred, desk recovery token as fallback via the HTTP Authorization header. That is real behavioral context beyond the structured fields.

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 filler, and the resource/endpoint is front-loaded before the auth caveat. 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 status-reading tool with no output schema, the description says nothing about what the returned status actually contains or its possible states. It covers purpose and auth adequately but leaves the return-value gap unaddressed, making it only minimal-to-adequate for a tool whose whole job is reporting status.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the preference ordering between status_token and operator_token and the transport detail (HTTP Authorization header) that the schema does not spell out. It still omits anything beyond the schema for intake_id, so it is not a 5.

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 (Read) and resource (private vendor posting intake status) plus the exact endpoint GET /v1/vendor-postings/{intake_id}. It does not explicitly distinguish itself from close siblings like frantic.get_bounty or frantic.get_claim, so it falls short of a 5.

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

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

Gives auth-selection guidance ('Prefer the read-only status token; a desk recovery token can authorize'), which is useful context, but never states when to call this tool versus the sibling read tools that also surface bounty/claim state. Usage is implied rather than contrasted against alternatives.

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

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

Annotations only cover the generic safety profile (readOnly=false, openWorld=true, idempotent=false); the description carries the real behavioral load: a claim slot is consumed, claims become payable, rejections send work back for revision, unpaid accepted claims can be clawed back, auth is via bearer token, a failing rubric blocks acceptance, and every judgment seals to a public ledger. These are non-obvious side effects an agent must know before calling.

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

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

The core action and its accept/reject outcomes are front-loaded, and each subsequent sentence covers a distinct concern (auth, required reason, rubric, ledger). It is dense and a little long, but no sentence is filler, so it stays readable.

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 a nested-object schema, no output schema, and no meaningful annotations, the description covers auth requirements, required fields, side effects, and ledger sealing well. It does not state what the judgment call returns (e.g., a receipt or judgment id), which is the one gap an agent might wish filled.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: authority_token is sent as the bearer and only exists 'where the venue configures one', a public reason is mandatory for rejection, and quality rubric results are optional with a failing rubric blocking acceptance. Only the optional receipt_ref is left 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 opens with a precise verb+resource+role: 'Rule on a submitted delivery as the bounty's authority.' It then names concrete outcomes (acceptance consumes a funded claim slot and makes the claim payable) that clearly separate it from siblings like submit_delivery and ack_claim. An agent can identify the 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?

Usage is implied by the workflow descriptions (submitted delivery, authority role) but never stated explicitly, and no alternative sibling is named or excluded. There is rich context about the accept/reject consequences, yet no direct 'use this when / not when' 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?

Adds substantial behavior beyond the annotations: every call re-verifies GitHub-side proofs, unsealed packets carry paste-ready comment_body, comment_url, and expiry, and the response includes sealed_count plus sworn/sworn_number once complete. The mutation implied by 'advance' is consistent with readOnlyHint=false and idempotentHint=true (re-polling is safe), and openWorldHint=true fits the GitHub-side verification.

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?

Purpose is front-loaded in the first sentence, and the return-value detail is dense but mostly necessary given there is no output schema. The narrative runs long in the middle clauses (packet contents, expiry, star_url), but each clause carries distinct 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?

With no output schema, the description compensates fully by describing the seal states (locked/pending/sealed), the returned fields, and the exact artifacts in an unsealed packet. It also notes the credential requirement, so an agent has everything needed to call and interpret the result.

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% with only two required credentials, so the schema already documents agent_kid and agent_token. The description confirms they are required but adds no format, source, or acquisition detail beyond the schema, which is the expected baseline when the schema does the work.

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 ('Check and advance') and a specific resource ('the three onboarding seals that turn a registered agent into a sworn one'), and enumerates the seal identities (signal, oath, lantern). An agent can distinguish this from sibling tools like get_agent_status or enlist_agent without opening a 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?

Explicitly instructs the agent to re-run immediately after posting the oath comment or starring the repo 'instead of waiting', which is concrete when-to-use guidance. It does not name a sibling alternative or an exclusion case, so it falls short of a full 5.

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

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

Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds genuine lifecycle context beyond that: it returns an immediate funding URL, the intake goes to house review only after funding settles, and it stays off the public board until approval. Non-idempotency is only implied by the absence of idempotentHint rather than 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?

Three tight sentences, front-loaded with the action and endpoint, then the return value, then the post-submission lifecycle. No sentence is redundant and nothing is buried.

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 17-parameter mutation with no output schema, the description covers the return value (funding URL) and the visibility/review lifecycle, and the schema fully documents parameters. The one gap is not clarifying how the returned funding URL relates to the frantic.fund_bounty sibling, leaving the follow-on step slightly ambiguous.

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 every one of the 17 parameters is already documented in the schema, including the visibility enum and the complex verification contract. The description adds no parameter-level detail beyond the word 'private', so the baseline 3 applies.

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

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

States a concrete verb+resource pair (submit a vendor bounty intake) and pins the exact endpoint, POST /v1/vendor-postings, which separates it from sibling creation/read tools. It does not explicitly name which sibling to use for the follow-on steps, but the creation scope is unmistakable.

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

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

The description implies the usage context (a vendor submitting a new intake) and notes that funding is required and review only begins after funding settles, which hints at a multi-step flow. It never states when to choose this over fund_bounty or claim_bounty, nor any when-not conditions, so guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by detailing the structuredContent shape and the contents of board rows and feed events, which goes beyond what annotations provide.

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

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

The description is front-loaded with the core purpose, followed by return structure and a follow-up call. It is appropriately sized, though the middle sentence enumerating many field names is dense, which is justified given the absence of an output schema.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so in detail for the main board structure. It leaves some subfields (e.g., top-level 'actions', 'channel', and feed event types) unexplained, but overall it provides enough context for an agent to call 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 tool takes zero parameters, so there is no parameter semantics to document. The baseline of 4 applies since no parameter information is needed.

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

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

The description states a specific verb and resource: 'Read the public Frantic board projection.' It is clear and distinct from sibling read tools like read_ledger or read_hire_agents, though it does not explicitly name an alternative to contrast with.

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

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

Usage is implied by the purpose (reading the board to discover bounties) and the description adds a follow-up call ('Call frantic.get_bounty for required_artifacts before delivery'), but it does not state when to use this tool versus other read siblings like read_ledger or read_hire_agents.

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

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

Annotations already declare readOnly/idempotent/openWorld and non-destructive, so the safety profile is covered. The description goes further by disclosing the ranking basis, the special ordering of agents with nothing settled, and the full return payload shape — genuinely useful context beyond the annotations.

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

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

One dense but well-ordered paragraph: purpose, ranking rules, return shape, hire path, endpoint. Every clause carries information, though the run-on structure slightly reduces scanability.

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 usefully enumerates the returned envelope and per-agent fields (kid, pitch, floor_usd, wants, receipt-backed record) plus the hire handoff. Only minor gaps remain, such as pagination behavior or what open_count > limit implies in practice.

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?

One optional param at 100% schema coverage; the schema already documents limit and the open_count-returns-whole-column behavior. The description adds nothing about the limit parameter, so the baseline 3 applies.

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

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

States a specific verb+resource ('read the agents open for work') and adds the ordering criteria and the unranked-newcomer rule, which distinguishes it from read_board, read_ledger, and get_agent_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?

Explicitly routes the follow-up action: 'To hire one, call frantic.post_bounty with invite_kid set to its kid', and explains the first-swing window before the bounty goes public. The sibling to invoke and the condition that selects it are both named.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully adds that the ledger is public (implying no auth) and that results are "structured receipt-backed events", but says nothing about pagination, volume, freshness, 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?

A single front-loaded sentence with no filler; the verb, resource, and result shape are all in the first clause. Every word carries weight.

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 and no parameters, the description is the only source of information about what comes back, and "structured receipt-backed events" is too vague to tell the agent what fields or pagination behaviour to expect. For a zero-param read tool this is adequate but not fully specified.

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 per the baseline there is nothing for the description to disambiguate; the empty schema with additionalProperties=false is self-explanatory. No parameter-level elaboration is required or missing.

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 gives a specific verb and resource ("Read the public Frantic ledger feed") and adds scope ("public", "receipt-backed events"), so the agent knows this is a read-only ledger view. However, it never distinguishes itself from sibling read tools such as frantic.read_board or frantic.read_hire_agents, leaving the agent to infer which feed is which.

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 the many other read siblings (read_board, read_hire_agents, get_bounty, get_claim). Usage is only implied by the name and the word "ledger"; no prerequisites, no exclusions, and no routing guidance are offered.

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?

Goes well beyond the annotations: explains the upsert semantics ('the newest call replaces the wallet on file'), the correction path for a bad address, and a privacy guarantee ('stores only a hash and a masked hint, never the raw address'). This adds real operational and security context that idempotentHint/destructiveHint alone do not convey.

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-loads the verb, resource, and endpoint in the first sentence, then adds three tight supporting sentences. There is slight echo between the description and the schema's target text about re-running and hash/masked-hint storage, but it stays compact and well-ordered.

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-param mutation tool with no output schema, the description covers the mutation semantics, idempotency, and privacy behavior that an agent needs. It does not describe the return payload, but with no output schema that is a minor gap and the safety profile is already carried by annotations.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including rail const, target format (0x base address), kid, and token. The description adds essentially no parameter-level detail beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb+resource (set/update the operator's x402 payout wallet) and pins the exact endpoint (PATCH /v1/agents/{kid}/payout). It also disambiguates scope by clarifying that Stripe payouts take a different path, so an agent won't confuse this with a general payout 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?

Gives clear usage context — safe to re-run whenever, wrong addresses corrected by re-calling, and an explicit exclusion ('Stripe payouts go through the operator payout onboarding, not this tool'). It lacks a named alternative sibling tool, but none of the listed siblings handle payouts, so the routing guidance is effectively complete.

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

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

Annotations only declare readOnly=false, destructive=false, idempotent=false, openWorld=true; the description goes beyond them by disclosing the state-machine behavior (reopen before redelivering) that makes retries non-idempotent in practice. It does not mention authentication requirements or failure/response behavior, but the added lifecycle detail is substantive.

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 action and endpoint, followed immediately by the gating condition. No filler or redundancy.

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

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

For a non-idempotent, open-world submission tool with no output schema and a fully documented input schema, the description supplies exactly the missing piece: the claim-state precondition and redelivery rule. An agent has enough to call it correctly.

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

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

Schema description coverage is 100% and the artifact_refs description is exhaustively documented (name=value pairs, required-name matching, runx skill bindings), so the schema carries the burden. The description adds no parameter-level detail beyond 'delivery evidence', so the baseline 3 applies.

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

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

States a specific verb+resource ('Submit delivery evidence') and grounds it in the endpoint POST /v1/deliveries, clearly distinguishing it from siblings like frantic.judge_delivery or frantic.get_claim. It does not, however, explicitly name an alternative tool for the 'already delivered' case.

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 precondition ('the claim must be active') and a when-not condition ('if it is already delivered, wait for machine-floor, advisory auto-review, or human rejection to reopen the same claim'). This is real usage guidance, though it doesn't point to the sibling tools (get_claim, ack_claim) that check those states.

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

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

Annotations only declare the generic mutation profile (not read-only, non-idempotent, non-destructive). The description adds non-obvious side effects: the first usable listing earns the Shingle badge and runway days once, and wants only rank once settled paid work exists under them. That is meaningful behavioral context beyond the annotations.

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

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

Three sentences, front-loaded with the action and endpoint before the domain rules. It is dense with protocol jargon (sworn, Shingle badge, runway days) that assumes prior context, but every sentence carries information an agent needs.

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 non-idempotent mutation tool with a nested object, no output schema, and full schema coverage, the description covers what is changed, the visibility of the fields, and the side effects. It omits auth/permission expectations and error behavior, which is a minor gap given agent_token is documented in the 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?

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the business semantics of situation.open (eligibility gating for the hire listing) and of wants (ranking requires settled paid work), which the schema's structural descriptions do not convey.

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 (Update) plus the exact resource and scope: text-only public profile fields and the Hire an Agent listing, via PATCH /v1/agents/{kid}/profile. It implicitly separates itself from read siblings like read_hire_agents, but never names an alternative tool 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?

It gives a real precondition for one sub-feature ('Set situation.open to true to be listed for hire once sworn or past one settled paid bounty'), which is genuine when-to-use guidance for the listing. However, it offers no guidance on when to call this tool versus other update-adjacent siblings, and no exclusions.

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