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

Annotations only state coarse facts (readOnlyHint=false, idempotentHint=false); the description adds significant behavior: the response returns claim_id, claim_ref, fuse_expires_at, fuse_minutes, and state; it reveals that an undelivered claim can be released after fuse expiration; it enumerates common blockers; and it gives authentication requirements. This is exactly the behavioral detail an agent needs, and nothing contradicts the annotations.

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

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

The definition is information-dense and front-loaded with the HTTP call and required parameters; every subsequent sentence contributes a distinct fact (response shape, fuse semantics, error list, eligibility tiers). It is long, but the layered eligibility rules require the detail; only a bit of the error-list and requirement text could have been tightened without losing value.

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

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

With no output schema present, the description fills the gap thoroughly: it lists the exact return fields, explains the meaning of the fuse and the release behavior, covers failure modes via common blockers and tailors the guidance by bounty tier. For a mutation tool of this complexity, the agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3; schema already gives one-line descriptions for all four parameters. The description adds meaning beyond that by tying agent_token to a registered agent, linking the optional contact/identity context to verified-contact eligibility for paid bounties, and explaining the value semantics of bounty. It does not name the contact parameter explicitly, which is the slight shortfall.

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

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

The description opens with the precise action: 'Claim a bounty through POST /v1/claims with bounty, agent_kid, and agent_token.' It uses a specific verb, names the exact resource, and is clearly distinct from siblings like post_bounty (creating a bounty), fund_bounty (financing one), get_bounty (reading one), and submit_delivery (delivering work).

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 explicit sequencing guidance: 'Call frantic.get_agent_status first when blocked,' which routes the agent to a sibling tool under a clear condition. It also encodes when-not-to-claim through graded eligibility ($0, paid up to $10, paid over $10) and contextualizes the claim lifecycle with the deliver-before-fuse rule, making the appropriate use both explicit and non-ambiguous.

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

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

The description goes well beyond the annotations, revealing that a one-time agent_token is shown only once, that it and agent_kid authenticate five specific sibling operations, and that onboarding seals are opened and email verification is sent to the contact address. These are critical side effects an agent must know before calling the tool.

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

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

The description is compact but dense, with every sentence carrying distinct value: registration, token warning, authentication scope, onboarding seals, follow-up calls, and the endpoint. It is front-loaded with the most critical facts and wastes no words.

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

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

Even with no output schema, the description explains what is returned (agent_kid and one-time agent_token), what side effects occur, how authentication works, and what the agent should do next. This is ample context for an agent to invoke the tool and handle common follow-up actions correctly.

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

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

The input schema already documents all 7 parameters with clear descriptions, so the description does not need to repeat them. It adds some operational context for 'contact' (receives email verification) and the agent/operator relationship, but it does not add meaningful semantics for the other parameters beyond what the schema provides.

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

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

The description uses a specific verb and resource: 'Register a new operator and their first agent'. It clearly positions this as the prerequisite for every paid action, which distinguishes it from the sibling tools that follow onboarding.

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 states exactly when to call this tool (before any paid action), warns that the token must be stored first, and gives explicit follow-up steps with 'Follow with frantic.poll_seals' and 'frantic.get_agent_status'. This is strong routing guidance for the agent.

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

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

Adds meaningful behavioral nuance beyond the annotations (readOnlyHint=false, idempotentHint=false): the two-stage quote-then-settle design, the server-driven quoting behavior, and that 'a new intake stays private pending house review.' No contradiction with 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, each earning its place: operation scope, two-step invoke flow, and post-settlement state effect. Front-loaded and free of 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 multi-step, financially sensitive tool without an output schema, the description covers the essentials: initial request, settlement, and resulting state (private pending review). It could specify the exact shape of the returned payment requirements, but the schema and flow guidance together are sufficient for correct invocation.

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

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

Schema coverage is 100% and several params already explain their server-overridden/ignored behavior, so the baseline is 3. The description meaningfully adds the payment_payload/payment_requirements workflow semantics (when each belongs in the call), which the schema alone does 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 ('Fund'), a clear resource scope ('private bounty intake or approved legacy posting'), and the exact endpoint (POST /v1/funding). The two-step funding flow is unique among siblings like claim_bounty or post_bounty, so the tool's identity 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?

Provides explicit sequencing guidance: call once without payment_payload to obtain x402 requirements, then call again with the signed payload to settle. This clearly prescribes the correct invocation pattern; it just stops short of explicitly ruling out sibling tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by specifying that the status is 'public' and enumerating what areas the status covers, such as onboarding, review blockers, and payout readiness.

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 one sentence, front-loaded with the primary action and resource, and contains no filler or repetition. The list of status dimensions is compact and informative.

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

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

For a simple read-only tool with one required parameter, the description is complete. The categories of status content compensate for the absence of an output schema, and the annotations cover safety and idempotence.

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

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

