Human Pages

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

With no annotations, the description carries full weight. It discloses that approval 'finalizes the job' and moves it to COMPLETED, and flags the need for user confirmation. It doesn't detail error handling or idempotency, but the key irreversible behavior is clearly stated.

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

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

Three concise sentences plus an important callout. Every sentence earns its place: action, confirmation warning, sequencing with siblings. Front-loaded with the verb and scoped to the SUBMITTED state.

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

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

Given the tool's state-transition nature and no output schema, the description provides the necessary workflow context: check messages first, approve, then leave_review, or request_revision instead. It doesn't cover error scenarios, but the core task and surrounding workflow are well covered.

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?

Input schema covers 100% of parameters with descriptions ('The job ID', 'Your agent API key (hp_...)'). The description adds no parameter-specific syntax or format details 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?

The description opens with 'Approve submitted work for a SUBMITTED job' — a specific verb+resource — and clarifies the state transition 'Moves the job to COMPLETED'. It distinguishes from siblings by explicitly referencing 'request_revision' for changes and 'leave_review' after approval.

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 exactly when to call: 'Call this after reviewing the human's deliverables (check via get_job_messages)'. Provides explicit alternative: 'If the work needs changes, use request_revision instead' and warns to 'Confirm with the user before approving'. This gives clear sequential and conditional 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 provided, the description carries the full burden. It discloses two important behavioral traits: pending applications will be rejected, and a creator-only permission check. It does not mention return values or irreversibility, but these are secondary for a simple cancel operation.

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

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

The description is two sentences, front-loaded with the primary action, followed by a side effect and an access constraint. Every sentence earns its place with no wasted words.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the key aspects: purpose, side effect, and authorization. It does not explain what happens to the listing after cancellation, but this is not essential for invoking the 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 schema documents the parameters. The description adds value by linking agent_key to the creator of the listing, clarifying that the agent_key must correspond to the listing's creator. This goes beyond the schema's simple 'Your agent API key' and 'The listing ID'.

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: 'Cancel an open listing' with a specific verb and resource. It distinguishes itself from sibling tools like create_listing and get_listing, and no other sibling tool performs cancellation.

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

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

The description provides clear use context by scoping to 'open listings' and specifies an exclusion: only the creator agent can cancel. It does not mention alternative tools explicitly, but there are no alternative cancellation tools among siblings, and the ownership constraint serves as a when-not.

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 explicitly states the operation is read-only and details the return data (verified, score, tier, timestamp). However, it does not cover error cases (e.g., invalid human_id) or other side effects, making it adequate but not comprehensive.

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 three concise sentences, each serving a clear purpose: stating the main action, listing the return values, and noting the read-only nature. There is no redundancy or filler, and the key action 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?

The tool is simple with one required parameter, no output schema, and no annotations. The description sufficiently covers the return values and side-effect profile (read-only). It omits details like error behavior or score scale, but given the low complexity, it is largely 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?

The input schema already provides a full description for human_id ('The ID of the human to check') with 100% coverage. The description only reinforces this by saying 'for a specific human,' adding no additional semantic information. Baseline 3 applies per the rubric.

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 checks humanity verification status for a specific human, and it enumerates the returned fields (verified, score, tier, when verified). This specific verb+resource combination distinguishes it from broader sibling tools like get_human or get_human_profile.

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

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

The description makes it evident that this tool is for checking a specific human's verification status, providing clear context. However, it does not mention exclusions or alternatives, such as when to use get_human instead, so it lacks explicit alternative guidance but is still 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?

The description discloses that the endpoint is a no-op for agents already on PRO and is deprecated, which is key behavioral information. However, it is ambiguous whether it is a no-op for all agents or might act for non-PRO agents, and it does not mention response behavior or error handling. Since no annotations are present, the description carries the burden but only partially covers 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?

The description is two concise sentences, front-loaded with 'Deprecated,' and every word provides relevant context. There is no wasted space or redundant information.

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

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

For a deprecated simple tool with one parameter and no output schema, the description covers the essential context: it tells the agent this is legacy and likely a no-op. The ambiguity about non-PRO agents and lack of response details prevent a perfect score, but the overall information is sufficient for an agent to understand the tool's current status.

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

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

The input schema already describes the only parameter (agent_key) with full coverage (100%). The description adds no additional meaning about the parameter, such as how it affects behavior or whether it is still required, so it does not improve on the schema 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?

The description clearly identifies the tool as deprecated and a no-op for PRO agents, which conveys its current purpose (legacy endpoint). It uses a specific verb ('claim') and resource ('free pro upgrade') but the primary purpose is to indicate it does nothing, which is clear enough. It does not explicitly state what happens for non-PRO agents, so slight ambiguity remains.

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

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

The description explicitly states the tool is deprecated and that agents are auto-activated on PRO tier at registration, making it clear that this tool should not be used. This is strong when-to-not-use guidance, effectively telling the agent it is unnecessary. No alternative is named, but the instruction is unambiguous.

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

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

With no annotations, the description carries the full burden. It discloses recipient notification, accept/reject behavior, agent_key requirement, rate limit (PRO = 15/day), flexible payment method, and post-creation steps (poll or webhook). It does not mention return output or cancellation behavior, but covers most key behavioral aspects.

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 fairly long but well-structured, front-loaded with the purpose and critical confirmation requirement, followed by workflow. Each sentence adds value, though it could be tighter without losing 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 complex tool with 20 parameters and no output schema, the description covers a lot: workflow, rate limit, payment method, webhooks, and next steps. Minor gaps like error handling and offer cancellation are not addressed, but the overall context is solid.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds high-level context (confirm price/payment) and references agent_key and payment flexibility, but does not add new per-parameter meaning beyond what the schema already provides.

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

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

The description clearly states 'Send a job offer to a specific human', using a specific verb and resource. It unambiguously distinguishes this from listing offers and other job-related tools, even though it does not name 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?

Provides clear workflow context (search_humans → get_human_profile → create_job_offer → mark_job_paid → approve_completion → leave_review) and an important directive to always confirm price/task/payment with the user before calling. It stops short of explicit 'when not to use' or alternative-tool comparisons.

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 burden of disclosing behaviors. It mentions the public nature of the board, the requirement for agent_key, the rate limit (PRO = 5/day), and the application process (humans apply with a pitch). It does not explicitly describe the response or side effects like cancellation, but the core behaviors 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?

