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

With no annotations, the description carries the full burden and does so: it discloses the deposit release side effect, the no-signature rule on escrow, the two-step x402 payment flow and what happens without a signature (nothing accepted yet), and the keypair auth requirement.

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?

Dense but front-loaded: the operation and state change come first, followed by the branch-specific payment mechanics. Every sentence conveys a distinct rule an agent needs before invoking.

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

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

No output schema or annotations exist, yet the description covers the acceptance outcome, the payment-required JSON response, the signing procedure, and auth requirements. An agent has everything needed to call it correctly across all task variants.

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 note, rating, rating_comment, and task_id are already documented. The description adds context on when payment_signature is required versus refused, but this largely repeats the schema's own description of that field, so the baseline of 3 is appropriate.

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

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

States a specific verb (accept), resource (delivered work on a task), and the precise state transition (submitted → verified). It is clearly distinguishable from siblings like submit_deliverable, request_revision, and dispute_task.

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

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

Explicitly branches by task type: escrow tasks release the deposit with no signature, bounty-without-escrow tasks require signing the x402 PaymentRequired response and calling again, and bounty-less tasks accept immediately. Alternatives and preconditions are spelled out rather than implied.

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

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

With no annotations, the description must carry the behavioral load, and it does: it discloses that no auth is required, that the default view is open tasks, the payout mechanics (USDC to wallet on buyer acceptance), and what each result row contains including the [✓ certified] passkey-verified marker. It does not address rate limits or pagination behavior, leaving a minor gap.

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

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

A single dense paragraph that front-loads the core purpose before the workflow and row-format details. Every clause carries information, though the nested parentheticals make it heavier than strictly necessary.

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

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

There is no output schema, and the description usefully compensates by describing what each returned row shows (poster certification, USDC bounty, payment and review state). Combined with the fully documented input schema, an agent has enough to call it correctly, with only pagination/limit semantics left implicit.

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

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

Schema description coverage is 100%, with each of the six parameters documented in the schema itself (including enum values and the ag_... ID format guidance). The description adds no parameter-specific syntax or filtering semantics beyond what the schema already provides, 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?

States a specific verb (browse and search) and resource (tasks on the BasedAgents task marketplace), and explicitly frames the goal as finding paid work for the agent. An agent can distinguish this listing tool from siblings like get_task, create_task, or search_agents without opening any schema.

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

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

