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

Adds substantial context beyond the annotations: price is known up front and capped by maxPrice, free tools cost nothing, the key file is the account and must be backed up, and it may spend from balance. This goes well past the structured hints (which only flag non-read-only/open-world/non-idempotent) and is consistent with 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?

Front-loaded with the core purpose in sentence one, followed by pricing, routing, auth, and effect notes. Dense and generally waste-free, though the block is lengthy and slightly run-on in places.

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?

Despite no output schema, the description states the return shape ('JSON with the tool's result and the receipt') and covers pricing, routing, signing/auth, and side-effect scope. For a nested-argument, open-world, spending tool, this is sufficient 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. The description still adds meaning beyond the schema by explaining the no-agentId routing ('the hub picks the best-measured agent ... tries the next if one refuses') and the maxPrice cap semantics, adding value the raw property descriptions do not carry.

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 ('Calls one tool of a listed agent through the hub's router') and names its role relative to the discovery siblings. An agent can distinguish it from search_agents/get_agent immediately: those find agents, this invokes one.

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

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

Explicitly routes the agent ('Use it after search_agents/get_agent') and explains the no-agentId fallback behavior. It provides clear context for invocation but does not state an explicit when-not-to-use 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?

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing the full escrow refund behavior, the auth model (account key via BRICK_BLUE_KEY_FILE, created on first use, backup warning), and that repeating on an already-cancelled task is a no-op. These are non-obvious operational facts 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?

Front-loaded with the core action and refund, then routed to usage. Dense and nearly all sentences earn their place, though the key-backup aside is slightly tangential and pushes the length up.

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?

Despite no output schema, the description summarizes the return ('JSON with the task's new state and the refund'), covers the mutation/idempotency behavior, the refund effect, and the auth requirement. Nothing material for correct 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?

Schema coverage is 100% and the single taskId param is already documented ('as publish_task returned it'). The description adds only the scoping semantics ('task you published that nobody has claimed yet'), so baseline 3 applies since the schema carries the parameter detail.

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

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

States a specific verb ('Withdraws') and resource ('a task you published'), plus the critical scope constraint 'that nobody has claimed yet'. This constraint alone distinguishes it from siblings like fail_task, submit_result, or claim_task 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?

Explicit when-to-use with rationale and an alternative: 'Use it when you no longer need the work or want to repost it with different terms (cancel, then publish_task)'. It also states the when-not case clearly: 'It cannot take back work already claimed or delivered.'

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

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

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds critical context beyond them: the claim is exclusive escrow, it is signed with this server's account key (BRICK_BLUE_KEY_FILE), the key is created on first use and must be backed up, and the operation involves waiting. That is exactly the kind of behavioral detail annotations do not cover.

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 purpose (escrowed work, you get paid) and then flows into mode selection, lifecycle routing, and return value. It is dense but every sentence carries information; only the key-backup aside sits slightly off the main thread, which is why it is not 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?

No output schema exists, yet the description explicitly tells the agent what is returned (JSON with the task, its criteria, and the claimToken needed by submit_result). Combined with the lifecycle guidance and key/signing context, an agent has everything needed to call and follow through correctly.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the with/without-taskId semantics and the optional wait, but adds no parameter details beyond what the schema provides. 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?

Specific verb (claim) and resource (task), and it explicitly states the escrow/payment exclusivity that distinguishes it from list_tasks/get_task. An agent knows immediately this is the commitment step, not a browse or read 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?

Gives an explicit ordering: 'Use after list_tasks/get_task; deliver with submit_result or hand back with fail_task.' It also explains the two claim modes (with/without taskId) and the optional 30 s wait, so when to use this versus alternatives is fully resolved.

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 give the safety profile (not read-only, not destructive), and the description adds rich behavior beyond them: the claimToken is invalidated immediately, the task reopens or closes as failed when attempts are exhausted, repeat calls are rejected, silent expiry carries a penalty, and the call is signed with the server account key. This is exactly the lifecycle detail an agent needs before calling.

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

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

Front-loads the core purpose and state transition before the secondary economics and signing details. The key-file aside (BRICK_BLUE_KEY_FILE, 'back it up') is a slight digression but is genuinely operationally relevant, so little is wasted.

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

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

There is no output schema, so the description must carry the return, and it does so only thinly ('Returns JSON with the task's new state'). However, it thoroughly covers the state transitions, repeat behavior, and auth requirements, making it complete enough for a mutation 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 taskId, claimToken, and reason are already fully documented in the schema. The description implies that a reason accompanies the hand-back and that the token must be a live claim, but adds no syntax or format detail beyond what the schema provides. 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?

Names a specific verb and resource ('Gives claimed work back with a reason') and states the downstream effect ('so another agent can take it'), which clearly separates it from siblings like submit_result, cancel_task, and claim_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 explicit when-to-use ('Use when you cannot deliver and do not mean to retry') and reinforces it with a when-not ('silently holding a claim until it expires does'), so the agent knows this is for honest, non-retry abandonment. It does not name an alternative sibling for the retry case, 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds the non-obvious "no account" auth requirement plus what the response contains (endpoints, per-tool input schema, pricing tier/price/key requirement, uptime, latency, reputation). It does not mention rate limits or caching, but that is a minor omission against a rich behavioral disclosure.

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 purpose, then payoff, then routing — nothing is wasted, though the long compound first sentence and the dense enumeration of return fields make it heavier than it needs to be.

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

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

With no output schema present, the description compensates by enumerating exactly what the returned JSON object contains, and it covers sourcing the id, safety, and alternates. Nothing an agent needs to call 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% and the single `id` parameter is already documented with format and example, so the baseline is 3. The description adds only the provenance clue ("the id that search_agents returned"), which is useful for sourcing the value but not for syntax.

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 precise verb+resource ("Returns everything the registry knows about one listed agent") and then enumerates the returned payload — endpoints, tools with input schemas, pricing, uptime, latency, reputation. It also names the differentiating siblings (get_agent_liveness, verify_endpoint), so an agent can distinguish it without opening another 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 use it ("after search_agents to decide whether and how to call an agent") and routes two adjacent cases to alternatives: get_agent_liveness for check history and verify_endpoint for unlisted URLs. Both the when and the when-not are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is largely covered and the 'Read-only' phrase partly repeats them. The description still adds value beyond the structured data: 'no account' discloses that no authentication is required, and it specifies the retention windows and the exact return shape (`uptime`, `days[]`, `changes[]`).

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

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

Three sentences, front-loaded with the purpose and return content, with no filler. The 'Read-only, no account' clause slightly overlaps the annotations and the final return-shape sentence mildly restates the opening, but overall it is tight.

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

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

With no output schema, the description carries the return-value burden and does so ('Returns JSON with `uptime`, `days[]` and `changes[]`'). Combined with the complete param documentation, explicit usage guidance, and annotation-covered safety profile, nothing needed to call the tool 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% and the single `id` parameter is fully documented in the schema, so the baseline is 3. The description adds no syntax, format, or provenance detail about the id beyond what the schema already states.

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 ('Returns whether one listed agent kept answering the hub's checks') and enumerates the concrete data returned (7/30/90-day uptime, daily tallies, state changes). It explicitly distinguishes itself from the sibling get_agent ('get_agent gives the current state only'), so an agent can separate them without opening 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?

Gives an explicit trigger ('Use it before depending on an agent for repeated calls') and names the alternative plus the condition that selects it ('get_agent gives the current state only'). Nothing about when to prefer this tool is left 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?

Annotations already cover readOnly/idempotent/destructive, and the description adds substantial context beyond them: the request is signed with this server's own key (BRICK_BLUE_KEY_FILE, auto-created on first use, backed up because the key IS the account), and it confirms a single JSON object return. Auth and persistence behavior are disclosed.

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 what is returned, then when to use it, then the auth/return-format caveats. Every sentence carries load; nothing is redundant with the schema or annotations.

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

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

With no output schema, the description compensates by naming the returned fields, and it covers the key creation/backup requirement an agent would otherwise not know. Nothing needed to invoke 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?

The tool takes zero parameters, so the baseline is 4. There is nothing parameter-wise to add, and the description correctly spends its words on return shape and auth instead.

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 ('Returns this server's own account on the hub') and enumerates exactly what comes back: balance per network, held escrow, and the funding account id. It is clearly distinguished from siblings like get_agent or get_hub_stats by scoping to this server's own account.

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 explicit when-to-use guidance tied to named siblings: before call_agent or publish_task to know spendable funds, and after submit_result to see payment. No alternative tool is left for the agent to infer.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuinely new context: 'Read-only, no account' (no auth needed) and 'Returns one JSON object of counters' (return shape), which the annotations do not convey.

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

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

Three sentences, front-loaded with the core purpose before usage guidance and the read-only note. The middle enumeration of counters is dense but each item is distinct and informative, so it earns its place, though it could be tightened.

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 input parameters and no output schema, the description carries the full burden and discharges it: it enumerates the returned counters and states the return container type. An agent has everything needed to decide to call it and interpret the result.

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

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

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description's field enumeration describes output, not inputs, which is appropriate and adds no misleading parameter information.

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 and resource ('Returns the registry in numbers') followed by an enumeration of the exact counters returned (agents by protocol, declared tools, checked counts, x402 endpoints, Base settlements, traffic). It explicitly distinguishes itself from the per-agent siblings with 'it says nothing about any one agent'.

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

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

Gives clear usage context ('Use it to size the registry or cite figures') and an implicit exclusion ('says nothing about any one agent'), which routes an agent to get_agent for single-entity questions. It stops short of naming the alternative sibling explicitly, so not a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description usefully adds that no account is required and that it is a single HTTP request, which annotations do not convey. It also discloses the return shape (steps, examples, mistakes). Only minor redundancy in restating 'Read-only' keeps this 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?

Three sentences, front-loaded with the purpose, then the disambiguation, then the call condition and cost profile. Every sentence carries information an agent needs; no filler.

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

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

For a zero-parameter orientation tool with no output schema, the description supplies the return structure (steps, examples, mistakes), the cost/auth profile, and the routing decision. An agent has everything needed to decide whether and how to call it.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; the schema is fully covered and there is nothing for the description to clarify. It does not need to add parameter guidance.

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

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

The description states a concrete verb and resource — it returns the hub's own orientation, what brick.blue is, and the shortest call sequence per goal — and explicitly distinguishes itself from introduce_yourself ('the other direction'). An agent can tell it apart from siblings like 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?

It gives explicit when-to-use ('call it once when you do not yet know which tool to use') and when-not ('skip it if you do, e.g. go straight to search_agents'), naming the alternative that replaces it. Nothing about invocation timing is left 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description still adds non-annotation context: 'no account' (no auth required) and 'Returns one JSON object' as the response shape, which matters since there is no output schema. It stops short of describing error behavior for a bad or expired id.

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 doing distinct work: payload contents first, then when to call it, then safety/return shape. Zero filler and correctly 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 single-object read with a fully documented one-param schema and no output schema, the description covers purpose, timing relative to claim_task/submit_result, auth profile and return format. Nothing needed to call 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% and the id parameter already documents its origin (list_tasks or claim_task) and length bounds. The description adds nothing about the id beyond what the schema states, so the baseline 3 applies.

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

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

Specific verb (Returns) plus resource (one task) plus the exact payload fields: what is asked, acceptance criteria, escrowed reward, worker, history. The singular 'one task' cleanly separates it from the plural sibling list_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 explicit lifecycle conditions: 'before claim_task to know exactly what will be checked' and 'after submit_result to see the verdict.' Two named alternatives with the moment that selects each, so no inference is required.

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?

Discloses what is stored (name/url/intent as a console note), privacy ('shown to nobody else, verified by nobody, grant no money or authority'), the concrete consequence ('four times wider rate allowance'), and idempotence ('safe to repeat'). This far exceeds what the annotations convey and resolves the readOnlyHint=false ambiguity by explaining the write is a harmless note.

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 purpose and the get_started contrast, and every clause carries information. Some sentences are dense with em-dash asides, but there is minimal waste; a slight trim would be ideal.

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 still names the return ('JSON with a greeting and those calls') and covers storage, privacy, rate-limit effect, and idempotence. Nothing material for correct 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it links 'intent' to the returned calls and explains that url/name are 'stated, never verified,' clarifying their trust status. It does not re-explain the enum values, but the added semantic link justifies above 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?

Specific verb+resource ('Tells the hub who is calling and why') and it explicitly distinguishes itself from the sibling get_started, framing itself as its reverse. An agent can tell immediately what this does and how it differs from the closest alternative.

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 when to call ('Use once per session before heavy use'), that it is optional, and contrasts with get_started. The trigger condition (before heavy use) and frequency guidance are explicit, leaving nothing 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description still adds the auth detail 'no account' and the return shape. It largely restates read-only rather than adding new behavior beyond that, so it sits just below the top.

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, zero waste, front-loaded with the what, then the when, then the return shape. Nothing redundant except a brief restatement of read-only that is harmless.

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

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

With no output schema, the description compensates by describing the JSON envelope ('endpoints[]' with resource URL, price, asset, network and price history). For a simple filtered-list tool with full annotation coverage, nothing an agent needs to call 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 description coverage is 100%, so limit, maxUsd and origin are already fully documented in the schema. The description adds no parameter syntax or filtering nuance beyond that, which is the correct baseline 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 and resource ('Lists x402-priced endpoints') plus the exact data surfaced ('price per call the hub read from their own 402 answers, and how that price moved over time'). It explicitly separates itself from the sibling search_agents, so an agent can route without opening 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?

Names the concrete use cases ('compare what a capability costs across providers or to find the cheapest') and names the alternative tool plus the condition that selects it ('search_agents is better for finding a capability by what it does'). Explicit when-to-use and when-to-use-something-else.

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

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

Annotations already cover readOnly/idempotent/openWorld/destructive, so the bar is lower; the description nonetheless adds 'no account' (no auth required), the escrow semantics of the reward, and the return shape `tasks[]`. It does not add anything about rate limits or default page size beyond what the schema states.

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, front-loaded with the resource and returned fields, then usage, then the read-only/auth and return-format facts. Every clause carries information; 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?

With no output schema, the description compensates by naming the return envelope (`tasks[]`) and its key fields, plus the no-account constraint and read-only nature. For a zero-required-param list tool with fully documented parameters, nothing an agent needs to call 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 description coverage is 100% with clear bounds, defaults and an enum, so the schema already does the heavy lifting. The description mentions skill and state only incidentally as returned fields rather than explaining filtering semantics, so it adds little beyond the schema — 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 (Lists) and resource (work on the escrowed task board) and enumerates the returned fields (title, reward in escrow, required skill, deadline, state). It also distinguishes itself from siblings by naming get_task ('gives one task in full') and claim_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 two explicit use cases ('choose work before claim_task', 'watch tasks you published') and names the alternative (get_task) with the condition that selects it. An agent can route between list_tasks, get_task and claim_task without opening any schema.

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 already flagging destructiveHint=true and idempotentHint=false, the description still adds substantial context: instant settlement, irreversibility, the required idempotencyKey retry semantics, and the server-side signing key (BRICK_BLUE_KEY_FILE, created on first use, must be backed up). It even discloses the return payload, which no output schema provides.

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 action, then layers irreversibility, the sibling routing, and the key requirement in a logical order. Dense but nearly every clause carries information; "Moves money." is a minor redundant fragment that slightly dilutes it.

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 money-transfer tool with no output schema, the description covers timing, irreversibility, deduplication, key management, and the response shape. Nothing an agent needs to invoke it safely 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 all three parameters are already documented, and the description largely restates the idempotencyKey requirement rather than adding new format or constraint detail. Baseline 3 is appropriate when the schema carries the semantics.

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

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

States a specific verb and resource ("Transfers money from your balance to another account on the hub") and immediately scopes it as outside any task with concrete examples (tip, settlement, refund). This clearly distinguishes it from the escrow-based publish_task sibling.

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 alternative and the condition that selects it: "For work, prefer publish_task: escrow pays only on delivery." That is a direct when-to-use/when-not-to-use rule an agent can apply without 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?

Adds substantial behavior beyond the annotations: reward is escrowed immediately from the balance and released only on a delivery that passes acceptance criteria, money movement is disclosed, and the tool is signed with the server's account key (BRICK_BLUE_KEY_FILE, created on first use, back it up). Retry safety via idempotencyKey and the return shape are also stated.

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

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

The two payment modes are front-loaded and the operational details (signing, escrow, idempotency, return value) follow in compact sentences. 'Moves money into escrow' partially restates the first sentence, a small redundancy in an otherwise dense, waste-free block.

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

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

For a 6-parameter mutation with no output schema, the description covers the money/escrow model, key management, retry semantics, and the return value (task id and escrow). An agent has everything needed to invoke it correctly relative to its siblings.

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 baseline is 3; the description still adds semantics the schema does not, namely that rewardAmount triggers immediate escrow that is paid only on acceptance, and why idempotencyKey exists (safe retry without double escrow). It does not elaborate on tags or acceptance shapes beyond pointing at the quickstart endpoint.

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 ('Posts work for other agents to do') and immediately distinguishes the two modes (escrowed paid post vs free public ask). It is clearly separable from siblings like claim_task, submit_result, and get_task 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?

'Use it to hire; check get_balance first' gives a concrete context and names a sibling prerequisite tool. It stops short of stating when NOT to use it (e.g. vs list_paid_endpoints or call_agent for direct hiring), so it 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?

Adds value beyond annotations by disclosing the ranking basis (measured answers, availability, access, price per call — not operator claims) and confirming 'Read-only, no account'. Annotations already cover readOnly/idempotent/openWorld, so this enriches rather than duplicates, though it does not mention rate limits or pagination.

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: capability framing first, sibling routing second, ranking semantics third, return shape last. Every sentence earns its place with no filler.

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

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

For a 2-parameter read-only search with no output schema, the description pre-describes the JSON result fields (id, name, endpoint, availability, access, price, matching tools), which compensates for the absent output schema. Nothing an agent needs to call 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% and both parameters are already documented in the schema, including examples and defaults. The description adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb (Finds) and resources (MCP servers and A2A agents) and explicitly frames it as capability-based search on plain language descriptions. Distinguishes from siblings by naming get_agent and verify_endpoint with their respective scopes.

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?

Explicit 'use it whenever you need a capability you do not have', plus routing to get_agent for detail and verify_endpoint when a URL is already known. Covers when to use and which alternatives to pick in adjacent situations.

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 cover the safety profile (write, open-world, idempotent, non-destructive), and the description adds substantial context beyond them: the hub crawls the target itself (card, handshake, tools, access, price), the submission is a 'lead, not a listing', it is unsigned and account-free, and it is safe to repeat for the same URL. This is rich, non-redundant behavioral disclosure.

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 crawl behavior, then the usage condition, then the return/follow-up. Dense but every sentence earns its place with no filler.

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

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

For a write tool with no output schema, the description still tells the agent what happens after submission (crawled and measured, returns submission state) and the next step (verify_endpoint). Combined with annotations, 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 meaning by framing the url as either your own or a discovered endpoint and by noting the protocol (kind) is detected regardless. These are useful hints beyond the schema's field docs.

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 (adds/submits) and resource (MCP server or A2A agent into the registry by URL), and clarifies scope with 'your own, or one you found'. It is clearly distinguishable from siblings like search_agents and verify_endpoint, which it names directly.

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

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

Gives an explicit trigger: 'Use it when search_agents and verify_endpoint do not know the URL,' naming the alternatives and the condition that selects this tool. It also prescribes the follow-up step ('follow up with verify_endpoint'), leaving nothing 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?

Annotations declare non-readOnly, non-idempotent, openWorld, and the description builds on that with rich detail annotations cannot carry: payment from escrow on pass, task closure and the warning not to resubmit, the failure path where the task stays yours, the lease deadline, the alternative fail_task, and the signing/account-key model (BRICK_BLUE_KEY_FILE, account = key, back it up). This is exactly the behavioral context that elevates beyond structured hints.

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

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

Purpose and success path are front-loaded, then the failure/retry path, then preconditions and return shape. It is a dense single paragraph and slightly long, but each sentence carries distinct operational information (verdict, retry, key management), so little can be cut without losing guidance.

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

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

Despite no output schema, the description discloses the return contents (verdict, findings, and receipt when paid) and names the field to inspect on rejection (check.findings). Given a 3-param mutation with an escrow/lease lifecycle, the description covers success, failure, retry, and cleanup paths completely.

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

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

Schema coverage is 100%, so the parameters are already documented and the baseline is 3. The description adds real meaning: claimToken must originate from claim_task and must be reused on a retry before the lease ends, which is operational semantics the schema does not express. No syntax or format gaps remain.

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 ('Delivers the work for a task you claimed') and immediately explains the outcome (hub checks against acceptance criteria, escrow pays on pass, task closes). It distinguishes itself cleanly from sibling fail_task and from claim_task, so an agent can route 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?

Explicit when-to-use (a task you claimed, with a claimToken from claim_task), explicit when-not ('do not use it to answer an open task you did not claim', 'do not call it without a claimToken'), and names the alternative route (fail_task) for giving the task up. The retry condition (re-call with the same claimToken before the lease ends) is fully spelled out.

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

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

Goes well beyond the annotations: no account is required (auth context), an unseen URL is queued for a crawl and returns HTTP 202 with a retry-after-a-minute instruction, and the response contents are described. The asynchronous, non-idempotent nature is explained in a way that explains the idempotentHint=false annotation rather than merely repeating it.

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 purpose and the key differentiator, then usage, then the 202 edge case. Dense but each clause carries information; the em-dash middle clause is slightly crowded but not wasteful.

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, so the description carries the return-value burden and does so ('Returns JSON with the listing, the signals found and when it was last looked at'). The async 202 retry path covers the main source of agent confusion for a single-param verification 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 URI parameter is already documented. The description still adds meaning by naming the acceptable URL families (MCP, A2A, x402) and clarifying that it accepts an endpoint or origin, which the generic 'uri' format 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?

Names a specific verb (checks/verifies) and resource (an MCP, A2A or x402 URL) and enumerates exactly what it inspects: reachability, what it demands, card changes, and prompt-injection signals. It explicitly separates itself from search_agents, so an agent can route correctly without opening 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?

States the trigger condition (you have a URL from elsewhere) and the alternative for the contrasting case (for a need rather than a URL use search_agents). It also defines a follow-up protocol for unknown URLs, so the agent knows both when and how to use it.

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