The input schema already fully documents the only parameter, 'kid', with 100% coverage. The description's use of 'by key id' aligns with the schema but does not add meaningful new parameter semantics beyond what a schema already says.

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

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

The description opens with a specific verb ('Read') and resource ('public Frantic agent status'), and further narrows it by key id with a clear list of what the status includes. It clearly distinguishes this from sibling tools like read_board or read_ledger.

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

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

The description clearly frames when to use the tool: to read one specific agent's status by 'kid'. It does not explicitly name alternatives or exclusions, but the resource and id requirement make the intended context unambiguous.

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

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

Annotations already mark the tool as read-only, idempotent, open-world, and non-destructive. The description meaningfully adds behavioral context by specifying the return format ('snake_case public JSON') and the conditional membership of fields such as required_artifacts, delivery_contract, and claim_window_minutes. This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded, with the core action and target in the first sentence. The second sentence earns its place by disclosing output shape and conditionally present fields. There is no filler, tautology, or irrelevant detail.

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

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

Given the tool's simplicity — one required parameter, rich annotations, and no output schema — the description provides enough detail for an agent to call it correctly and understand the response shape. It could mention what happens when a bounty is not found, but for a one-parameter read operation, the current details are largely sufficient.

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

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

With schema coverage at 100%, the schema already documents the single id parameter as 'Bounty posting id or public bounty number.' The description repeats that semantic without adding new detail, such as input format, validation rules, or examples. A baseline 3 is appropriate because the schema does the heavy lifting and the description adds little beyond restating the parameter purpose.

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

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

The description opens with a specific verb and resource: 'Read one public Frantic bounty by posting id or bounty number.' It clearly states the operation and the identifier used, making the tool's purpose unambiguous. It also distinguishes the entity (public bounty) from the general 'get_posting' sibling by emphasizing the bounty entity and public scope.

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

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

The description states what the tool does but gives no guidance on when to choose it over siblings. It does not mention alternatives like get_posting or read_board, nor any conditions that would make another tool more appropriate. The only implicit guidance is that this is a point-read operation for a single bounty, but no exclusion or recommendation is provided.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: the operation is private, it follows a GET endpoint, and it supports a specific authorization mode. It does not need to cover error handling or pagination for this simple status 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?

The description is two tight sentences with no redundant phrasing. The core action and endpoint are front-loaded, and the authorization guidance directly follows without wasted words.

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

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

For a read-only status endpoint, the description, combined with the param schemas and annotations, provides everything needed to invoke the tool correctly: path, identifier, token preference, and alternative authorization path. No critical invocation detail is missing.

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

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

Schema coverage is 100%, so the parameters are already well documented. The description adds extra operational meaning by telling the agent to prefer the read-only status token and clarifying how the operator_token is sent via the HTTP Authorization header, which goes beyond the schema 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?

The description uses a specific action verb ('Read'), a precise resource ('private vendor posting intake status'), and the exact HTTP endpoint. This makes it easy to tell apart from siblings like get_bounty or get_agent_status, even though those tools are not explicitly named.

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

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

The description conveys the intended use case well: retrieving vendor posting status. It also provides operational within-tool guidance on preferring the status token and using the desk recovery token via the Authorization header. However, it does not explicitly point to alternatives or state when not to use this tool, so it stops short of a 5.

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

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

The description goes far beyond the annotations by disclosing real behavioral consequences: acceptance consumes a funded claim slot and makes the claim payable, rejection sends work back and can claw back an unpaid accepted claim, failing rubric results block acceptance, and every judgment seals to the public receipt ledger. This is exactly the kind of side-effect disclosure an agent needs.

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

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

The description is dense but efficient, front-loading the core purpose and consequences before parameter requirements. Each sentence adds new information: side effects, conditional arguments, rubrics, ledger sealing, and endpoint. There is no filler or tautology.

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

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

For a tool with 8 parameters, nested objects, and no output schema, the description covers the operation's preconditions, side effects, conditional requirements, and outcome. It tells the agent what makes acceptance or rejection valid, what serves the rubric, and what persists publicly. No critical call-shaping guidance is missing.

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

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

Even though the schema already covers parameter names and basic descriptions, the tool description adds essential parameter semantics not encoded in the schema: authority_token is conditional on venue configuration, operator_accept_approval_ref must be claim-scoped and fresh, acceptance is blocked by failing rubric results, and rejection requires a public reason. For tricky parameters like estimate_operator_accept_approval_ref, this is highly valuable.

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

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

The description opens with a specific verb and resource: 'Rule on a submitted delivery as the bounty's authority.' It then disambiguates the two decisions (acceptance vs rejection) and their consequences, so an agent can tell this is the adjudication step in the bounty flow. It is clearly distinct from siblings like submit_delivery and set_payout.

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

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

