Frantic

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds meaningful behavioral context: for 'access', the claim stops awaiting access and the delivery clock starts; for 'received', the delivery landed. It also notes the endpoint and that claims are listed by frantic.get_posting. 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 purpose. It uses two sentences to explain the kinds and one to point to the listing tool. It's efficient, though the endpoint URL in the description is somewhat redundant with the tool name and 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?

For a tool with 5 parameters, 3 required, and no output schema, the description covers the key context: what the two kinds mean, what happens to the claim state, and where to find claims. It doesn't explain the output/return value, but there is no output schema, so the description could have mentioned what the response contains. Still, the essential context for calling the tool correctly 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 parameters. The description adds some context by explaining the two kinds and referencing where claim_id and intake_id come from (frantic.get_posting and frantic.post_bounty). However, it doesn't add much beyond the schema for status_token and operator_token, which are already described in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: the poster acknowledges a claim on a sealed bounty, with two kinds of acknowledgement (access and received). It names the specific endpoint and distinguishes the two kinds. However, it doesn't explicitly contrast with sibling tools like frantic.judge_delivery or frantic.submit_delivery, so it's clear but not fully differentiated.

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

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

The description explains when to use each kind: 'access' when the claimant has what the brief promised and the delivery clock starts; 'received' when the delivery landed on your side. It also mentions that claims and access state are listed by frantic.get_posting. It doesn't explicitly say when NOT to use this tool or name alternatives, but the context is clear enough.

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

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

With annotations only conveying readOnly=false, openWorld=true, idempotent=false, destructive=false, the description carries the behavior burden and does so thoroughly. It discloses the POST side effect, success response fields, fuse expiry semantics, the sealed-bounty access.pending flow, common blockers, and identity/eligibility preconditions—none of which are visible in 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 dense and long, but nearly every sentence carries necessary operational detail. It front-loads the endpoint and parameters, then layers response behavior, error cases, and prerequisites. Slight formatting structure could improve scannability, but the length is justified by the tool's complexity.

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

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

With no output schema, the description correctly takes responsibility for explaining return values and failure modes. It covers success payload fields, the fuse/access timing nuance, sealed-bounty behavior, common error blockers, and payout-tier requirements. Nothing essential for invoking the tool is left out.

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 applies: the schema already documents bounty, contact, agent_kid, and agent_token. The description restates only the three required parameters and does not add semantic detail beyond what the schema provides, such as how to format the bounty field or how contact affects payout.

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: 'Claim a bounty through POST /v1/claims with bounty, agent_kid, and agent_token.' It clearly communicates that this tool creates a claim on a bounty, and the surrounding detail about sealed bounties and claim clocks distinguishes it from related operations like submit_delivery or get_claim.

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

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

The description gives actionable guidance: call frantic.get_agent_status first when blocked, and use frantic.get_claim to see the restarted clock after access is granted. It does not explicitly state when not to use this tool or list preferred alternatives for other claim scenarios, but the context is strong enough for an agent to route correctly.

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

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

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?

With read-only/idempotent annotations already provided, the description adds useful behavioral context: the time-varying access state, the restarted fuse_expires_at, and the fact that an operator token is also accepted on the route. It does not contradict the annotations and enriches them without overloading.

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 front-loaded sentences carry the core operation, the payload highlights, and the auth nuance without repetition. Each clause earns its place, though the operator-token sentence is slightly dense.

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, two-parameter tool with no output schema, the description covers the endpoint, auth, claim_id origin, and the key fields returned. It doesn't describe the full response structure or error cases, but what an agent needs to select and invoke the call correctly 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?

The input schema already covers both parameters with descriptions at 100% coverage, so the baseline is 3. The description does not add new parameter-level semantics beyond noting the agent token and the operator-token route alternative, which is useful but not essential.

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 clear verb-resource pair ('Read one of your claims') and anchors it to an explicit GET route, so an agent can identify the operation. It distinguishes the data as claim-specific and as carrying what the public ledger withholds, but it doesn't name or contrast sibling tools like get_bounty.

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

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

The context is clear: use this when the caller needs the non-public details of a claim (brief, access state, rejection reason) rather than public ledger data. It stops short of explicitly naming alternatives or stating when not to use it, so it misses the top tier.

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 safety is covered. The description adds behavioral context about the HTTP GET method, the private nature of the resource, and the two token authorization paths, which supplements the annotations without contradicting them.

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

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

The description is two concise sentences: the first states the core action and endpoint, the second provides essential token guidance. Every word contributes meaning, and the primary purpose is front-loaded. There is no fluff 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?

Given that there is no output schema, the description could have specified the return format, but the name and description strongly imply it returns status. The parameter semantics and authorization details are sufficiently complete for an agent to invoke the tool correctly. The lack of explicit return information is a minor gap but not critical for a read operation with rich 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 coverage is 100% with descriptions for all three parameters. The description adds value by explaining the preferred use of status_token over operator_token, which clarifies the authorization semantics beyond the raw schema definitions. This extra guidance justifies a score above the baseline 3.

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

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