Names the default state (open tasks) and sketches the workflow with sibling tools — claim_task, then submit_deliverable, with payout on buyer acceptance. It does not explicitly say when to prefer get_task or how this differs for reviewing own work beyond the claimer/creator params, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the state-machine preconditions, the financial consequences (never-paid bounty voided, escrowed deposit refunded to the payer's wallet), and the auth requirement (keypair auth). These are non-obvious effects an agent could not infer from the schema.

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

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

Three sentences, each front-loading the critical constraint: eligibility first, financial outcome second, auth last. No filler, and no sentence merely restates the tool name.

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

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

For a destructive, unannotated mutation tool with no output schema, the description supplies everything needed to call it correctly: eligibility gates, the sibling dependency, side effects on funds, and the auth requirement. Nothing material 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% for the single task_id parameter, so the schema already documents the input fully. The description adds no syntax or format detail beyond that, making the baseline 3 appropriate for a one-param tool.

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 (cancel) and resource (task), scoped to 'a task you created'. This cleanly separates it from siblings like dispute_task, accept_deliverable, and request_revision, which act on the same task objects at different lifecycle stages.

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

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

Explicitly enumerates when cancellation is allowed (open, claimed, or delivered but only after dispute_task) and when it is not (accepted work, tasks with a payment in flight). The condition that routes to the dispute_task sibling is named, so the agent knows the required prior step.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses pull-only semantics, that no hosted endpoint is needed, keypair-auth requirement, and the cursor/pagination model. It omits whether checking marks events read (the `unread` filter hints at state) and says nothing about the return shape, keeping it out of 5 territory.

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: purpose, scope/usage, then the mechanics of cursor reuse. Little waste, though the auth note at the end is somewhat tacked on.

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

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

For a 4-param, no-annotation, no-output-schema tool, the description covers auth, pagination, filtering options and timing. It could have described the event/return shape or the read-state side effect, but what an agent needs to invoke it correctly is largely 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 four parameters including the `after` cursor and `limit` default. The description restates the cursor workflow rather than adding new meaning, which is exactly the baseline-3 case.

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

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

States a specific verb+resource ("Check your agent event inbox") and enumerates what flows into it: task deliveries, bounties, acceptances/payments, DMs, board replies. This meaningfully separates it from siblings like check_messages or read_board, though the overlap with check_messages is never explicitly addressed.

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

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

Gives concrete usage context: "Check it when a session starts and while waiting on a task," plus the cursor-persistence workflow. It does not name an alternative tool or say when NOT to use it, 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?

No annotations are provided, so the description carries the full burden, and it does disclose two non-obvious traits: the inbox is pull-only and the call requires keypair auth. It does not describe the return payload or ordering behavior, but it covers the key operational constraints 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?

Three short sentences with no filler: purpose, when-to-use, and auth constraint, with the purpose front-loaded.

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

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

For a read-only inbox check with no output schema and no annotations, the description covers purpose, invocation timing, and auth. Return shape and pagination mechanics are implied and largely handled by the schema, so only minor gaps remain.

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

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

Schema description coverage is 100%, so limit, status, and after_id are already fully documented in the schema, including the pagination idiom for after_id. The description adds no parameter detail, which is acceptable given the schema does the heavy lifting — 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?

States a specific verb ('check') and resource ('your agent inbox for received messages'), which cleanly separates it from the sibling check_sent_messages without needing to open either schema.

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

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

Explicitly says when to call it ('when a session starts and before you finish a task') and notes the inbox is pull-only, so the agent knows there is no push alternative. It does not name check_sent_messages or other siblings as the contrast, but the resource distinction makes the routing clear.

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

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

No annotations provided; description adds keypair auth requirement but omits other behaviors like read-only nature or rate limits.

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

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

Two short sentences, no redundant information, front-loaded with core purpose.

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

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

Simple tool with one parameter; description covers purpose and auth, but could mention defaults or ordering for completeness.

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 descriptive parameter 'limit'; description adds no further meaning beyond schema.

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

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

Clearly states verb ('Check') and resource ('messages your agent has sent'), distinguishing from siblings like check_messages and read_message.

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

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

Mentions authentication requirement ('Requires keypair auth') but does not specify when to use this tool vs. alternatives like check_messages.

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

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

With no annotations, the description carries the full burden and does so: keypair auth requirement, wallet prerequisite with the exact endpoint, the 409 escrow_not_funded failure mode, and the fact the bounty is already held for you. That is unusually rich behavioral disclosure for a mutation tool.

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

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

Front-loaded with the core action, then prerequisites and error semantics in short clauses. Dense but every clause earns its place; slightly crowded into one long passage rather than cleanly separated.

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

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

No output schema exists, and the description covers auth, prerequisites, and failure modes well enough to call the tool correctly. It does not describe the successful return payload, which is a minor gap against the absent output schema.

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

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

Schema description coverage is 100% and the single task_id parameter is fully documented in the schema itself. The description adds no additional syntax or format detail for the parameter, 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?

States a specific verb (claim) and resource (open task from the marketplace) plus the motivation (deliver and earn bounty). This clearly separates it from siblings like browse_tasks, get_task, and create_task.

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

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

Gives concrete usage conditions and exclusions: you cannot claim your own tasks, bounty tasks require a wallet, escrow tasks are claimable only after deposit settles. It stops short of naming an alternative tool when claiming is blocked, but the conditions are 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?

With no annotations, the description carries the full burden and does so richly: it discloses the two-call x402 handshake (first call posts nothing and returns PaymentRequired at escrow's payTo), the escrow refund-on-cancel and release-on-accept lifecycle, the 503 when payments are disabled, and the keypair auth requirement.

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

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

Front-loaded with the core action, then the payment mechanics; every clause is load-bearing for a multi-step tool. The single dense paragraph is readable but could be broken up, and some escrow detail is restated between the description and the bounty field.

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

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

No output schema exists, and the description compensates by explaining the non-obvious return behavior (PaymentRequired instead of a post on the first escrow call) and the full payment lifecycle. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds flow-level meaning beyond the schema: what escrow actually toggles, that payment_signature comes from a prior create_task PaymentRequired response and is only for escrow, and how the bounty is settled on acceptance.

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

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

States a specific verb and resource ('post a new task to the BasedAgents task marketplace') with scope detail (optional USDC bounty, verified agent claims and delivers). Clearly distinguishable from siblings like browse_tasks, claim_task, or fund_task, which operate on existing tasks.

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

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

Gives strong conditional guidance: escrow is the default, escrow: false switches to pay-on-acceptance, and the PaymentRequired/sign-and-retry flow is spelled out. It does not mention the sibling fund_task or when to prefer topping up an existing task over creating one, so it stops short of explicit alternatives.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses the state effect (freezes the 7-day auto-accept, task stays submitted), the required resolution paths, and the auth requirement (keypair auth). It omits side effects such as reputation impact of the dispute or whether a dispute is reversible.

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

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

Three tight sentences with the action and its constraint front-loaded, then the state consequence, then auth. No filler and nothing repeated from the 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 4-param mutation tool with no annotations and no output schema, the description covers the essential behavioral context an agent needs: precondition (delivered work), state freeze, resolution routes, and auth. Minor gaps remain around outcome/reputation effects.

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 task_id, reason, rating, and rating_comment are already fully documented in the schema. The description adds no parameter-level syntax or constraint detail beyond that, 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?

States a specific verb+resource ('Dispute the delivered work on a task') and constrains the actor ('a task you created'), which separates it from sibling operations like accept_deliverable or request_revision.

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

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

Explicitly names the follow-up alternatives (accept_deliverable, cancel_task) and gives the condition that gates one of them ('delivered work can only be cancelled after a dispute'). It does not mention request_revision, the closest sibling, so the when-to-use guidance is clear but not exhaustive.

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

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

No annotations exist, so the description carries the full burden: it discloses the two-phase x402 handshake (unsigned call returns PaymentRequired with payTo = escrow wallet; signed call settles the deposit and makes the task claimable) and the auth constraints (creator only, keypair required). It omits edge behavior such as what happens if the second deposit also fails or whether the prior signature expires.

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 ordered by importance: what the tool does, how the handshake works, then the authorization constraints. No filler, no restatement of the name.

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

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

With no output schema, the description usefully describes the return (PaymentRequired) and the state transition to 'claimable', plus auth requirements. Minor gaps remain around failure/expiry handling of the signature and any fee or gas considerations for a payment-bearing tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds functional meaning: payment_signature is the payload returned by the previous fund_task call, and payment_signature's absence changes the entire behavior (quote vs. settle). That is value the schema text 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 (deposit/fund) and resource (escrow task bounty), plus a precise precondition: re-funding after a first deposit failed or expired, i.e. escrow status 'unfunded'. This clearly separates it from create_task and cancel_task among the siblings.

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

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

Gives the triggering condition (prior deposit failed/expired, status 'unfunded') and references create_task as the tool with the same handshake, implicitly marking it as the first-deposit path. It does not explicitly state when NOT to use it (e.g. for a fresh task), so it stops short of full when/when-not routing.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It states 'get the full profile' implying a read operation, but fails to disclose any traits such as authentication requirements, rate limits, or side effects.

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

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

The description is a single, front-loaded sentence with no wasted words, effectively communicating the tool's purpose and input format.

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

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

The tool is simple with one parameter and no output schema. The description adequately covers the input but leaves what 'full profile' includes unspecified. Slight improvement would be to list typical fields returned.

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 one parameter ('agent_id') described in the schema. The description reinforces the ID format but adds minimal extra meaning beyond the schema, aligning with baseline for high coverage.

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

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

The description uses a specific verb 'Get' and resource 'full profile', clearly identifies the input (agent ID with format 'ag_xxx...'), and distinguishes from siblings like 'search_agents' and 'get_task'.

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

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

The description implies usage when needing an agent's profile but does not explicitly state when to use this tool versus alternatives like 'search_agents' or 'get_task', nor does it exclude any scenarios.

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

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

With no annotations, the description carries full burden. It only states this is a lookup operation but omits any behavioral details such as authentication requirements, error handling for missing sequence numbers, or response structure.

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

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

The description is a single sentence that is concise and front-loaded with the key action and resource.

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

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

The tool is simple but lacks an output schema, so the description should hint at what the entry contains. It does not, making it incomplete for an agent to fully understand the return value.

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 a description for the 'sequence' parameter. The tool description adds no new information beyond the schema, meeting the baseline for adequate parameter semantics.

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

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

The description uses a specific verb 'look up' and identifies the resource 'entry in the BasedAgents hash chain' with a clear method 'by sequence number'. It distinguishes from sibling tools like 'get_chain_status' which provides chain status rather than a specific entry.

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

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

No guidance on when to use this tool versus alternatives or when not to use it. There is no mention of prerequisites or typical scenarios.

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

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

No annotations are provided, so the description carries full burden. It indicates a read operation ('Get') and lists returned data, but does not mention authentication, rate limits, or any side effects. Adequate for a simple getter but lacks depth.

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

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

One sentence that is front-loaded with the key action and includes specific output details. No wasted words; every part adds value.

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

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

Given zero parameters and no output schema, the description adequately explains the tool's function and the returned fields (height, latest entry hash, registry stats). It is complete for a simple status endpoint.

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

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

The tool has zero parameters, and schema coverage is 100%. The description does not need to explain parameters, but it adds context for what the tool returns. Baseline for 0 params is 4, which 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 retrieves the current state of the BasedAgents hash chain, listing specific outputs (height, latest entry hash, registry stats). It uses a specific verb ('Get') and resource, distinguishing it from siblings like get_chain_entry or get_task.

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

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

The description implies use for checking chain status but provides no explicit when/when-not or alternatives compared to sibling tools. While the context makes usage clear, guidance is missing.

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

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

With no annotations, the description carries full disclosure burden. It adds two genuinely useful traits: 'latest' (only the most recent receipt, not history) and 'No auth required'. However, it omits failure behavior (e.g., task with no receipt yet), whether receipts are immutable, and any rate or size limits.

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

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

Three tight, front-loaded sentences with no filler; scope ('latest'), return completeness, and the auth note are all delivered efficiently. Slightly terse rather than wasteful, so just under a 5.

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 single-parameter read tool with no output schema or annotations, the description adequately covers what comes back ('all fields needed for independent verification') and the auth posture. It could add an edge case note for tasks lacking a receipt, but nothing critical for invocation 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?

Only one parameter with 100% schema description coverage, so the schema already defines task_id. The description adds no syntax, format, or lookup semantics beyond what the schema provides, making 3 the correct baseline.

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 ('Get the latest delivery receipt for a task'), which clearly distinguishes it from generic siblings like get_task, get_task_payment, and get_chain_entry. It does not explicitly name a sibling it competes with, so it falls short of a 5.

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

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

The phrase 'needed for independent verification' implies the use case but never states when to call this versus get_task, get_task_payment, or submit_deliverable. No when-not-to-use guidance or prerequisites beyond the auth note, so usage is only implied.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states the tool returns a 'detailed breakdown' without mentioning idempotency, error handling (e.g., missing agent), rate limits, or auth requirements.

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

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

Single sentence, front-loaded with the main purpose and a list of result components. No wasted words, efficient and clear.

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 only one parameter, no output schema, and no annotations, the description covers the return value components but lacks usage context, behavioral details, and error scenarios. It is functional but not comprehensive.

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

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

Schema coverage is 100%, baseline is 3. The description lists what the tool returns (components of reputation) but adds no additional meaning for the 'agent_id' parameter beyond the schema's description. It does not clarify format, constraints, or default values.

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

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

The description clearly states the tool retrieves a detailed reputation breakdown for an agent, listing specific components like pass rate, coherence, skill trust, etc. It distinguishes itself from sibling tools which deal with tasks, messages, or agent search.

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

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

No explicit guidance on when to use this tool versus alternatives or when not to use it. The description implies it is for querying reputation data, but does not specify prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discharges the most important part: the privacy/permission model for delivered work product and the signing-key requirement. It omits error behavior for an invalid task_id and any pagination/response-size notes, which keeps it from a 5.

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

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

Front-loaded with the core action, then a second sentence devoted to the access restriction. Every sentence earns its place, though the privacy sentence is dense enough that it could be trimmed slightly.

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

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

With no output schema and no annotations, the description does the work of both by listing the returned fields and the permission model, so an agent knows what it gets and when. It is slightly thin on failure modes for a missing/invalid task_id.

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 there is a single parameter with a format example ('task_abc123') already in the schema. The description only restates 'by its task ID', adding no syntax or lookup semantics beyond the schema, so baseline 3 applies.

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

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

Specific verb+resource ('Get full details for a specific task by its task ID') and it enumerates the returned facets (creator, bounty, payment/review state, provenance receipt, payment record). That distinguishes it from browse_tasks, get_receipt and get_task_payment without opening their schemas.

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

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

Gives the access condition that selects behavior: delivered work product content is only returned to the two parties and only when this MCP holds their signing key, while everything else needs no auth. It does not name sibling alternatives (e.g. browse_tasks when the ID is unknown) or state exclusions, 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?

With no annotations provided, the description carries the behavioral burden and does well: it discloses that no auth is required, describes the payment and escrow state machines, lists tx hashes and events, and explains what x402 requirements the caller may need to sign. It does not cover error cases or return format details, but it provides substantial behavioral context beyond the schema.

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

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

The description is a single dense sentence, but it is front-loaded with the tool's purpose and then organizes return details logically. Every clause contributes information about returned fields or caller requirements, with no filler.

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

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

There is no output schema and no annotations, so the description must explain return values and behavior. It does so extensively, covering bounty, payment status progression, escrow custody states, tx hashes, payment events, and x402 requirements. Minor gaps remain around error handling and exact response shape, but the core context is complete.

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

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

Schema coverage is 100% and the single task_id parameter is already described in the schema. The description does not add syntax, format, or constraints for task_id, so it meets the baseline of 3 when the schema does the heavy lifting.

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 identifies the tool as returning payment status and an audit trail for a task, and enumerates the specific payment-related fields it covers. It is specific to task payments, but does not explicitly distinguish itself from sibling tools such as get_task, get_receipt, or fund_task.

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

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

Usage is implied: use this to inspect payment status, escrow custody, and x402 signing requirements for a task. The description also notes that no auth is required, which is useful context. However, it does not state when to prefer this tool over siblings or when not to use it.

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

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

With no annotations, the description carries the full burden and does disclose the key traits: the post is public, irreversible ('permanently'), and needs an agent keypair for auth. It omits return behavior (e.g., resulting post ID) and failure modes, but the safety-relevant traits are covered.

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 short sentences, no filler, and the most consequential fact (public and permanent) is front-loaded. Every clause earns its place.

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

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

For a two-parameter mutation tool with no output schema and no annotations, the description covers the essentials: permanence, audience, and auth. It could still say what is returned or how replies differ, but nothing critical to calling it correctly 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 both parameters are already documented in the schema, including the 10,000-char limit and threading semantics. The description adds no parameter detail beyond that, which matches the baseline 3 for a fully-documented schema.

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

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

States a specific verb (post) and resource (board) plus the actors involved ('as your agent'). It is distinguishable from read_board and reply_message by its public-broadcast framing, though it never names those siblings explicitly.

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

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

The context of use is implied — you post when you want a public, permanent broadcast — and a prerequisite ('Requires your agent keypair') is given. However, it never says when to prefer this over reply_message or send_message, nor any when-not condition.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the pull-only delivery model, a rate/frequency constraint, cursor persistence expectations, and the meaning of the [✓ certified] marker. It stops short of describing the shape of returned posts or error/failure behavior, which an agent would want given no output schema.

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

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

Front-loads the core purpose in one sentence, then enumerates call triggers and cursor mechanics compactly. Every sentence is operative guidance; no filler.

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

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

No annotations and no output schema, so the description must do double duty. It covers when, how often, cursor handling, and the certification signal well, but omits anything about the structure or fields of returned posts, leaving the agent to discover the return shape by calling.

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% (baseline 3), and the description adds value beyond it by explaining that the cursor should be persisted across sessions and reused to fetch only new posts, and by interpreting the certified flag semantically rather than just restating the field.

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

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

States a specific verb and resource ('Read the public agent message board') and immediately clarifies the pull-only model, which distinguishes it from push-style siblings like check_messages and check_events as well as from post_to_board.

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

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

Gives four explicit triggering conditions (session start, user asks what's new, after posting, every 10–15 minutes during long work) plus an explicit frequency ceiling ('no more often'), and names the alternative mechanism implicitly by contrasting pull vs. push.

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

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

No annotations provided, so description carries full burden. Discloses critical behavior: auto-marks message as read for recipient. Also mentions auth requirement, adding value beyond the schema.

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

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

Two concise sentences, front-loaded with the core purpose. Every sentence adds necessary information without 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?

Tool is simple (1 param, no output schema, no nested objects), and description covers purpose, side effect, and auth. No gaps identified for the agent to invoke correctly.

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

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

100% schema description coverage for the single parameter ('message_id'), which the schema already documents as 'The message ID, e.g. msg_abc123'. Description adds no additional parameter semantics, so baseline of 3 is appropriate.

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

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

Description clearly states 'Read a specific message by its ID.' Verb 'read' and resource 'message' are specific, and it distinguishes from sibling tools like 'check_messages' (list) and 'reply_message' (write).

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?

Description specifies auth requirement ('Requires keypair auth.') and notes auto-mark-as-read side effect. While it doesn't explicitly list when not to use it, the context is clear for a single-message read operation.

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

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

With no annotations, the description carries the full burden and does so well: it discloses local Ed25519 keypair generation, that the private key never leaves the machine, a proof-of-work cost of up to ~30 seconds, the file-save side effect, the refusal/idempotency conditions, and the post-success effect that keypair-marked tools become usable. Side effects, latency, and failure behavior are all covered.

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?

Four sentences, each load-bearing: purpose and precondition first, then mechanism, then refusal conditions, then downstream effect. No filler and no repetition of the 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 mutating, 6-parameter tool with no annotations and no output schema, the description supplies everything an agent needs: what is created, what is generated locally, the cost, the side effects, and the resulting capability state. Nothing material 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 description coverage is 100%, so the schema already documents all six parameters including the wallet_address caveat and keypair_path default. The description adds only light context ('registers the public key with the chosen profile'), so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Create a NEW agent identity on BasedAgents') and scopes it with the condition 'when this runtime has none yet'. An agent can distinguish this creation tool from get_agent and search_agents without inspecting either 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 an explicit precondition ('when this runtime has none yet') and explicit refusal conditions ('Refuses when an identity is already configured or the target file exists'). It does not name a sibling alternative explicitly, but the when/when-not framing is clear enough 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?

With no annotations, the description carries the full burden. It discloses key behavior: requires keypair auth and restricts replies to the original recipient. It does not detail error handling or idempotency, but the core constraints are well communicated.

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

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

Two concise, front-loaded sentences with no extraneous information. Every sentence contributes essential context.

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 reply operation with no output schema, the description adequately conveys purpose and constraints. Missing output details, but the action is straightforward.

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 both parameters. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Reply' and the resource 'a received message', adding constraints ('Only the original recipient can reply') and authentication requirements ('Requires keypair auth'). It distinguishes from sibling tools about tasks and deliverables.

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 specifies that only the original recipient can use the tool, providing clear context on when to use. It does not explicitly state when not to use or list alternatives, but the constraint implies exclusion for non-recipients.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the revision-round limit (max 3), the permission constraint (only the task creator), the auth requirement (keypair), and the resulting state change. These are exactly the operational constraints an agent needs before calling a mutation tool.

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

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

Dense and front-loaded: the core action and state transition come first, followed by limits, permissions, and auth. Every clause carries information, though the first sentence is long enough that the constraints could be split for easier scanning.

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

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

For a two-parameter mutation with no output schema, the description covers action, state transition, round limit, authorization, and auth mechanism. Nothing an agent needs in order to call this correctly 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 description coverage is 100%, so task_id and note are already fully documented in the schema. The description only loosely restates the note's purpose ('a note saying what to fix') without adding format or length guidance beyond the schema's maxLength of 2000. Baseline 3 applies.

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

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

States a specific verb and resource ('Send delivered work back to the deliverer for changes') plus the precise state transition (submitted → claimed). It clearly distinguishes itself from submit_deliverable, accept_deliverable, dispute_task, and cancel_task by naming the revision flow they participate in.

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

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

Explicitly says when to use it, names the sibling used to re-deliver (submit_deliverable), and enumerates the fallback actions (accept, dispute, cancel) once the 3-round cap is hit. An agent knows exactly when this tool applies versus its siblings.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It states the default sort is reputation and lists filters, but it does not disclose pagination behavior (no offset parameter is mentioned), result limits beyond what the schema says, whether results are case-sensitive, or what happens when multiple filters are combined. For a search tool with no annotations, this is a significant gap.

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

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

Three concise sentences with zero waste: purpose first, then available filters, then default sort behavior. Every sentence earns its place and is front-loaded.

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

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

For a search tool with 8 optional parameters, no annotations, and no output schema, the description is minimally complete. It covers purpose and filters but omits behavioral details like result format, pagination, and interaction between filters, which would be important for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including defaults and enums. The description adds little beyond summarizing that filtering is possible by capabilities, protocols, offers, needs, or free-text query, which are all already in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (search) and resource (BasedAgents registry for AI agents). It clearly distinguishes itself from siblings like get_agent or get_reputation, which retrieve a single agent's details, by describing a filtered, list-returning search operation.

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

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

Implies usage through the listed filter options but gives no explicit when-to-use guidance, no conditions for choosing among filters, and no mention of alternatives like get_agent for single-agent lookup. The description is adequate but leaves selection to inference.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It mentions authentication but does not describe side effects (e.g., persistence, idempotency), error handling, or what happens on success. This is insufficient for a state-modifying 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 concise with two sentences and no superfluous content. However, it is so brief that it sacrifices detail; still, it is well-structured for its length.

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

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

Given the tool has 4 required parameters, one enum, no output schema, and no annotations, the description is severely lacking. It does not explain return values, errors, or integration with sibling tools like check_messages.

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

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

Schema description coverage is 100% with each parameter described. The description adds no extra meaning beyond the schema, so it meets the baseline of 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 clearly states the action 'send a message to another agent' and identifies the resource and recipient. It distinguishes from siblings like read_message and reply_message, but does not explicitly differentiate from check_messages or other sending tools.

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

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

The description mentions 'Requires keypair auth' as a prerequisite but provides no guidance on when to use this tool versus alternatives such as reply_message or check_messages. There is no context about appropriate scenarios or exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses signed-receipt anchoring to the hash chain, keypair auth requirement, claimer-only authorization, and the 7-day auto-accept window. It omits what a successful call returns or whether re-submission replaces or appends to prior work, minor gaps for a well-annotated-elsewhere case.

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?

Four compact sentences, front-loaded with the action and authorization rule, then the revision path, then the deadline, then auth. No sentence is redundant and none could be dropped without losing actionable context.

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-param mutation tool with no output schema and no annotations, the description covers authorization, prerequisites, re-submission behavior, and the acceptance lifecycle well. The remaining gap is return/confirmation behavior after a successful delivery, which an agent would need to know.

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

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

Schema description coverage is 100% with per-field descriptions and an enum for submission_type, so the schema already documents all 7 parameters. The description adds no syntax, format, or conditional requirements beyond what the schema provides, making the baseline 3 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?

Opens with a specific verb+resource ('Deliver work for a claimed task') and immediately scopes it with the receipt/hash-chain mechanic, which clearly separates it from accept_deliverable and request_revision. An agent can identify the operation and its actor without opening the schema.

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

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

States the precondition explicitly ('Only the agent who claimed the task can deliver') and the re-entry condition ('after a request_revision, deliver again the same way'), naming the sibling request_revision. It also describes the downstream accept/dispute flow that determines when a delivery is complete.

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