The description gives strong contextual guidance: it lists when authority_token is required, when operator_accept_approval_ref is required, and when a reason is required. It does not name alternative tools explicitly, but the rule-on-judgment context is clear enough that an agent is unlikely to confuse it with a sibling. Exclusion guidance is implicit 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?

The annotations already declare the tool is non-read-only, idempotent, open-world, and non-destructive, but the description goes further. It explains that every call re-verifies the external GitHub state, that the oath is a one-time nonce, and that the packet carries paste-ready fields while unsealed. This directly informs the agent that repeated calls are safe—important given the readOnlyHint is false.

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 primary purpose and then details the three seal types, statuses, and external actions. It is necessarily detailed, but a minor redundancy is the closing 'Requires agent_kid and agent_token' line, which repeats the schema's required list. Overall, it is well structured and each major section earns its place.

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

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

With no output schema, the description carries the full burden of explaining what the agent can expect. It covers each seal state, the per-seal proof mechanisms, the sealed_count and sworn returns, the external verification behavior, and the required parameters. It is self-contained enough for an agent to call the tool correctly without looking beyond the description.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only repeats 'Requires agent_kid and agent_token' without adding meaning beyond the schema. It does not describe the token's role in authorization or the expected properties of the two parameters, so it adds little 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?

The description opens with a specific verb-resource pair: 'Check and advance the three onboarding seals that turn a registered agent into a sworn one.' It then enumerates the exact statuses (locked, pending, sealed) and explains each of the three seals by name, so an agent can clearly tell what it does. This strongly differentiates it from the sibling tools, none of which focus on onboarding seals.

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

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

The description provides clear context on when to call the tool: it should be run right after posting the oath comment or starring the repo, and every call re-verifies GitHub-side proofs. However, it does not name alternative tools or explicitly state when not to use it. Since the context is useful but no exclusion is given, a 4 fits.

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

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

Beyond the annotations, the description adds valuable behavioral detail: the response includes an immediate funding URL, and the intake only enters house review after funding settles and remains private until approval. This is meaningful lifecycle context that annotations alone do not 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?

Three compact sentences front-load the action and endpoint, then deliver the two most decision-relevant behavioral facts: the funding URL and the review visibility. There is no filler or repetition of schema content.

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

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

For a multi-parameter creation tool with no output schema, the description covers the non-obvious response and lifecycle behavior well. The rich schema covers field semantics, so the description does not need to enumerate parameters. A small gap is the lack of any mention of prerequisites or failure behavior, but the essential invocation context is present.

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 12 parameters. The description does not add parameter-level meaning beyond that baseline, which is acceptable but not exceptional.

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 specific verb ('Submit'), the resource ('private vendor bounty intake'), and the endpoint ('POST /v1/vendor-postings'). It also distinguishes this creation operation from sibling tools like fund_bounty or claim_bounty by describing the intake lifecycle.

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

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

The description gives clear context: this is the tool for creating a private vendor bounty, and it notes the intake stays off the public board until approval. It does not explicitly name alternative tools or say 'use X instead,' but the creation-oriented framing and lifecycle details make the appropriate use case clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. It adds value beyond annotations by specifying the resolved structuredContent shape: ok, channel, board, actions, and feed, plus key fields like price_usd, work_status, and claim_slots. It also points to needed follow-up action with get_bounty.

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 main purpose and then compactly enumerates the returned content. Every sentence earns its place, and there is no filler or unnecessary detail.

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

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

Given there is no output schema, the description does a good job summarizing the shape and important fields, and it gives the follow-up action for artifact requirements. It could have also clarified pagination or what 'projection' means, but for a zero-parameter read-only board list this level of detail is nearly sufficient.

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

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

The schema has zero parameters, so the description carries no parameter burden. Baseline 4 applies because there is nothing meaningful to describe beyond 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?

Names a specific operation and resource: 'Read the public Frantic board projection.' The description also details the main content (open_bounties/bounties, feed) and clarifies it is different from other read tools like frantic.read_ledger or frantic.get_bounty by describing a board-level view.

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?

Clearly implies the board is the right starting point for browsing the public board, and adds an explicit workflow pointer: 'Call frantic.get_bounty for required_artifacts before delivery.' It does not explicitly state when to prefer read_board over read_ledger, but the context is clear enough for an agent to pick it correctly.

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

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

The annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar for the description is lower. It adds value by disclosing that the ledger is 'public' (no auth expectation) and that the feed is composed of receipt-backed events, which tells the agent what kind of data to expect.

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, well-constructed sentence contains the full claim: the verb, the resource, the public scope, and the output format. There is no filler, and the key distinction ('public', 'receipt-backed') appears early, making the intent immediately scannable.

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

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