The description is four sentences, each adding distinct value: purpose, usage contrast, workflow, and constraints. It is front-loaded with the main action and avoids redundancy. Every sentence earns its place, making it concise and well-structured.

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

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

Given the tool's complexity (21 params, no output schema), the description provides essential context: the job-board workflow, rate limit, auth requirement, and a fallback use case. However, it does not mention what the API returns (e.g., listing ID) or how to handle errors, which would make it fully complete. The schema fills in param details, so the description is almost sufficient.

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

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

The schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The tool description itself adds little parameter-specific meaning beyond the schema, only mentioning agent_key and rate limit in passing. Since the schema already explains each field, the description does not reduce the need for schema lookups.

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: 'Post a job on the public job board.' It clearly differentiates from the sibling tool create_job_offer by stating the contrast ('targets one person') and also notes a use case related to search_humans. This makes the tool's purpose unambiguous.

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

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

Explicit guidance is provided: 'Use this when you don't have a specific human in mind (vs create_job_offer which targets one person).' It also suggests using it 'when search_humans returns no results,' giving clear decision criteria. The workflow (review applicants, hire) is outlined, making it evident when to invoke this tool versus 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 provided, the description carries the full burden. It clearly discloses what the tool returns (tier, activation, rate limits, expiry, optional x402 pricing) and implies a read-only operation. No contradictions exist, and it adds useful behavioral context beyond just the tool name.

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

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

The description is two sentences, front-loaded with the primary purpose, and every clause provides value. No redundant wording or 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?

Given there is no output schema and no annotations, the description adequately enumerates the key return items (tier, activation, rate limits, expiry, optional pricing). It misses minor edge cases like error handling, but for a simple status getter, it is sufficient.

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

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