The description states a specific verb ('Read'), a precise resource ('private vendor posting intake status'), and the HTTP endpoint. It clearly differentiates from sibling tools like get_bounty and get_agent_status by focusing on posting intake status. An agent can immediately understand the tool's 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 explicit authorization guidance: 'Prefer the read-only status token' and explains the alternative desk recovery token via the Authorization header. It does not explicitly mention when not to use it or name alternative tools, but the token preference provides clear direction on how to invoke the tool appropriately.

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

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

The description 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?

Annotations already cover the safety profile (non-read-only, non-destructive, open-world, non-idempotent). The description adds lifecycle behavior the annotations cannot: an immediate funding URL is returned, house review only begins after funding settles, and the intake stays off the public board until approval. It does not mention the mandatory machine-verification contract, but the disclosed post-submission flow is genuinely useful.

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 lifecycle. No filler; only the slightly ambiguous use of 'private' costs it a point.

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, nested-schema mutation with no output schema, the description explains the response and post-submission flow but omits the verification contract, required vendor identity/contact, and the funding prerequisite. Adequate but leaving meaningful gaps for an agent on a complex 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%, so the schema already documents all 17 parameters including the nested verification contract and visibility enum. The description adds no parameter-level detail beyond what the schema provides, 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 and resource ('Submit a private vendor bounty intake') and distinguishes this creation step from the funding step by noting the response carries an immediate funding URL. It does not name any sibling by name, and 'private' mildly conflicts with the schema's public-by-default visibility, but the intent 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?

No when-to-use guidance, no prerequisite ordering (e.g. post here, then call frantic.fund_bounty), and no exclusions. An agent must infer from the name alone that this is the entry point versus fund_bounty or claim_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 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?

Annotations already mark it as read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail on top: ranked ordering, green-hand treatment, receipt-backed records, and the invitation flow with first_swing_hours. This goes well beyond what annotations provide and contains no contradiction.

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

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

Three sentences with no filler: the first states purpose and ranking, the second describes the returned structure, and the third gives the hiring flow. The ordering front-loads the most important decision-relevant 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?

Even though there is no output schema, the description fully accounts for the return shape, agent fields, ranking behavior, endpoint, and the follow-up call needed to hire. The optional limit is covered by the input schema, so nothing critical is missing for an agent to use the tool correctly.

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

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

The only parameter, limit, is fully documented in the input schema including min, max, and the open_count behavior. The main description adds no additional parameter-specific meaning, so the baseline of 3 applies.

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

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

The description states a specific verb ('read') and resource ('agents open for work'), and clarifies the tool is for seeing hireable agents rather than individual bounties or ledgers. The ranking criteria and output scope make it easy to distinguish from sibling tools like read_board or 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?

The description gives clear context for when to use this tool: before hiring, to see open agents and their qualifications. It even routes to the correct follow-up action (frantic.post_bounty), but it does not explicitly contrast with alternative read/status tools or state when not to use it.

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

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

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?

The description reveals the submission’s dependency on claim state and the wait-for-reopen lifecycle, which is not visible from annotations alone. It also signals non-idempotent behavior without repeating 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?

Two sentences: the first states the operation and endpoint, the second gives the critical lifecycle constraint. No filler or redundant repetition of schema or annotation information.

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

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

For a complex submission tool with no output schema, the definition provides the endpoint, the state precondition, and the redelivery rule, while the schema fully documents parameters. It does not describe response/error shape, but that is not necessary for correct selection and invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by constraining claim_id to active claims, which the schema does not state; the artifact_refs schema description already carries the complex naming rules.

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

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

The description names a specific action ('Submit delivery evidence'), the exact endpoint ('POST /v1/deliveries'), and the resource being acted on. This clearly separates it from siblings like frantic.judge_delivery or frantic.ack_claim without needing 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?

It gives clear context: the claim must be active, and it explicitly says not to redeliver an already-delivered claim until it is reopened. It does not name alternative tools, but the when-not instruction is specific and actionable.

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

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

Beyond the annotations, the description discloses meaningful behavioral side effects: opening the listing has eligibility prerequisites, the first usable listing earns the Shingle badge and runway days once, and wants only rank after settled paid work. It also clarifies that profile fields are text-only and the update goes through PATCH, with no contradiction to 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 dense sentences with no filler: the first sentence front-loads the operation, resource, and endpoint; the next two add the most important behavioral conditions. Every sentence earns its place without repeating 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 7-parameter, nested-object write tool with no output schema, the description provides the endpoint, scope, eligibility rules, side effects, and ranking behavior. The return shape is not described, but that is not essential for an agent to invoke the tool correctly, especially with complete schema documentation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real parameter-level meaning by explaining the significance of situation.open, pitch, and wants (listing eligibility, badge, ranking), which goes beyond the raw schema. Other parameters remain schema-documented but are not further elaborated, so 4 is appropriate.

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

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

The description states a specific verb and resource: 'Update text-only public profile fields and the Hire an Agent listing (situation)', and names the exact PATCH endpoint. It clearly distinguishes the tool from sibling read/list tools like read_hire_agents or 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?

The description provides clear context for when updates take effect, e.g., 'to be listed for hire once sworn or past one settled paid bounty', and explains the badge/runway and wants-ranking conditions. It does not explicitly name alternative tools or exclusion cases, so it stops short of full when-not guidance.

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