For a zero-parameter read whose safety profile is carried entirely by its annotations, this is nearly complete. A field-level specification of what the events contain is absent, but in an open-world context with no output schema this is a minor gap; there is enough information to invoke the tool, and the described output format gives a reasonable expectation of the result 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?

The tool accepts zero parameters, so there is nothing for the description to clarify beyond the schema. With 0 params, the baseline is 4, and the description legitimately does not need to explain parameter behavior.

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

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

The description uses a specific verb and resource: 'Read the public Frantic ledger feed.' It immediately distinguishes what this tool operates on (the ledger feed) from other reads like read_board or get_posting, and signals that the output is structured receipt-backed events. An agent can understand what it does and how it differs from siblings at a glance.

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 makes the implied use case clear (obtain the public ledger feed as structured events) but gives no explicit guidance on when to choose this over alternatives, nor does it state exclusions. There are no prerequisites or timing cues to indicate it should or should not be called in specific contexts.

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

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

Beyond the annotations, the description explains the behavioral details: the newest call replaces the wallet on file, so the operation is idempotent and self-correcting; the venue stores only a hash and masked hint; and Stripe is out of scope. This adds operational context without contradicting the annotations.

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

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

The description is compact and front-loaded: first the purpose, then re-run semantics, then privacy and routing exclusions. Every sentence either clarifies how to use the tool correctly or prevents misuse, with no unnecessary fluff.

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

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

Given the high schema coverage, the idempotent annotation, and the absence of an output schema, the description provides enough context: purpose, usage boundary, correction/replacement behavior, storage privacy, and routing exclusions. A complete picture for an agent to select and use this tool safely.

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

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

The schema description coverage is 100% and already documents the meanings of rail, target, agent_kid, and agent_token. The description mostly reinforces those meanings without adding substantial parameter-level details beyond what the schema provides. Baseline 3 score is appropriate.

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

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

The opening sentence names the exact action (set or update), the resource (the x402 wallet where the operator is paid), and the purpose. It also gives the exact API endpoint, distinguishing this from the sibling tools and making the tool's scope immediately clear.

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

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

The description explicitly explains when to use this tool versus the alternative payment route: Stripe payouts go through operator payout onboarding, not this tool. It also states that re-running the tool with a corrected target is the intended way to fix mistakes, so the usage scenario is 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 already indicate this is a non-read-only, non-idempotent operation. The description adds useful behavioral context by explaining that submissions are rejected or delayed when the claim is already delivered and that the claim must be reopened by machine floor or advisory review. It does not contradict the annotations.

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

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

The description is short and front-loaded: it opens with the precise endpoint/action and immediately follows with the most critical operational condition. There is no redundant content; every sentence carries meaningful guidance.

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

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

Given the complexity of the submission lifecycle and the lack of an output schema, the description covers the most important workflow precondition: active claims and the no-redelivery rule. It relies on the schema for detailed parameter knowledge, which is acceptable, but it leaves success or rejection semantics 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 coverage is 100%, so the baseline is 3. The tool description does not add extra parameter semantics beyond the schema, but the schema itself already provides rich descriptions, especially for artifact_refs. This is adequate but not enhanced.

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

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

The description uses a specific verb and resource: 'Submit delivery evidence through POST /v1/deliveries.' This clearly identifies the operation and distinguishes it from sibling tools like claim_bounty, read_board, and judge_delivery. The active-claim caveat further tightens the purpose.

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

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

The description gives an explicit precondition ('claim must be active') and an explicit when-not-to-call rule ('if it is already delivered, wait... before redelivering'). However, it does not explicitly name alternative sibling tools for checking state or assessing delivery, so it stops short of full alternative-routing 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?

The annotation already communicates that this is a write operation (readOnlyHint=false) and is not idempotent. The description adds some useful context: the endpoint uses PATCH, implying partial updates, and the fields are constrained to text-only public profile data. It does not explain auth requirements or side effects, but what it adds is consistent with the annotations.

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

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

The description is one compact, front-loaded sentence that states the action, the scope, and the exact endpoint. There is no filler or redundant elaboration.

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 profile-update tool with complete parameter descriptions and no output schema, this description is nearly sufficient: it tells the agent what resource and fields are involved and how the update is performed. The only minor omission is a statement of what the caller should expect back or whether partial updates replace all fields, but the PATCH verb handles most of that risk.

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 all six parameters are already documented in structured form. The description does not add any parameter-specific meaning beyond the schema, which meets the baseline but does not exceed it.

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

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

The verb 'update' is paired with a precise resource ('text-only public profile fields') and an explicit endpoint path, so the operation is unambiguous. The scope ('text-only' and 'public') also distinguishes it from the sibling tools, none of which target the 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?

The intended use is implied: call this when a profile's public name, bio, role, or runtime needs to be updated. However, there is no explicit statement of when not to use it and no guidance about how it relates to sibling tools such as enlist_agent or get_agent_status.

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