Schema description coverage is 100% since the only parameter (agent_key) has a description. The tool description adds no additional semantic detail about the parameter, so the baseline of 3 is appropriate; it doesn't fail but also doesn't enhance.

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 'Check' with a clear resource ('your agent's current tier, activation status, rate limit usage, and expiry date'). It distinguishes this from sibling tools like get_payment_activation and get_promo_status by focusing on agent status and quota details.

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 explicitly states when to use the tool: 'Use this to understand your remaining quota.' While it doesn't mention when not to use it or name alternatives, it provides a clear use case that is distinct from 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds context by saying 'public profile', implying read-only access and no special permissions, and lists specific return data. However, it does not explicitly state that the operation is read-only, nor does it describe error behavior (e.g., what happens if the agent is not registered).

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, concise and front-loaded with the action and target. Every word adds value without redundancy or irrelevant details.

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 getter with one parameter and no output schema, the description adequately covers the purpose and key return fields. It lacks details on exact response structure or error handling, but given the low complexity, it is sufficiently complete for an agent to use the tool effectively.

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

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

The schema already describes agent_id as 'The registered agent ID' with 100% coverage. The description restates 'registered agent' but does not add new details about the parameter's format, constraints, or valid values. Since schema coverage is high, 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?

The description clearly states the verb 'Get' and the resource 'a registered agent's public profile', and specifies the included reputation stats (total jobs, completed jobs, payment speed). This distinguishes it from sibling tools like get_human_profile by focusing on agents and their reputation.

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 an agent's public profile and reputation stats are needed, but it does not explicitly state when to use this tool over alternatives or mention exclusions. The phrase 'registered agent' gives some context, but no direct comparison to siblings like get_human_profile is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return contents and the intended user role (arbitrator). The verb 'Get' implies a read-only operation, and the description adds context beyond the schema by listing specific data fields.

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

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

The description is two concise sentences. It front-loads the purpose, then lists return items, and ends with usage context. No wasted words or redundancy.

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

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

Since there is no output schema, the description appropriately explains return values (job info, messages, evidence, amounts, deadline). It also provides context on when to use (before submitting a verdict). It is nearly complete, though it does not mention error conditions or explicit read-only guarantees, which are less critical for this tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; the meaning of 'job_id' and 'agent_key' is fully described in the schema.

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

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

The description specifies the verb 'Get' and the resource 'full case details for an escrow dispute', listing concrete return items (job info, messages, evidence, amounts, deadline). This clearly distinguishes it from sibling tools like get_job_messages or get_job_status, which focus on other aspects.

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 explicitly states 'Used by arbitrators to review a case before submitting a verdict', providing clear context for when to use. It does not mention alternatives or exclusions, but the intended workflow is well 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 discloses prerequisites (wallet must exist), parameter behavior (country influences recommendations), and expected workflow (present options to developer). It stops short of detailing the exact response format or error cases, hence a 4 rather than 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?

Four sentences of moderate length. The purpose is front-loaded, but the wallet creation guidance appears twice in slightly different forms, making it slightly redundant. Still compact enough for a 4.

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?

Covers prerequisite, parameter usage, and high-level output. Lacks explicit output schema details, but the description sufficiently sets expectations for a tool with no output schema. A 4 is justified given the clear workflow and responsibilities.

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 already covers all three parameters (100% coverage), so baseline is 3. The description adds meaningful context for the country parameter ('if known', 'best rates') and reaffirms the role of agent_id/agent_key as credentials, elevating it to 4.

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: 'Get funding instructions and current wallet balance.' It clearly distinguishes from sibling tools by focusing on funding guidance, and later clarifies the tool's role in presenting onramp options.

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 explicitly instructs the agent to create a wallet via CDP AgentKit before using this tool, and clarifies when to pass the country code. It also delineates agent versus developer responsibilities, which serves as a usage guideline.

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 full burden. It discloses the returned fields (bio, skills, reputation, etc.), exclusions (contact info, wallets), and the source of the ID. While it doesn't mention error behavior or authentication, it's public profile info, so this is adequate but not exhaustive.

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

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

The description is front-loaded with the core action, uses a compact list of fields, and consists of three sentences each serving a purpose. No fluff or redundancy.

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

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

For a simple one-parameter tool with no output schema, the description is complete: it lists all return fields, clarifies exclusions, cites the alternative tool, and explains where to find the ID. No significant gaps.

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

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

The input schema already covers the single 'id' parameter with a description (100% coverage). The description adds value by stating the ID can be found in search_humans results, providing contextual information beyond the schema.

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

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

The description clearly states the tool's function: 'Get a human's public profile by ID' and enumerates the exact fields returned. It also distinguishes itself from the sibling get_human_profile by explicitly noting exclusions and pointing to the alternative, which is strong differentiation.

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

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

The description explicitly provides when to use this tool vs. alternatives: 'Does NOT include contact info or wallets — use get_human_profile for that (requires agent_key).' It also gives a practical hint on finding the ID via search_humans results, offering clear usage context.

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. It discloses auth requirement (agent_key from register_agent), rate limit (PRO = 50/day), and a cost alternative (x402). This goes beyond basic introspection, though it does not describe failure responses or edge cases.

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

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

The description is compact yet information-dense: each sentence adds new, relevant context (purpose, prerequisites, rate limit, alternative, usage timing, parameter source). No filler words; front-loaded with the core action.

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

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

For a tool with no annotations and no output schema, the description covers purpose, contents, auth, rate limiting, cost alternative, and parameter source. It lacks explicit error/return behavior, but given the simple read operation and rich context, it is nearly 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% (both params have descriptions). The description adds value by stating human_id comes from search_humans and that agent_key is obtained from register_agent, reinforcing and enriching the schema meaning.

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 clearly that it retrieves a human's FULL profile with enumerated details (contact info, wallets, payment methods, social links). Distinguishes from siblings like get_human by specifying 'FULL profile' and gives a direct use-case ('Use this before create_job_offer').

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

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

Provides explicit use case ('Use this before create_job_offer to see how to pay the human'), notes an alternative ($0.05 via x402), and specifies that human_id comes from search_humans. Does not explicitly list exclusions (e.g., when to use get_human instead), but gives strong contextual 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?

No annotations are provided, so the description must disclose behavior. It states the return content ('messages from both agent and human with sender info and timestamps') and ordering ('chronological'), which is useful. However, it does not explicitly confirm that the operation is read-only or describe error/edge-case behavior, leaving some transparency gaps.

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

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

The description is two sentences: the first defines the purpose and output, the second gives usage context. Every word earns its place, with no redundancy or 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 simple read tool with 2 well-documented parameters and no output schema, the description covers what it returns, the ordering, and when to use it. It does not mention pagination or empty-result behavior, but these are minor for this tool's simplicity.

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 both parameters (job_id and agent_key) already documented. The tool description adds no additional parameter-specific meaning beyond what the schema provides, 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 tool's function with a specific verb 'Get' and resource 'messages for a job', adding 'chronological' and 'from both agent and human' to define scope. This distinguishes it from siblings like get_job_status (status) and send_job_message (sending).

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 lists three use cases: 'check for replies, review submitted deliverables, or follow up on work progress.' This provides practical context for when to invoke the tool, though it does not explicitly name alternatives or exclusions. The guidance is clear and actionable.

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

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

With no annotations, the description carries the full burden. It reveals the exact return fields (status, price, human name, next-step recommendation) and the full lifecycle including edge statuses (REJECTED/CANCELLED/DISPUTED, STREAMING, PAYMENT_PENDING_CONFIRMATION). This goes well beyond a typical get 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 three sentences, with the purpose front-loaded in the first sentence. The status list is dense but every clause adds meaningful detail about transitions and follow-up actions.

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?

Since there is no output schema, the description compensates by spelling out return fields and interpreting each status. It also covers streaming/fiat-specific statuses, making it fully adequate for its complexity.

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 single parameter job_id is fully described in the schema ('returned from create_job_offer'), so schema coverage is 100%. The description adds no additional parameter semantics, but the schema already carries the load, warranting baseline 3.

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

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

The description uses a specific verb 'Check' with a specific resource 'status of a job,' and enumerates the status values. It distinguishes from sibling tools like get_activation_status or get_funding_info by focusing solely on job status.

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

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

It sets clear context: use to check current job status. It even provides conditional next-step guidance, e.g., under SUBMITTED use approve_completion or request_revision, under COMPLETED use leave_review. However, it does not explicitly name alternative tools or exclusions, so it stops short of full usage 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?

No annotations are provided, so the description must carry the full burden. It discloses some return content (posting agent's reputation, application count), but does not mention side effects, authentication requirements, error behavior, or confirm it is read-only. The 'Get' verb implies a read operation, but more explicit transparency would be beneficial.

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, clear sentence that front-loads the core verb and object ('Get detailed information about a specific listing') and then adds relevant specifics. No filler or redundant text, making it highly concise and well-structured.

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 one-parameter read tool with no output schema, the description is adequately complete: it states the purpose and highlights key return fields (reputation, application count). It could mention error behavior or that it retrieves by ID, but the schema covers the ID, and the tool is simple enough that the description suffices.

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

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

Schema description coverage is 100% for the single 'listing_id' parameter, so the baseline is 3. The description does not add any extra meaning beyond the schema's 'The listing ID' — it only refers to 'a specific listing', which adds no new 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 ('Get') and resource ('listing'), and adds differentiating details: it's for a specific listing and includes the posting agent's reputation and application count. This clearly distinguishes it from siblings like get_listings (plural) and get_listing_applications.

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 for a single, specific listing via the word 'specific', which differentiates it from get_listings. However, it does not explicitly name alternatives or provide exclusion conditions, so it has clear context but no explicit when-not-to-use 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 provided, the description carries the full burden. It discloses an important behavioral constraint (creator-only access) and describes what data is returned. However, it does not explicitly mention that this is a read-only operation with no side effects, nor does it address pagination or error cases. The 'View' verb implies read-only, but explicit confirmation would be more transparent.

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: two sentences. The first sentence states the purpose and return value, the second gives usage guidance and an access constraint. Every sentence adds value, and the structure is front-loaded with the 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?

Given that the tool has no output schema, the description adequately explains return values (applicant profile fields and pitch message). It also covers usage context, permission constraints, and the natural next step (make_listing_offer). This is complete for an agent to use the tool correctly.

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

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

The input schema has 100% coverage with clear descriptions for both parameters (agent_key, listing_id). The description adds no additional parameter-specific meaning beyond the schema. The baseline of 3 is appropriate since the schema handles 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 states the action ('View applications for your listing') and specifies the resource (listings applications). It distinguishes itself from siblings by mentioning the follow-up action 'make_listing_offer' and the returned data (applicant profiles and pitch message). This is specific and unambiguous.

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

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

The description explicitly states when to use this tool: 'Use this to evaluate candidates, then hire with make_listing_offer.' It also gives a usage constraint: 'Only the listing creator can view applications.' This provides clear context and a direct alternative/successor, making it easy for an agent to decide when to invoke 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?

No annotations are provided, so the description carries the full burden. It discloses return fields, filter capabilities, pagination defaults/max, and response counts (total and pages). It implies a read-only browse operation but does not explicitly state side-effect-free status or authentication needs; still, it is quite transparent for a list-reading 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 three sentences with no fluff. Each sentence serves a purpose: first states purpose and output fields, second lists filters, third covers pagination. It is appropriately sized and 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?

No output schema exists, so the description must explain return values, which it does by listing return fields and pagination metadata. It covers all filter dimensions and pagination behavior. Missing details like error handling or optionality of location parameters are minor given the tool's simplicity.

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 reiterates filter types and pagination defaults that are already in the schema, adding no new parameter-specific semantics beyond reinforcing how they are used together (e.g., location parameters implied by 'location').

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 'Browse open job listings on the public board' with a specific verb, resource, and scope. It lists return fields and distinguishes itself from the singular sibling 'get_listing' through the plural 'listings' and browsing intent.

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

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

The description conveys clear context: this is for browsing and filtering multiple listings on the public board. However, it does not explicitly mention alternatives (e.g., 'use get_listing for a single listing') or provide when-not-to-use guidance, so it lacks explicit 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 burden. It states what the tool returns (a deposit address and payment instructions) but does not disclose potential side effects, authentication prerequisites beyond the agent_key, address expiry, or whether it initiates any state change. This is acceptable but not detailed.

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 clear sentence, front-loaded with the action and resource. No wasted words or redundant information.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core purpose but lacks usage context and does not enumerate the expected return fields beyond a vague 'deposit address and payment instructions.' It is minimally adequate.

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

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

The input schema already fully describes agent_key with 100% coverage. The description adds no extra meaning or usage details about the parameter, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get') and identifies the exact resource ('deposit address and payment instructions for PRO tier activation via on-chain payment'). It clearly distinguishes this tool from siblings like verify_payment_activation and request_activation_code.

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 is given on when to use this tool versus alternatives such as claim_free_pro_upgrade, request_activation_code, or verify_payment_activation. The purpose is implied but not compared to other activation-related tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses that no authentication is required and describes the return value (claimed and remaining slots). The read-only nature is implied by 'Check' and 'Returns', though it could explicitly state it does not modify any state.

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

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

The description is two sentences, front-loaded with the main purpose and then providing key details. Every word serves a purpose, with no filler or redundant information.

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

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

For a simple tool with no parameters and no output schema, the description covers purpose, return value, and authentication requirement. It could possibly mention the exact response format or any caveats (e.g., promo availability), but it is adequately complete for a status check of this simplicity.

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, so the input schema provides no information. The description adds context about what the status refers to (free PRO tier for first 100 agents) and what details are returned, which is valuable beyond the empty schema. Baseline for 0 params is 4, and the description satisfies that.

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

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

The description states a specific verb ('check') and a specific resource ('launch promo status'), and clearly explains what the tool does: it reports how many of the 100 free PRO slots are claimed and remaining. This distinguishes it from related siblings like 'claim_free_pro_upgrade' and 'check_humanity_status'.

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

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

The description clearly indicates this is a read-only status check for the promo, with no authentication required. While it doesn't explicitly name alternatives or state when not to use it, the context is clear for a simple tool of this nature.

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 provides useful behavioral context: the nonce expires in 5 minutes and the flow involves returning a message to sign. It does not explicitly disclose side effects or auth details, but for a nonce request, this is sufficient.

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 three sentences, front-loaded with the action, and every sentence earns its place. No fluff or redundancy.

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

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

For a simple nonce-request tool with no output schema or annotations, the description covers the essential context: the step in the verification flow, the expiration behavior, and the relationship to set_wallet. It could mention the return format more explicitly, but that is not critical for invoking 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 baseline is 3. The description does not add any additional meaning to the parameters beyond their schema descriptions, which already cover agent_id, agent_key, and wallet_address adequately.

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 'Request a signing challenge (nonce) for wallet verification,' using a specific verb and resource. It also distinguishes itself from set_wallet by positioning it as step 1, making it easy to differentiate from 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?

Explicitly states 'call this first, then sign the returned message... and pass the signature to set_wallet,' providing clear when-to-use guidance and naming the alternative/successor tool. This is exactly what the dimension asks for.

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 transparency burden and does so well: it discloses that reviews are visible on the human's profile and affect their reputation score in search results, plus the completion prerequisite. It could mention editability/permanence, but the key consequences 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?

Three short, information-dense sentences with no filler. The first sentence states the action and format, the second explains consequences, and the third reinforces the key constraint. Well-structured and 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 simple review tool with no output schema, it covers purpose, timing, visibility, and reputational impact. It doesn't explain return values or error cases, but these are minor gaps for the tool's simplicity and are not needed given the absence of an 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 coverage is 100% and each parameter already has a description. The tool description adds mild context (e.g., optional comment, 1-5 rating) but doesn't significantly expand beyond what the schema provides, 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?

Description clearly specifies the action ('Rate a human'), the resource (the human), and the required context ('after a COMPLETED job'), with a concrete rating scale ('1-5 stars + optional comment'). This distinguishes it well from sibling tools like request_revision or approve_completion.

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

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

The description explicitly states 'Only works on COMPLETED jobs' and 'after a COMPLETED job', giving clear timing guidance. It doesn't name alternatives or exclusions, but the primary usage condition is unmistakable.

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 transparency burden. It discloses the return payload (wallet address, fee format, specialties, SLA, health status, dispute track record) and the lack of authentication. While it doesn't explicitly state that the operation is read-only or non-destructive, 'Browse' implies such, and the detail about fee basis points adds valuable context. Slightly more could be said about output ordering or pagination, but the provided info is substantial.

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 concise 3 sentences: what it does, what it returns, and when to use it. Every sentence adds value, with no repetition or fluff. It is front-loaded with the primary action.

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 tool with no output schema and no annotations, this description is remarkably complete. It explains the return format (basis points example), the intended use case, and authentication status. It fully equips an agent to select and invoke the tool correctly.

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

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

The tool accepts zero parameters, so there is no schema to elaborate. The baseline for 0 params is 4, and the description appropriately focuses on the output and usage rather than parameters, which is correct.

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

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

The description clearly states the tool's purpose with a specific verb ('Browse') and resource ('available escrow arbitrators'), and lists the return fields (wallet address, fee, specialties, etc.). It also differentiates from sibling tools by explicitly tying usage to create_job_offer with payment_mode=ESCROW.

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

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

The description provides explicit usage context: 'Use this before create_job_offer with payment_mode=ESCROW to pick an arbitrator.' It names the exact preceding step and the payment mode, which tells the agent when to invoke this tool. It also mentions 'No authentication required,' a relevant guideline.

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 and does well by stating 'This is a binding commitment — you agree to pay the listed budget if the human accepts and completes the work.' This is a critical side effect not inferable from the schema. It also notes that a notification is sent to the human.

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 three sentences, each earning its place: the action, the key caveat, and the follow-up workflow. It avoids unnecessary detail and is front-loaded with the main 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?

For a tool with no output schema and no annotations, this description covers the purpose, prerequisites, workflow, and financial obligation. It lacks an explicit return value description but the subsequent flow (get_job_status → ...) implies how to track the result, making it sufficiently 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?

The schema already describes all three parameters, and the description adds meaning by pointing to get_listing_applications as the source for application_id. This helps the agent obtain the correct value, though it doesn't add details for listing_id or agent_key (already clear).

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 starts with a clear verb phrase 'Hire a listing applicant' and elaborates with 'Creates a standard job from the listing and notifies the human.' This distinguishes it from sibling tools like create_job_offer by being listing-specific.

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 explicitly instructs to get application_id from get_listing_applications, and after the offer, directs to follow the same flow as create_job_offer with a specific sequence. This provides clear when-to-use context, though it could more explicitly state when to choose this over create_job_offer.

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 full burden of behavioral disclosure, and it excels. It explains the two distinct payment paths (crypto vs fiat), the exact status transitions (PAID vs PAYMENT_PENDING_CONFIRMATION), the verification mechanism (on-chain instant vs human 7-day confirmation), and the requirement for user confirmation before operation. This is exceptionally transparent.

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

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

The description is compact and well-structured. It leads with the core purpose, then a critical warning, followed by method-specific behavior and a forward pointer to the subsequent tool. Every sentence earns its place with no fluff, and the use of bullets and bold/caps makes it scanable. Despite its length, it remains efficient for the complexity it covers.

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 no output schema and no annotations, the description is remarkably complete. It covers prerequisites, allowed job statuses, payment-method-specific flows, outcome statuses, and the next step in the workflow. It also includes an important human-in-the-loop guardrail. There are no significant gaps for a tool with this complexity.

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

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

The schema has 100% parameter coverage with descriptions for every field, providing a solid baseline. The description adds value by grouping payment_method into crypto/fiat categories and clarifying the relationship between payment_reference and payment_network for each path. While most parameter meanings are already in the schema, the description enriches the contextual semantics, so a 4 is appropriate.

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

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

The description opens with a clear verb+resource: 'Record payment for an ACCEPTED job.' It distinguishes the tool from siblings like approve_completion by explaining the full payment workflow and when the next tool should be used. The focus on job payment with status transitions makes the purpose unambiguous.

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

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

The description provides explicit usage conditions: the job must be in ACCEPTED status, and it directs the agent to check via get_job_status. It also specifies that payment details must be confirmed with the user before calling, and gives a clear alternative/next step: 'use approve_completion when done.' This fully covers when and how to use the tool versus 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 transparency burden. It reveals key behavioral traits: backend verification for Superfluid and tick-skipping for micro-transfer. It does not mention side effects or return values, but for a pause operation this is reasonable.

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

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

The description is two sentences long, front-loaded with the primary purpose, and contains no redundant information. Every word 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 the tool's simplicity and lack of output schema, the description covers the main behavioral variations and prerequisites. It could mention error conditions or resumability, but the current content is adequate for a pause 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?

The input schema already provides full descriptions for both parameters (job_id and agent_key) with 100% coverage. The description adds no parameter-specific context, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Pause an active stream') and specifies two protocol-specific variants (Superfluid and micro-transfer). This distinguishes it from sibling tools like stop_stream or resume_stream.

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 provides concrete usage steps for each protocol: for Superfluid, delete the flow first; for micro-transfer, skip the pending tick. However, it does not explicitly contrast with alternatives like stop_stream or resume_stream, leaving some ambiguity about when to use which.

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?

Without any annotations, the description carries the burden of explaining the tool's behavior. It discloses the key nuance that this only applies to MICRO_TRANSFER streams and that Superfluid is handled automatically, which adds important context. However, it does not mention any side effects, error conditions, or what happens after submission, leaving gaps for a write operation.

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

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

The description is two sentences long, front-loaded with the main verb and resource, and contains no fluff. Every clause serves a purpose: the first sentence states the action, the second provides crucial scope limitations. It is ideal for an AI agent to quickly grasp the tool's 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?

Given the tool's simplicity (3 required parameters, no output schema), the description is reasonably complete. It explains the specific scenario (micro-transfer tick payment), the input required (transaction hash), and the distinction from Superfluid streams. It could mention the outcome or potential failure modes, but the core context is sufficient for an agent to invoke it correctly.

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

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

The schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds extra meaning to the tx_hash parameter by specifying it is for the 'current pending tick', which clarifies how to use it. The other parameters (job_id, agent_key) gain no additional context from the description, but overall the description enriches the parameter semantics slightly.

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

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

The description clearly states the tool's function: 'Record a micro-transfer stream payment' with a specific verb and resource. It distinguishes itself from siblings by specifying that it is 'Only for MICRO_TRANSFER streams' and clarifying that 'Superfluid streams are verified automatically', which sets it apart from other stream-related tools like start_stream or stop_stream.

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

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

The description explicitly says when to use this tool ('Only for MICRO_TRANSFER streams') and when not ('Superfluid streams are verified automatically'). It provides a clear exclusion but does not name an alternative tool for Superfluid streams, so it falls slightly short of a 5 that would require 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 fully owns the transparency burden. It discloses the most critical behavioral trait: the API key can only be retrieved once and must be saved immediately. It also transparently states the auto-activation, quotas, and the free launch tier, giving the agent all necessary operational expectations.

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 delivering essential information: what it does, critical warning about the API key, and post-registration usage. The description is front-loaded and every sentence adds value without padding.

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 registration tool with no output schema, the description covers the core context: the return value (API key), its irrecoverability, the activation tier with quotas, and how to integrate with other tools. It could mention error cases or follow-up verification (e.g., check get_activation_status), but for a typical first-step creator, this is sufficiently 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 description coverage is 100%, so the schema already documents all seven parameters. The description adds no additional parameter-specific semantics beyond what's in the schema. It does mention the API key usage, but that's an output concern, not a parameter detail. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: "Register a new agent on Human Pages." It distinguishes from siblings like register_as_arbitrator by focusing on the general agent registration flow, and it frames itself as "Typical first step before hiring," which differentiates it from other setup 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?

It provides clear context for when to use the tool: as a first step before hiring, and it explains how to use the returned API key in subsequent authenticated tools. While it doesn't explicitly name alternatives to avoid, it implicitly signals that separate activation (e.g., claim_free_pro_upgrade) may be unnecessary due to auto-activation on PRO tier.

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

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

With no annotations, the description carries the full burden. It discloses key constraints such as the whitelist requirement and the webhook's /health endpoint requirement, along with the fee maximum. However, it does not mention side effects (e.g., overwriting an existing registration) or what the response/outcome will be, leaving room for improvement.

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 with a distinct purpose: action, role context, prerequisite, and required inputs. No redundancy, front-loaded with the core action. Could be slightly more compact but is efficient.

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 registration tool with no output schema, the description adequately covers what it does, who can use it (whitelisted agents), and what information must be provided. It could explicitly state the post-registration outcome, but the essentials are present.

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

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

The schema covers 100% of parameters, giving a baseline of 3. The description restates some parameters (webhook, fee, specialties, signed message) but adds no new meaning beyond the schema, such as parameter interactions or additional formatting rules.

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

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

The description opens with the specific verb-resource pair 'Register your agent as an escrow arbitrator', clearly stating what the tool does. It also distinguishes this from related tools by implying the arbitrator role, while sibling tools like list_arbitrators and submit_verdict serve different functions.

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 provides the clear prerequisite of being whitelisted by the platform owner, which is essential timing/context for when this tool can be used. It does not explicitly name alternatives, but given the unique nature of registration, the use case is unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the code is for social media and not required for API access, but it doesn't describe the response format, delivery method, whether the code expires, or any 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 two short sentences, front-loaded with 'Optional.' Each sentence provides necessary context without any wasted words.

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

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

The tool is simple with one fully documented parameter, but there is no output schema. The description should clarify what the response contains (e.g., whether the code is returned directly or sent via email), which it doesn't. This leaves a gap in understanding the tool's behavior after invocation.

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

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

Schema coverage is 100% for agent_key, and the schema already describes it as starting with hp_. The description adds no additional parameter details beyond what the schema provides.

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

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

The description clearly states the tool's function: 'Request an activation code (HP-XXXXXXXX) to post on social media for a verified trust badge.' It also distinguishes from siblings by explicitly noting it is not required for API access and that agents are auto-activated.

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 says 'Optional' and clarifies the code is for a social media trust badge, not for API access. This gives clear context for when to use it, though it doesn't explicitly name alternative tools like get_activation_status or verify_social_activation.

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 full burden of behavioral disclosure. It reveals the state change (SUBMITTED -> ACCEPTED), the requirement to include a reason, and the notification to the human. This covers the key behavioral traits, though it does not mention potential errors or response format.

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 four sentences, each earning its place: what it does, the state change, the reason requirement, the notification, and the alternative. There is no fluff or repetition, and it is front-loaded with the 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?

For a simple state-transition tool with three params and no output schema, the description covers the essential context: precondition, effect, side effect, and alternative. It does not mention the return value, but that is a minor gap for this kind of 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?

The schema has 100% coverage with descriptions for all three parameters. The description reinforces the 'reason' parameter by saying 'Include a clear reason explaining what needs fixing,' but this adds little beyond the schema. The baseline of 3 is appropriate since 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 states the tool's specific purpose: 'Request changes on submitted work' and explains the state transition ('Moves job back to ACCEPTED so the human can resubmit'). It distinguishes itself from the sibling tool approve_completion by explicitly mentioning it as an alternative for satisfactory work.

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

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

The description provides explicit when-to-use guidance: the job must be in SUBMITTED state. It also names an alternative tool ('Use approve_completion instead if the work is satisfactory'), giving clear direction on choosing between the two related operations.

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 disclosure burden. It does reveal key behaviors: Superfluid requires a new flow and backend verification, while micro-transfer creates a new pending tick. However, it omits failure modes, side effects, or what happens upon verification, leaving gaps for an agent to understand operational risks.

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 and well-structured: one sentence states the primary purpose, and the second sentence adds essential protocol-specific details. No extraneous information is included.

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 description covers the core action and two modes, but leaves ambiguity about how an agent determines which protocol applies and what happens after backend verification or pending tick creation. Without annotations or an output schema, additional context about expected outcomes or prerequisites would improve 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?

All three parameters are fully described in the schema (100% coverage), including the Superfluid-only sender_address. The description adds no additional parameter-level semantics, so the baseline score of 3 applies.

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

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

The description clearly states the tool's core function ('Resume a paused stream') and distinguishes between two protocol variants (Superfluid and micro-transfer) that have different behaviors. This differentiates it from siblings like start_stream, stop_stream, and pause_stream.

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 provides explicit context for when to use the tool: for paused streams. It also gives protocol-specific guidance, such as 'create a new flow first, then call this' for Superfluid. It does not explicitly mention when not to use it, but the two conditional branches offer clear usage direction.

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 reveals multiple behavioral details: default radius 30km, response includes totalCount and resolvedLocation, contact info requires get_human_profile (registered agent needed), and geocoding behavior for location. It also mentions currency conversion for max_rate, making the tool's behavior more predictable.

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 paragraph but logically structured: purpose, returns, key filters, defaults, response extras, contact info, workflow. Every sentence adds actionable value without fluff, making it highly scannable.

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

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

For a search tool with 25 parameters and no output schema, the description covers the essential behavioral contract: what fields are returned, how filters combine, defaults, the workflow with related tools, and the requirement for get_human_profile to access contact info. It also explains the resolvedLocation verification, making it practically complete for invocation decisions.

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

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

The input schema already has 100% field coverage with descriptions, so the baseline is 3. The description adds strategic guidance above the schema, such as using min_completed_jobs=1 to find proven workers without a skill filter, fully-qualified location names for accurate geocoding, and default sort behavior. This elevates it to 4.

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 it searches for humans available for hire and lists the exact fields returned (id, name, skills, location, reputation, etc.). It also differentiates itself by providing the typical workflow link to get_human_profile and create_job_offer, making it distinct from the many get_* sibling 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?

It provides explicit usage tips like 'All filters are optional — combine any or use none to browse' and highlights key filters (skill, location, min_completed_jobs) with examples. The typical workflow 'search_humans → get_human_profile → create_job_offer' indicates when this tool is the appropriate entry point, though it doesn't enumerate exclusions vs. 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. It discloses that the human receives email and Telegram notifications, which is a meaningful side effect. It also mentions the rate limit and applicable job states. However, it doesn't describe error handling or whether the message is logged/visible elsewhere, leaving some gaps.

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 four sentences, front-loaded with the primary action. Every sentence adds value: purpose, applicable states, notification behavior, alternative tool, rate limit, and max length. No redundant or filler content.

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

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

For a simple 3-parameter tool with no output schema and no annotations, the description covers the essential context: what it does, when to use it, side effects, constraints, and a pointer to the related read tool. Missing details like return value or error behavior are minor for this tool type.

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 all parameters already have descriptions. The description adds no new parameter-specific meaning beyond restating the 2000-character limit for content. It does tie job_id to active job states, but that's more about usage context than parameter semantics. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Send a message to the human on an active job.' It specifies the verb (send), resource (message), and recipient (human on a job), and lists the applicable job states (PENDING, ACCEPTED, PAID, STREAMING, PAUSED). This distinguishes it from sibling get_job_messages, which is for reading replies.

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

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

The description explicitly tells when to use this tool (on active jobs in listed states) and provides an alternative: 'Use get_job_messages to read replies.' It also includes practical constraints like rate limit (10/minute) and max message length (2000 chars), which guide usage.

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?

Without annotations, the description carries the full burden. It discloses the critical behavioral impact (controls payment attribution), emphasizes user consent, and explains the distinction between verified and unverified wallets. This is substantive context beyond a simple 'set' operation, though it does not detail return values or error conditions.

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 moderately long but well-structured: purpose, critical warning, alternative, and optional verification flow. Each sentence adds value, though the all-caps 'IMPORTANT' and repeated emphasis could be tightened without loss of meaning.

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 lack of annotations and output schema, the description covers essential behaviors: user consent, verification mechanics, and payment attribution. It does not specify what the tool returns or error cases, but the focused scope makes this adequate for the tool's complexity.

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

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

The schema already describes all parameters, so the baseline is 3. The description adds meaning to the optional 'signature' and 'nonce' parameters by explaining they verify ownership via EIP-191 and enable payment attribution, which goes beyond the schema's syntax-only descriptions.

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 ('Set the wallet address') and the resource ('for a registered agent'), making the purpose unambiguous. It also distinguishes from sibling tools like get_wallet_nonce by focusing on the write 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?

The description explicitly instructs when to use the tool (only after user confirmation, never autonomously) and provides an alternative (create a wallet via CDP AgentKit when a wallet is needed). This gives clear when-to-use and when-not-to-use 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 full burden. It discloses that the tool 'commits ongoing funds,' 'verifies the flow on-chain,' and for micro-transfer 'locks network/token and creates the first pending tick.' This gives clear behavioral context beyond just the action.

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 lengthy but well-structured with numbered steps and a warning. Every sentence serves a purpose: purpose, warning, prerequisites, steps, and a gas-cost tip. It's dense but not redundant.

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

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

Given the tool's complexity (two modes, prerequisites, on-chain flow) and lack of output schema/annotations, the description covers the key operational aspects. It could mention error scenarios or response format, but it provides enough for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for sender_address (flow creator vs payer) and network preference, but most parameter meaning is already in the schema. It doesn't significantly enhance understanding beyond structured descriptions.

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 'Start a stream payment for an ACCEPTED stream job,' identifying the specific action and scope. It also distinguishes between Superfluid and micro-transfer modes, making it distinct from sibling tools like pause_stream or stop_stream.

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 provides explicit prerequisites: 'you must FIRST create the on-chain flow' for Superfluid, and warns 'Confirm with the user before starting a stream.' It also offers practical advice like preferring L2s, but doesn't explicitly name alternative tools for 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 provided, the description carries the full transparency burden. It discloses the permanent, irreversible nature of the action and the required job states, but does not elaborate on side effects, such as whether the action can be undone or any cleanup behavior.

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

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

The description is two short sentences with no redundancy. The main action is front-loaded, and each sentence adds distinct information: the action and the usage conditions. Every word 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 tool with full schema coverage, the description covers the core action, state preconditions, and permitted callers. It does not describe behavior for invalid states or post-conditions beyond marking as completed, but it is adequately complete for its simplicity.

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 description does not need to add parameter details. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description clearly states a specific action (stop a stream) and its permanent effect (mark job as completed), distinguishing it from sibling tools like pause_stream or resume_stream by emphasizing 'permanently' and the completion aspect.

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 the applicable job states (STREAMING or PAUSED) and permitted callers (agent or human), giving clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the permanent nature implies a distinction from pause_stream.

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 that the arbitrator fee is automatically calculated from the locked rate and that a signed Verdict struct is required. However, it does not describe side effects (e.g., funds released, dispute closed) or prerequisites, and with no annotations provided, the description carries the full burden. Partial transparency only.

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 main action, followed by context and signing details. Every sentence contributes meaning with no fluff.

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

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

For a 7-parameter mutation tool with no output schema and no annotations, the description covers purpose, role, fee calculation, and signing structure. It lacks explicit prerequisites (e.g., being an active arbitrator) and outcome details, but is largely complete for the core operation.

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%, providing baseline 3. The description adds value by showing the canonical EIP-712 Verdict struct (jobId, toPayee, toDepositor, arbitratorFee, nonce) and explains the fee behavior relative to locked rate, which clarifies the relationship between parameters beyond the schema.

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

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

Clearly states 'Submit a signed EIP-712 verdict to resolve an escrow dispute' with a specific verb and resource. The description distinguishes this from sibling tools like approve_completion or request_revision by focusing on the final verdict submission.

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 implies usage context: resolving an escrow dispute as an arbitrator, mentioning 'Your arbitrator fee'. It does not explicitly list alternatives or when-not-to-use, but the context is clear from sibling tools like request_revision and get_dispute_details.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose a key prerequisite (websiteUrl must be set) and gives exact instructions for the well-known and dns methods (file path and TXT record). However, it does not mention whether the operation is read-only, what the result/return value looks like, or any side effects. The lack of outcome details is a 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?

The description is two sentences, front-loaded with the main purpose, and every word contributes value. It includes the prerequisite, the two methods, and specific technical details without superfluous content.

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

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

For a tool with no annotations and no output schema, the description covers the core requirements: it explains what the tool does, the prerequisite, and how to execute both verification methods. However, it does not describe the expected return value or what constitutes a successful verification, which would be helpful for an agent to know how to interpret the result. Given the tool's moderate complexity, the description is nearly complete but leaves out the outcome.

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 exceeds this by adding meaningful detail to the 'method' parameter: it explains the exact file path for 'well-known' and the TXT record host for 'dns', which is not fully specified in the schema. It also adds the prerequisite context about websiteUrl, which relates to the agent_id parameter. This extra explanation compensates for any ambiguity in the enum.

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

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

The description clearly states the tool's purpose: 'Verify domain ownership for a registered agent.' The verb 'verify' is specific, and it identifies the resource (domain ownership) and scope (registered agent). It distinguishes itself from sibling verify tools like verify_payment_activation and verify_social_activation by focusing on domain ownership.

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

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

The description provides clear context: it must be used when an agent needs domain ownership verified, and it includes a prerequisite ('The agent must have a websiteUrl set'). It also explains the two supported methods, giving the user a sense of when each might be appropriate. However, it does not explicitly exclude alternatives or mention when not to use this tool.

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?

There are no annotations, so the description carries full responsibility. It does disclose a key side effect ('On success, your agent is activated with PRO tier'), but it does not mention failure behavior, idempotency, permission requirements, or whether the verification step is read-only or modifies state beyond activation. This leaves significant unknowns for an agent, especially for a tool that activates a paid tier.

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

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

The description is two sentences, front-loaded with the primary action, and the second sentence adds the crucial outcome. Every word earns its place; there is no filler, redundancy, or overly technical jargon. It is a model of concise structure.

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 has 3 required parameters, no output schema, and no annotations. The description conveys the core purpose and success outcome but lacks guidance on when to use it, what happens on failure, or any prerequisites. For a relatively simple verify/activate tool, this is minimally adequate but leaves gaps, hence not a higher score.

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

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

The input schema already provides descriptions for all three parameters (agent_key, tx_hash, network) with 100% coverage. The description adds no parameter-specific meaning or examples beyond what the schema offers. Baseline for high schema coverage is 3, and there is no additional compensation needed.

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

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

The description uses a specific verb 'verify' and clearly identifies the resource: 'on-chain payment for PRO tier activation.' It also states the successful outcome ('your agent is activated with PRO tier'), which distinguishes it from likely read-only siblings like get_payment_activation or claim_free_pro_upgrade. The purpose is unambiguous and action-oriented.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prereqs, or mention sibling tools like get_payment_activation or claim_free_pro_upgrade. The context implies using it after an on-chain payment, but this is not directly stated, so the agent receives no actionable guidance on selection.

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 disclosure burden. It adds useful context that the tool is optional and auto-activation occurs, but it does not state whether the operation is read-only, what happens on success, or any potential side effects. The verb 'Verify' implies a read operation, but this is not explicit.

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

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

The description is two sentences, front-loaded with the 'Optional' context, and every clause adds value. There is no fluff or repetition, making it highly efficient.

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 2 documented parameters, and the description clarifies its purpose and optionality. However, there is no output schema, and the description does not explain what a successful verification returns or what the 'verified trust badge' entails, leaving a modest gap for agents to understand the post-call outcome.

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?

Both parameters have schema descriptions covering 100% of the inputs, so the description need not add parameter details. It mentions 'activation code' and 'social media post,' which aligns with the schema but does not add new format or syntax beyond what the schema already provides.

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

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

The description uses the specific verb 'Verify' with the resource 'social media post containing your activation code' and states the purpose 'for a verified trust badge.' It clearly distinguishes from sibling verification tools by focusing on social media posts rather than domain or payment verification.

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

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

The description explicitly labels the tool as 'Optional' and states 'Not required for API access — agents are auto-activated on registration,' providing a clear when-not scenario. However, it does not explicitly mention alternative tools for other verification types (e.g., verify_agent_domain), so it stops short of full alternative guidance.

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