Human Pages

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

No annotations provided, so description carries full burden. Discloses finality ('this finalizes the job'), state transition ('Moves the job to COMPLETED'), and irreversibility implications. Lacks details on error states or non-SUBMITTED job handling, but covers primary behavioral traits well.

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?

Optimal structure: warning front-loaded ('IMPORTANT: Confirm...'), followed by prerequisites, action, post-action step, and alternative. Every sentence serves distinct purpose with zero 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?

Complete despite no output schema or annotations. Describes full workflow lifecycle (prerequisite checks → approval → post-approval review), state machine behavior (SUBMITTED→COMPLETED), and integration points with 2 sibling tools.

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 has 100% description coverage with 2 required parameters fully documented. Description implies job_id context through workflow but adds no direct parameter semantics beyond schema. Baseline 3 appropriate per 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?

Excellent clarity: specific verb 'Approve' with resource 'submitted work' and scope 'SUBMITTED job'. Distinguishes from siblings by contrasting with 'request_revision' and sequencing with 'leave_review'.

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?

Comprehensive workflow guidance: explicit prerequisite ('Call this after reviewing...check via get_job_messages'), mandatory confirmation requirement ('Confirm with the user before approving'), and clear alternative path ('If the work needs changes, use request_revision instead').

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, description carries full behavioral burden. It successfully discloses destructive side effects (rejection of pending applications) and authorization requirements. Could be improved by stating whether cancellation is reversible or affects active jobs.

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

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

Three sentences with zero waste: action first, side effect second, authorization third. Appropriate length for a 2-parameter destructive operation.

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 cancellation tool with simple schema and no output schema, description adequately covers action, side effects, and constraints. Could mention impact on active jobs/offers but sufficient for basic 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 has 100% coverage with descriptions for both parameters. The text adds crucial semantic context for agent_key by specifying authorization requirements ('creator only'), elevating it above baseline despite complete schema documentation.

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 states specific verb ('Cancel') + resource ('listing') + state ('open'), clearly distinguishing from siblings like create_listing (creation), get_listing (read), and make_listing_offer (negotiation).

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 authorization constraint ('Only the agent who created the listing can cancel it') and warns of side effects ('All pending applications will be rejected'). Stops short of explicitly contrasting with alternative actions like completing or expiring listings.

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

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

No annotations provided, so description carries full burden. Adds critical 'This is read-only' disclosure and details return structure (verified status, score, tier, when verified), covering behavior beyond parameter schema.

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

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

Three sentences with zero waste: purpose sentence first, return values second, safety (read-only) third. No redundancy, appropriately 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?

Complete for a simple single-parameter lookup tool. Compensates for missing output schema by describing return fields in description. No output schema present, but coverage of return structure 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 coverage is 100% (human_id fully documented). Description references 'specific human' implicitly but adds no syntax/format details beyond schema. Baseline 3 appropriate when schema carries the load.

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

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

Specific verb ('Check') + specific resource ('humanity verification status') + scope ('for a specific human'). Clearly distinguishes from sibling tools like get_human or get_human_profile by focusing exclusively on verification data (score, tier, verified 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?

Provides implied usage guidance by enumerating the specific verification fields returned (score, tier, date), signaling when to use this over general profile lookups. However, lacks explicit 'when to use vs alternatives' guidance or prerequisites.

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 'no-op' behavior and deprecated status, which is valuable. However, it lacks detail on what happens if called by non-PRO agents (does it upgrade them or error?) and doesn't describe any response format or auth requirements beyond the key.

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

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

Two efficient sentences with zero waste. Front-loads critical information (Deprecated) immediately, then explains rationale and current behavior. Every clause serves a specific 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 this is a single-parameter deprecated endpoint with no output schema, the description adequately covers essential context (why deprecated, what happens now). Minor gap regarding response behavior for non-PRO agents or error states, but sufficient for agent decision-making.

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% (1 parameter), so baseline is 3. The description adds valuable semantic information not in the schema: the 'hp_' prefix hint for the agent_key, which helps with validation and debugging.

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 is deprecated and explains current behavior (no-op for PRO agents). While the original purpose is implicit in the name, it effectively communicates the current non-functional status and distinguishes it from the current registration flow mentioned.

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 implicit guidance by stating 'Agents are now auto-activated on PRO tier at registration,' steering users toward the registration flow (register_agent). It also defines the condition when this is a no-op (agents already on PRO), though it doesn't explicitly name the alternative 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?

With no annotations provided, description carries full burden and excellently discloses: rate limits (15/day), notification mechanisms (email/Telegram), human response options (accept/reject), auth requirements, and post-creation state management via polling or webhooks.

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?

Lengthy but justified by 20-parameter complexity and zero annotations. Well-structured with clear priority: purpose → safety warning → prerequisites → mechanics → workflow. Every sentence delivers unique information without redundancy.

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

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

For a complex 20-parameter workflow tool with no annotations or output schema, description comprehensively covers: safety constraints, auth dependencies, rate limiting, notification behavior, payment mode intricacies (STREAM, ESCROW, ONE_TIME), and full lifecycle integration with 6 sibling tools.

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 has 100% coverage (baseline 3), but description adds crucial workflow context: agent_key must come from register_agent, callback_url triggers webhooks with specific states, price_usd constraints (minOfferPrice), and payment_mode implications (flexible crypto/fiat).

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

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

Description clearly states the specific action ('Send a job offer'), target resource ('specific human'), and distinguishes from sibling tools like create_listing (public) vs direct offers implied here.

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 when-not guidance ('never create offers autonomously'), mandatory prerequisites ('Requires agent_key from register_agent'), clear workflow sequencing ('Full workflow: search_humans...'), and explicit next-step alternatives (poll get_job_status vs callback_url).

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, description carries full disclosure burden. It successfully declares auth requirement ('Requires agent_key'), rate limiting ('PRO = 5/day'), and operational workflow (humans browse/apply → review → hire). It establishes the discovery mechanism without contradicting any structured data.

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?

Five sentences efficiently structured: purpose → usage context → human interaction model → workflow/auth/limits → fallback trigger. Every sentence adds unique value beyond the structured fields. No 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 complex 21-parameter tool with no annotations and no output schema, the description provides sufficient ecosystem context (public job board mechanics), workflow integration points (three sibling tools referenced), and operational constraints (rate limits, auth) to enable 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%, establishing a baseline of 3. Description mentions 'Requires agent_key' which aligns with schema but adds no semantic detail beyond the schema's existing descriptions for the 21 parameters (e.g., no clarification on how location_lat/lng interact with radius_km, or callback_secret mechanics).

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 specific action ('Post a job') and resource ('public job board'). Explicitly distinguishes from sibling tool create_job_offer ('vs create_job_offer which targets one person'), clarifying the broadcast-vs-targeted distinction.

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 when-to-use ('when you don't have a specific human in mind'), names the alternative tool for comparison, and provides trigger condition ('Also suggested when search_humans returns no results'). Also outlines the complete workflow chain (post → get_listing_applications → make_listing_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 burden of disclosure. It effectively lists return values (tier, rate limits, expiry) and conditional behavior (x402 pricing 'if enabled'), but does not explicitly state read-only safety or side effects despite using the verb 'Check'.

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

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

Two well-structured sentences that front-load the information. The first sentence details capabilities and return data; the second provides usage intent. No redundant text, though could be slightly more compact.

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

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

For a single-parameter tool without output schema, the description compensates well by enumerating expected return fields (tier, status, rate limits, expiry, pricing). Complete for the tool's complexity, though explicit read-only declaration would improve it further.

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 has 100% coverage with the agent_key parameter fully described in the schema. The tool description itself does not add parameter-specific context, warranting the baseline score of 3 for high-coverage schemas.

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?

Clear specific verb (Check) and comprehensive list of returned data (tier, activation status, rate limits, expiry, x402 pricing). Distinguishes implicitly from siblings by detailing unique data points, though lacks explicit differentiation from similar tools like get_payment_activation.

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 implicit usage guidance ('Use this to understand your remaining quota'), indicating when to invoke the tool. However, lacks explicit alternatives or exclusions to distinguish from sibling tools like get_payment_activation or get_promo_status.

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, description carries disclosure burden by enumerating returned reputation fields (total jobs, completed jobs, payment speed). However, lacks safety info (read-only nature), error conditions, or caching 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?

Single efficient sentence front-loaded with action and resource. Parenthetical specifics about reputation stats add value without verbosity—every clause earns its place.

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

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

For a simple lookup tool with one parameter and no output schema, describing the returned data structure (reputation stats) provides adequate completeness. Missing auth/rate-limit details prevents a 5.

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 has 100% coverage for the single agent_id parameter. Description mentions neither the parameter name nor format details, relying entirely on schema documentation—appropriate baseline for high-coverage schemas.

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

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

Specific verb 'Get' paired with clear resource 'registered agent's public profile'. Explicitly targets 'agent' distinguishing it from sibling tools like get_human_profile and get_human.

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

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

No guidance provided on when to use this versus get_human_profile or other profile-fetching siblings. No mention of prerequisites like agent registration status or visibility rules.

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 compensates for the missing output schema by listing specific return contents ('job info, messages, evidence, amounts, and deadline'), which is valuable behavioral disclosure. However, it lacks other critical behavioral traits such as idempotency, caching behavior, rate limits, or error conditions specific to dispute access.

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

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

Three sentences, each earning its place: the first establishes the core action, the second compensates for the missing output schema by detailing return values, and the third provides essential workflow context. No redundancy or filler; front-loaded with the verb 'Get'.

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 moderate complexity (escrow dispute resolution) and lack of output schema, the description adequately compensates by enumerating the returned data fields. The 100% schema coverage means parameter documentation is complete. It could be improved by mentioning error scenarios (e.g., access denied for non-assigned arbitrators) or pagination for large dispute histories.

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% description coverage ('job_id' and 'agent_key' are fully documented). The description reinforces the semantic context by mentioning 'escrow dispute' (aligning with job_id) and 'arbitrators' (aligning with agent_key constraints), but does not add syntactic details, validation rules, or format specifications 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 a specific verb ('Get') and resource ('full case details for an escrow dispute'), clearly distinguishing it from generic job query tools like 'get_job_status' or 'get_job_messages'. It specifically identifies the domain (escrow disputes vs. regular jobs) and mentions arbitrators, clearly positioning it within the dispute resolution workflow relative to 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?

The description provides clear context ('Used by arbitrators to review a case before submitting a verdict'), implicitly referencing the 'submit_verdict' sibling tool and establishing the workflow sequence. However, it lacks explicit negative guidance (e.g., 'do not use if you are not the assigned arbitrator') or explicit mention of alternatives for non-arbitrator users.

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 and succeeds in disclosing behavioral traits: it explains the split of responsibilities between AI and developer, mentions that results are country-specific (affecting rates/payment methods), and implies this is a read operation (retrieving balance/instructions). Minor gap: doesn't mention error cases if wallet uninitialized.

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 that are front-loaded with purpose and each earn their place: prerequisites, post-call actions, parameter usage, and responsibility split. Slightly conversational ('YOUR job', 'DEVELOPER's job') but efficient with minimal 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?

Despite no output schema, the description comprehensively covers return values (funding instructions, current balance, country-specific onramp recommendations). Given the 100% input schema coverage and clear behavioral disclosure, the description provides sufficient context for 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?

With 100% schema coverage, baseline is 3. The description adds value by explaining the semantic purpose of the optional 'country' parameter ('returns country-specific onramp recommendations with the best rates and local payment methods'), justifying why to include it beyond the schema's ISO code format.

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 specific action (Get) and resources (funding instructions, wallet balance, onramp recommendations). It distinguishes this informational tool from wallet creation (CDP AgentKit) and other wallet operations like set_wallet by focusing on retrieval of funding 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?

Excellent workflow guidance: explicitly states the prerequisite condition ('If you don't have a wallet yet, create one first'), names the specific alternative method (CDP AgentKit), clarifies autonomous vs. collaborative actions ('you can do this autonomously'), and defines roles ('wallet creation is YOUR job; the funding is the DEVELOPER's job').

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

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

No annotations provided, so description carries disclosure burden. Lists comprehensive return fields and explicitly defines privacy boundary (public vs private contact data). Implies read-only nature through 'Get' verb and 'public profile' framing. Minor gap: no mention of error handling when ID invalid or rate limits.

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

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

Three sentences efficiently structured: (1) core function with field enumeration, (2) exclusions with alternative reference, (3) parameter sourcing. No redundant text; every clause earns its place.

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

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

No output schema exists, but description compensates by enumerating all returned data categories (bio, skills, reputation metrics, verification status). Prerequisites covered via sibling tool references. Fully adequate for single-parameter lookup 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 has 100% coverage for the single 'id' parameter. Description adds critical usage context beyond schema: 'The id can be found in search_humans results', guiding parameter acquisition.

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?

Excellent specificity: states exact action ('Get'), resource ('human's public profile'), and identifier ('by ID'). Clearly distinguishes from sibling 'get_human_profile' by explicitly listing included fields vs excluded sensitive data.

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 on when NOT to use (lacks contact info/wallets), names alternative 'get_human_profile', notes its stricter auth requirement ('requires agent_key'), and specifies ID source ('found in search_humans results').

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

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

No annotations provided, but description fully compensates by disclosing rate limits ('PRO = 50/day'), authentication requirements ('agent_key from register_agent'), cost alternatives ('$0.05 via x402'), and return payload structure (enumerated contact/payment 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?

Information-dense single sentence front-loaded with the core action. Efficiently packs purpose, prerequisites, rate limits, pricing, and workflow relationships. Slightly dense but zero waste—every clause earns its place by providing actionable context not found in structured fields.

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?

Exceptionally complete given no output schema exists. Description compensates by exhaustively listing profile contents (contact methods, payment rails), covers authentication, rate limiting, and monetization alternatives. Provides sufficient information for an agent to integrate into the job creation workflow.

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 has 100% coverage establishing baselines, but description adds crucial provenance context: 'human_id comes from search_humans' and 'agent_key from register_agent'. This semantic linkage helps the agent understand tool chaining without repeating schema definitions.

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?

Clear specific action 'Get a human's FULL profile' with comprehensive enumeration of returned data types (contact info, crypto wallets, fiat methods, social links). Explicitly distinguishes from sibling 'get_human' by emphasizing 'FULL' and detailed payment-relevant fields.

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?

Excellent workflow guidance: states prerequisite 'Requires agent_key from register_agent', data source 'human_id comes from search_humans', and explicit trigger 'Use this before create_job_offer to see how to pay the human'. Also mentions alternative pricing path.

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 full burden for behavioral disclosure. It adds valuable context about chronological ordering and return contents (sender info, timestamps, both agent/human messages), but omits pagination, rate limits, or side effects like read receipts.

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

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

Three sentences with zero waste: Sentence 1 states core action, Sentence 2 details return values, Sentence 3 provides usage guidance. Well front-loaded with critical information first.

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 operation with 100% schema coverage and no output schema, the description is complete. It covers functionality, return structure, ordering, and use cases without needing to explain output schema fields.

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% (agent_key includes format hint 'starts with hp_'). The description implies the relationship between job_id and 'messages for a job' but does not add validation rules or syntax details beyond the schema, meriting the baseline score.

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 the specific verb 'Get' and resource 'messages for a job', adds scope detail 'chronological', and distinguishes from siblings like send_job_message (retrieve vs. send) and get_job_status (messages vs. 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?

Provides explicit use cases ('Use this to check for replies, review submitted deliverables, or follow up on work progress') that clarify when to use the tool. Lacks explicit 'when not to use' or named alternatives to achieve a 5.

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

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

Comprehensive disclosure of the state machine lifecycle (PENDING→ACCEPTED→PAID→SUBMITTED→COMPLETED), alternative terminal states (REJECTED/CANCELLED/DISPUTED), and streaming-specific states (STREAMING/PAUSED). Also documents return payload structure (price, human name, next-step recommendation). Lacks only negative case handling (invalid job_id errors).

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?

Information-dense with logical front-loading (purpose first, then return values, then status definitions). The length is justified by the complexity of the state machine and lack of output schema. Minor deduction for the parenthetical list of streaming/fiat statuses which could be more integrated.

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?

Fully compensates for missing annotations and output schema by exhaustively documenting the state transitions, what each status means functionally, and the expected return payload. Adequate for a state-query tool with complex workflow logic.

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 has 100% description coverage for the single 'job_id' parameter. The main description text adds no explicit parameter syntax or format details beyond what the schema already provides, warranting the baseline score of 3.

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

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

Clear specific verb ('Check') + resource ('current status of a job'). Unambiguously distinguishes from sibling action tools like 'approve_completion' and 'leave_review' by contrasting read-only inspection with those mutation operations.

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 directs to sibling tools at specific states: 'use approve_completion or request_revision' when SUBMITTED, and 'use leave_review' when COMPLETED. Provides clear workflow guidance on when to use 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?

No annotations provided, so description carries full burden. It adds valuable behavioral context by disclosing what data is returned (agent reputation, application count), which is critical since no output schema exists. However, lacks details on error handling (e.g., invalid ID), authentication requirements, or side effects.

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

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

Single sentence efficiently combines purpose, resource, and return value hints. Front-loaded with action and noun. Zero redundancy. Slightly dense but appropriate for the tool's simplicity.

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

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

For a single-parameter read tool without output schema, the description adequately hints at key return fields (reputation metrics, counts). Missing full return schema or error specifications, but reasonable given low complexity and clear sibling differentiation.

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% (the single parameter 'listing_id' is described in schema as 'The listing ID'). Description adds no additional parameter semantics, but with complete schema coverage, the baseline score of 3 is appropriate—no additional documentation 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?

Clear specific verb ('Get') + resource ('listing') + scope ('detailed information'). The word 'specific' distinguishes from sibling 'get_listings' (plural), while mentioning 'application count' distinguishes from 'get_listing_applications' (which presumably returns full application objects, not a count).

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 implied usage through 'specific listing' (suggesting use when you have a listing_id) versus sibling 'get_listings'. However, lacks explicit when-to-use guidance such as 'use this when you have a listing_id; use get_listings to search'. No alternatives named explicitly.

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, description carries full disclosure burden. It details return structure (applicant profile fields + pitch message) and authorization requirements (listing creator only). Could improve by mentioning empty states or error conditions, but output transparency is strong.

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

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

Three sentences with zero waste: 1) Purpose and return payload, 2) Workflow integration, 3) Authorization boundary. 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?

No output schema exists, so description adequately compensates by enumerating returned fields (profile attributes, pitch message). Covers purpose, workflow role, permissions, and output structure sufficient for 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 has 100% description coverage, establishing baseline 3. Description adds implicit context that 'listing_id' refers to 'your listing' via the ownership constraint, but largely relies on schema documentation.

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?

Clear specific verb 'View' + resource 'applications for your listing'. Distinguishes from sibling 'make_listing_offer' by stating this precedes hiring, and from 'get_listings' via the ownership constraint 'Only the listing creator can view 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?

Explicit workflow guidance: 'Use this to evaluate candidates, then hire with make_listing_offer' names the specific next tool. Permission constraint 'Only the listing creator can view applications' defines when-not-to-use (if not the creator).

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 disclosure burden and succeeds well. It explicitly lists the returned data fields (title, budget, category, work mode, skills, application count, agent reputation, pagination metadata) and describes the pagination behavior (total count, total pages), compensating for the missing output schema.

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

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

Three well-structured sentences with zero waste: (1) purpose and return payload, (2) available filters, (3) pagination mechanics. Information is front-loaded with the primary action stated immediately. Every clause earns its place with no repetition of the tool name or tautology.

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

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

Given 10 optional parameters, 100% schema coverage, no annotations, and no output schema, the description is nearly complete. It details the response structure and pagination behavior adequately. Minor gap: no mention of authentication requirements or rate limiting, though the 'public board' scope implies open access.

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

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

Schema coverage is 100% with all 10 parameters fully documented in the schema itself. The description adds narrative grouping (organizing filters by type: skill/category/location/budget) and emphasizes the pagination defaults/limits, which is appropriate added value when the schema carries the param semantic load.

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 action 'Browse open job listings on the public board' — clear verb (browse), resource (job listings), and scope (public board). The plural 'listings' and term 'public board' effectively distinguishes it from sibling get_listing (singular retrieval) and create_listing (creation).

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 excellent operational guidance on filtering (skill, category, work_mode, budget range, location) and pagination mechanics (page/limit params, default 20, max 50). While it doesn't explicitly name sibling alternatives like get_listing, the clear context about browsing multiple items and filter combinations provides strong implicit 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?

With no annotations provided, the description carries full disclosure burden. It successfully indicates blockchain involvement ('on-chain payment') but omits critical financial safety details: payment amount, currency/token type, chain network, deposit address expiration, and whether the operation is idempotent or triggers 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?

Single sentence with zero redundancy. Front-loaded with the action verb 'Get', immediately clarifies the output (deposit address), purpose (PRO tier activation), and method (on-chain). Every clause earns its place with no filler words.

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

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

For a financial/activation tool with no output schema or annotations, the description covers the basic intent but leaves significant gaps. Missing: return value structure, payment amounts, currency details, timeout windows, and post-payment next steps that would be necessary for safe agent 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% with agent_key fully documented in the JSON schema. The description implies the parameter requirement by referencing 'Your registered agent' but adds no additional semantic context (e.g., why the key is needed, format validation beyond the schema) warranting a higher score given the complete schema coverage.

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

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

The description provides specific action ('Get'), clear resource ('deposit address and payment instructions'), scope ('PRO tier activation'), and mechanism ('on-chain payment'). It effectively distinguishes this from siblings like claim_free_pro_upgrade (free alternative) and verify_payment_activation (verification step).

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?

While the context implies this is for paid activation (contrasted with the free upgrade sibling), the description lacks explicit guidance on when to use this versus claim_free_pro_upgrade or the expected workflow sequence with verify_payment_activation. Usage must be inferred from the tool name and surrounding 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?

With no annotations provided, the description carries the full disclosure burden. It successfully reveals return values (slot counts) and authentication requirements (none). For a simple read operation, this covers the essential behavioral traits, though rate limits or caching behavior aren't mentioned.

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

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

Three sentences with zero waste: first establishes purpose and scope, second details return values, third states auth requirements. Perfectly front-loaded with the action verb and efficiently 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?

Despite lacking an output schema, the description explicitly documents the return structure ('how many slots are claimed and remaining'). Combined with the auth disclosure and promo context, this is fully complete for a parameter-less status check 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?

Input schema contains zero parameters. Per scoring guidelines, 0 parameters earns a baseline score of 4. The description appropriately requires no parameter explanation.

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?

Excellent clarity with specific verb 'Check' + resource 'launch promo status' and clear scope ('free PRO tier for the first 100 agents'). Effectively distinguishes from sibling 'claim_free_pro_upgrade' by positioning as a query operation versus an action.

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 implicit usage context by explaining it returns slot availability (claimed/remaining) and explicitly notes 'No authentication required,' which guides invocation prerequisites. Would be a 5 if it explicitly named the sibling alternative or stated 'use this before claiming'.

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 5-minute expiration and the multi-step workflow context, but could clarify whether this operation is idempotent or creates server-side state (the nonce record). Nonetheless, the expiry warning is critical behavioral context.

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

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

Three sentences with zero waste: sentence 1 states purpose, sentence 2 provides the workflow guideline, sentence 3 gives the expiry constraint. Front-loaded and dense with operational 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 this initiates a multi-step verification flow with no output schema, the description adequately explains what gets returned (nonce/challenge) and the critical expiry behavior. It references the sibling completion tool, providing sufficient context for an agent to use this correctly in sequence.

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% (agent_id, agent_key, wallet_address all documented), establishing the baseline score of 3. The description doesn't add parameter-specific semantics beyond the schema, but doesn't need to given the comprehensive schema coverage.

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

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

The description uses a specific verb ('Request') and resource ('signing challenge/nonce') with clear context ('wallet verification'). It explicitly distinguishes this as 'step 1' and contrasts with 'set_wallet' (the subsequent step), giving it clear sibling 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?

Excellent explicit guidance: states 'call this first', describes the complete workflow sequence ('sign the returned message... and pass the signature to set_wallet'), names the specific sibling tool (set_wallet), and notes the critical timeout constraint ('expires in 5 minutes').

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, description carries the burden and discloses visibility ('visible on the human's profile') and business impact ('affects their reputation score'). Missing idempotency guidance (can I edit/update?), error behavior for non-completed jobs, and reversibility details.

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

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

Three sentences with zero waste. Front-loaded with core action and constraints, followed by side effects. Every sentence 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?

Appropriate for a 4-parameter mutation tool without output schema. Covers primary business logic (reputation impact, visibility rules, completion requirement). Could strengthen with idempotency or update/delete behavior, but adequate for agent selection.

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%, establishing baseline 3. The description repeats '1-5 stars' and 'optional comment' already in schema, and implies job_id must reference a completed job, but does not add syntax/format details beyond structured data.

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

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

Specific verb (Rate) and resource (human) with clear scope (COMPLETED jobs). The parenthetical specification of '(1-5 stars + optional comment)' distinguishes this from generic feedback 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?

Explicit constraint 'Only works on COMPLETED jobs' provides clear precondition for use. However, it does not mention sibling alternatives like request_revision for incomplete work or clarify whether this is the final step after mark_job_paid/approve_completion.

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 disclosure burden. It successfully documents the return structure ('wallet address, fee... health status'), the fee format ('basis points, e.g. 500 = 5%'), and authentication requirements ('No authentication required'). It lacks explicit mention of read-only safety or rate limits, preventing a 5.

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

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

The description consists of three high-value statements: the action/returns, the usage context, and the auth status. There is no filler or redundancy; every phrase provides actionable information to the agent.

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 absence of an output schema and annotations, the description comprehensively compensates by detailing the returned fields (wallet, fee structure, track record) and operational context. For a parameterless listing tool, this covers all necessary invocation knowledge.

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 contains zero parameters. According to scoring guidelines, 0 parameters establishes a baseline score of 4. The description appropriately does not invent parameter documentation where none exist.

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 'Browse' and resource 'escrow arbitrators', clearly stating the tool's function. It explicitly differentiates from sibling tools like 'register_as_arbitrator' by specifying this is for selecting (not becoming) an arbitrator, and links to 'create_job_offer' with specific parameter context.

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 workflow guidance: 'Use this before create_job_offer with payment_mode=ESCROW to pick an arbitrator.' Also states 'No authentication required,' giving clear prerequisites. This directly tells the agent when to invoke 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?

No annotations provided, so description carries full burden. Discloses critical side effects: 'notifies the human', creates a binding financial commitment, and clarifies payment obligation triggers. Could be improved by stating what is returned (job_id?) and whether the offer is reversible/cancellable, but the financial risk disclosure is high-value behavioral context.

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 with zero waste: (1) Action, (2) Binding commitment warning, (3) Prerequisite, (4) Post-workflow. Front-loaded with the core verb. Every sentence earns its place by conveying distinct critical information (action, risk, prerequisite, next-steps).

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?

Appropriate for a complex multi-step transaction tool. Links the full lifecycle from application retrieval through payment and review. Missing only return value specification (since no output schema exists) and cancellation/reversibility policy, but the parameter coverage is complete and workflow is comprehensively mapped via sibling references.

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%, establishing a baseline of 3. Description adds value by specifying the data lineage for 'application_id' (must come from 'get_listing_applications') and implicitly connecting 'listing_id' to the 'listed budget' mentioned in the commitment warning. This semantic context exceeds the bare schema 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?

Clear specific verb 'Hire' paired with resource 'listing applicant'. Immediately distinguishes from sibling 'create_job_offer' by noting this originates from a listing, while explicitly stating the equivalence 'flow is the same as create_job_offer'. Also distinguishes from 'get_listing_applications' by stating this is the action following that data retrieval.

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?

Excellent explicit prerequisites: states to 'Get the application_id from get_listing_applications'. Provides clear workflow chain post-invocation 'get_job_status → mark_job_paid → approve_completion → leave_review'. Explicitly references sibling 'create_job_offer' for comparison. Includes critical 'when-not' guidance via binding commitment warning.

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

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

No annotations provided, so description carries full burden. It discloses state transitions (ACCEPTED → PAID vs PAYMENT_PENDING_CONFIRMATION), verification timing ('instantly' vs 'within 7 days'), on-chain vs human confirmation flows, and post-payment workflow. Rich behavioral context for a mutation tool.

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

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

logically structured across 6 sentences: purpose → safety warning → prerequisite → crypto behavior → fiat behavior → next step. No waste; the IMPORTANT warning and status requirements earn their place for a payment mutation tool.

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 state-transition tool without output schema, the description is comprehensive. It covers input validation (ACCEPTED status), payment method variations, state outcomes, timing constraints, and downstream workflow (approve_completion). No gaps given 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?

Schema coverage is 100% with complete property descriptions. Description adds valuable semantic grouping by distinguishing crypto methods (tx hash + network, instant verification) from fiat methods (receipt/reference, 7-day confirmation), which wires the enum values to their behavioral consequences.

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 'Record payment for an ACCEPTED job' - specific verb (Record) + resource (payment) + scope constraint (ACCEPTED status). It clearly distinguishes this from siblings by referencing get_job_status (prerequisite check) and approve_completion (next workflow step).

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 when-not guidance ('never mark payments autonomously'), mandates user confirmation ('Always confirm payment details with the user'), specifies prerequisites ('Job must be in ACCEPTED status'), and names specific sibling tools to use before/after (get_job_status, approve_completion).

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?

Excellent behavioral disclosure given no annotations: reveals backend verification logic ('backend verifies the flow was deleted') and side effects ('skips the current pending tick'). Explains the dual-mode operation clearly, though omits rate limits or auth requirements beyond the agent_key parameter.

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

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

Two efficient sentences with zero waste. First sentence states the action; second sentence uses parallel structure to explain the two distinct behavioral modes (Superfluid/micro-transfer). Information density is high with no 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?

Adequately covers the complexity of dual-mode operation without output schema or annotations. Explains preconditions (DELETE requirement) and side effects for both stream types. Could improve by describing the paused state or relationship to resume_stream, but sufficiently complete for safe 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?

Input schema has 100% description coverage (job_id, agent_key), establishing baseline 3. Description implies job_id refers to an active stream job but does not add semantic details about parameter formats, validation rules, or relationships between parameters beyond what the schema provides.

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

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

Clear specific verb ('Pause') and resource ('stream') with detailed mechanics distinguishing two implementation types (Superfluid vs micro-transfer). Distinguishes from siblings implicitly via technical details (requires DELETE first for Superfluid, implies temporary state), though could explicitly contrast with 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?

Provides explicit prerequisite workflow for Superfluid ('you must DELETE the flow first, then call this endpoint') and clarifies the effect for micro-transfer ('skips the current pending tick'). Strong procedural guidance, though lacks explicit comparison to when to use stop_stream vs 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?

Without annotations, the description carries the full burden. It explains the critical micro-transfer vs. Superfluid behavioral split, but lacks disclosure on side effects (e.g., whether this marks a job installment as paid, idempotency, or failure modes for invalid hashes).

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 tightly constructed sentences front-load the action, specify the submission requirement, and restrict scope. Zero redundant words; every sentence 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?

Given the 3-parameter schema with full coverage and no output schema, the description adequately covers the domain-specific context (pending ticks, stream types). Could benefit from mentioning side effects on job status for a perfect 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?

With 100% schema coverage, baseline is 3. The description adds valuable flow context by specifying the tx_hash is for the 'current pending tick' and linking job_id to micro-transfer streams, enhancing the raw schema definitions.

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 specific verbs ('Record', 'Submit') with clear resources ('micro-transfer stream payment', 'transaction hash') and explicitly scopes the tool to 'current pending tick' and 'MICRO_TRANSFER' streams, distinguishing it from Superfluid handling.

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 restricts usage to MICRO_TRANSFER streams with parenthetical clarification that 'Superfluid streams are verified automatically,' providing clear when-to-use guidance that prevents incorrect invocation against the automatic sibling stream types.

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

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

No annotations provided, so description carries full burden. Excellently covers: return format (hp_... prefix), critical persistence constraint (cannot be retrieved later), auto-activation status (PRO tier), rate limits (15/day, 50/day), and pricing context (free during launch). Full behavioral disclosure.

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

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

Four dense sentences with zero waste. Critical warning ('MUST save') front-loaded. Every sentence conveys distinct high-value information (operation, return constraints, usage mapping, workflow position).

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?

Comprehensive for a 7-parameter registration tool. Describes return value format, persistence requirements, tier activation, rate limits, and authentication patterns despite lack of output schema. Covers all critical operational context.

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 has 100% coverage (baseline 3), but description adds significant value for wallet_address parameter by providing CDP AgentKit integration guidance for wallet creation. Also clarifies that the returned API key maps to agent_key parameter in other tools.

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?

Clear specific verb (Register) + resource (agent on Human Pages). Distinguishes from sibling tool register_as_arbitrator by specifying this is for hiring workflow ('Typical first step before hiring') versus arbitration.

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 this is the 'Typical first step before hiring' and identifies downstream tools requiring the output (create_job_offer, get_human_profile). Lacks explicit 'when not to use' (e.g., check get_agent_profile first), but strong positive 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 provided, so description carries full disclosure burden. It effectively communicates key constraints: fee cap (10%), whitelisting gate, webhook /health requirement, and wallet signature verification. Deducting one point for not describing success/failure behavior or side effects of registration.

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 that are information-dense and logically ordered: purpose → role explanation → prerequisite → parameter requirements. No redundant phrases, though slightly dense. 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?

Given the complexity (6 parameters, cryptographic signing, webhooks, whitelisting), the description adequately covers prerequisites and input requirements. No output schema exists; while the description omits return value details, this is acceptable for a registration endpoint where success/failure is standard.

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%, establishing baseline 3. The description references most parameters (webhook, fee, specialties, signed message) but primarily reinforces information already in schema (e.g., /health endpoint, basis points). Adds minimal semantic meaning beyond structured field 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 explicitly states the tool registers 'your agent as an escrow arbitrator' and clarifies the role (resolving disputes for a fee). It clearly distinguishes from siblings like list_arbitrators (querying) and submit_verdict (acting as an arbitrator vs. becoming one).

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

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

Provides explicit prerequisite ('You must be whitelisted by the platform owner first'), which is critical usage guidance. Lacks explicit 'when not to use' or comparison to alternatives, though the distinction from siblings is relatively clear from the purpose statement.

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 code format (HP-XXXXXXXX) but lacks details about side effects, idempotency, return structure, or rate limits. Adequate but minimal behavioral context for a mutation-type 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?

Two sentences with zero waste. First sentence covers purpose and output format; second covers usage constraints and alternatives. Every word earns its place and the structure is immediately scannable.

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

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

Given 100% schema coverage and no output schema, the description compensates reasonably well by clarifying the optional business logic and code format. However, it could strengthen completeness by explicitly describing the return value or interaction with verify_social_activation sibling.

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 parameter (agent_key), so the schema fully documents inputs. The description adds no specific parameter guidance beyond the schema, meeting the baseline for high-coverage schemas.

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 provides a specific verb (Request), identifies the resource (activation code with format HP-XXXXXXXX), and clarifies the purpose (post on social media for verified trust badge). It also distinguishes from API access and registration scenarios, providing clear scope 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?

Explicitly states when NOT to use the tool ('Not required for API access') and identifies the alternative path ('agents are auto-activated on registration'). Opening with 'Optional:' immediately signals usage context, making the guidance 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 provided, the description carries full burden and successfully discloses critical behavioral traits: state machine transition (SUBMITTED→ACCEPTED), side effects (human receives notification), and workflow impact (human can resubmit). Only gap is lack of error handling or idempotency details.

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?

Five efficient sentences with zero waste. Front-loaded with critical state constraint (SUBMITTED). Logical flow: purpose/precondition → workflow effect → parameter instruction → notification side effect → alternative tool. Every sentence 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?

Given no annotations and no output schema, the description adequately covers the essential workflow context: state transition logic, notification behavior, and differentiation from sibling approve_completion. Lacks only error scenario description (what happens if job is not SUBMITTED).

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%, establishing baseline 3. The description adds valuable context beyond schema: it emphasizes that 'reason' requires a clear explanation of what needs fixing, and constrains 'job_id' by stating the job must be in SUBMITTED status. This provides semantic context for proper parameter usage.

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 phrase 'Request changes on submitted work' and explicitly distinguishes from sibling tool approve_completion in the final sentence. It also clarifies the specific resource (submitted work/jobs) and precondition (job must be SUBMITTED).

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 when-to-use guidance via state requirement '(job must be SUBMITTED)' and explicitly names the alternative tool: 'Use approve_completion instead if the work is satisfactory.' This covers both the prerequisite condition and the primary alternative sibling.

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 important behavioral details for both modes: backend verification step for Superfluid and creation of 'pending tick' for micro-transfer. Since no annotations exist, description carries full burden but omits general mutation risks, side effects, or idempotency guarantees.

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

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

Two sentences with front-loaded core action. Second sentence efficiently packs dual-mode context using em-dash separation. No redundant phrases, though density slightly impacts readability.

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?

Adequately covers the dual-mode complexity and workflow prerequisites. Lacks return value description (no output schema exists) and explicit sibling differentiation. Missing guidance on error conditions or failure modes.

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%, establishing baseline 3. Description adds contextual linkage between 'create a new flow' and the sender_address parameter (Superfluid), but does not add syntax details or format guidance 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?

States specific actions (resume stream) and distinguishes two operational modes (Superfluid vs micro-transfer). However, it does not explicitly differentiate from sibling tools like start_stream or pause_stream, which are available on the same server.

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 guidance for Superfluid context ('create a new flow first, then call this'). Establishes prerequisite ordering. Lacks explicit 'when not to use' or alternative tool recommendations.

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 effectively. It discloses geocoding behavior ('use fully-qualified names... for accurate geocoding'), response contents ('total count and resolvedLocation'), and permission requirements. It could improve by mentioning pagination or rate limits, but covers the essential behavioral traits well.

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?

Despite covering 25 parameters worth of complexity, it remains tightly structured in 5 information-dense sentences. It follows a logical flow: purpose → outputs → filter philosophy → key examples → response metadata → prerequisites → workflow. Every sentence adds distinct value without repetition.

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

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

Given the high parameter count (25), lack of output schema, and lack of annotations, the description achieves completeness by listing returned fields, explaining the geocoding resolution behavior, stating default values (30km), and providing the end-to-end workflow. It successfully prepares the agent for the tool's full lifecycle.

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

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

With 100% schema coverage, the baseline is 3. The description adds significant value by providing concrete examples ('photography', 'Richmond, Virginia, USA'), explaining the semantic purpose of filters ('find proven workers'), and highlighting which filters are key. This contextualizes the raw schema parameters effectively.

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 phrase 'Search for humans available for hire' and clearly distinguishes this from sibling tools like 'get_human' and 'get_human_profile' by stating it returns multiple profiles and emphasizing the filtering/browsing capability ('All filters are optional... to browse').

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 workflow chain ('search_humans → get_human_profile → create_job_offer'), identifies prerequisites ('registered agent needed'), and explains when to use specific filters ('min_completed_jobs=1... no skill filter needed') versus browsing. Clearly states that contact info requires a different 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?

With no annotations, description carries full burden and delivers: delivery mechanism (email/Telegram notifications), rate limiting (10/minute), and valid contexts (job states). Could improve by mentioning error conditions or return value 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?

Six information-dense sentences with zero waste. Front-loaded with core action ('Send a message'), followed by constraints, related tools, and limits. No filler 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?

With 3 parameters, 100% schema coverage, and no output schema, the description is complete: covers invocation requirements (job states, rate limits), side effects (notifications), and complementary tools needed for the conversation loop.

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 has 100% coverage with complete param descriptions. Description reinforces the 2000 character limit but adds no new semantic information beyond what the schema already provides, warranting the baseline score for high-coverage schemas.

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?

Clear specific verb ('Send') with resource ('message'), recipient ('the human'), and context ('on an active job'). Distinguishes from sibling get_job_messages (read vs write) and create_job_offer by specifying operational messaging on existing jobs.

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 valid job states (PENDING, ACCEPTED, PAID, STREAMING, PAUSED) for when to use. Explicitly names sibling tool get_job_messages with 'Use get_job_messages to read replies' for when NOT to use and the correct alternative.

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

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

No annotations provided, yet description fully discloses critical behavioral traits: financial impact ('controls where payments are attributed'), security model (EIP-191 verification), state outcomes ('verified' vs 'unverified' wallets), and trust implications ('proving you sent the payment, not just found a random tx hash').

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 with zero waste: front-loaded core action, followed by safety imperative, alternative creation method, and verification mechanics. Every sentence earns its place; appropriate urgency given financial safety implications.

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?

Comprehensive for a mutation tool without output schema: explains state changes (wallet set, verified/unverified), security requirements, and cross-tool workflow. Minor gap: could briefly indicate success confirmation (e.g., 'wallet will be updated for future payments'), but verification states are well-documented.

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%, establishing baseline 3. Description adds crucial semantic relationships: signature/nonce are optional but enable verification, nonce originates from sibling tool get_wallet_nonce, and verification status determines payment attribution capabilities. Exceeds schema by explaining why parameters matter beyond their types.

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?

Excellent specificity: 'Set the wallet address for a registered agent' provides clear verb and resource. Distinguishes from sibling get_wallet_nonce by stating this performs the actual setting vs. nonce retrieval.

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

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

Explicit when/when-not guidance: 'Always confirm the wallet address with the user before calling... never set wallets autonomously.' Identifies alternative approach (CDP AgentKit) and cross-references prerequisite tool get_wallet_nonce for verification flow.

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

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

No annotations provided, yet description fully discloses behavioral traits: commits ongoing funds (financial impact), requires crypto on-chain, distinguishes two operational modes (Superfluid verification vs micro-transfer locking), details prerequisites (token wrapping, specific contract address 0xcfA132E353cB4E398080B9700609bb008eceB125), and side effects (locks network/token, creates pending tick).

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?

Information-dense and logically structured: purpose → warning → crypto requirement → Superfluid steps → micro-transfer behavior → network recommendation. Length is justified by complexity of two distinct payment modes and blockchain prerequisites. No redundant sentences.

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?

Comprehensive coverage of complex operational requirements for a financial/ blockchain mutation tool. Covers prerequisites, side effects, and verification steps for both payment modes. Minor gap: no mention of expected return values or success indicators given lack of output schema, but operational completeness is high.

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

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

Schema coverage is 100% (baseline 3). Description adds crucial semantic context: sender_address clarifies dual meaning for Superfluid vs micro-transfer modes; network parameter contextualized with specific L2 recommendations (Base, Arbitrum, Polygon) and gas cost rationale; token contextualized via USDCx wrapping instructions.

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 uses specific verb 'Start' with resource 'stream payment' and scope 'ACCEPTED stream job'. It clearly distinguishes this initialization action from siblings like pause_stream, resume_stream, stop_stream (control existing streams) and mark_job_paid (one-time payment).

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 prerequisites: 'Confirm with the user before starting', 'For Superfluid: you must FIRST create the on-chain flow, then call this'. Clear when-not-to-use guidance (don't call without user confirmation or prior flow creation). Recommends L2s for lower gas costs, providing clear decision criteria.

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 successfully indicates the operation is permanent ('permanently') and describes the state transition side effect (marks job 'completed'). However, it lacks details on error handling, reversibility confirmation, or what happens to underlying stream resources after stopping.

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

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

Two efficient sentences with zero waste. The first sentence front-loads the core action and primary side effect; the second sentence provides invocation constraints. Every word earns its place with no 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 2-parameter mutation tool with no output schema, the description adequately covers the essential behavioral contract: the action (stop), the permanence, and the state prerequisites. While it could benefit from explicit mention of error conditions or return value structure, it provides sufficient context for safe invocation given the straightforward schema.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description mentions valid job states ('STREAMING or PAUSED'), which provides semantic context for the job_id parameter, but adds no further details about parameter formats, validation rules, or the agent_key requirements beyond what the schema already states.

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

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

The description uses a specific verb ('Stop') with a clear resource ('stream') and explicitly states the side effect ('mark the job as completed'). It distinguishes this from sibling tools by emphasizing the permanence of the action ('permanently'), implying this is the terminal state operation versus temporary alternatives like 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?

The description provides clear state-based prerequisites ('on STREAMING or PAUSED jobs') and identifies who can invoke the tool ('agent or human'). While it effectively signals when to use the tool, it does not explicitly name alternative tools (e.g., 'use pause_stream for temporary suspension') or explicitly state prohibited states.

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 EIP-712 signing mechanism and fee derivation from locked rates, but critically fails to mention that this is a destructive/final action that irreversibly distributes funds, or what happens to the dispute status after submission.

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

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

Three sentences, zero waste. Front-loaded with the core action (submit verdict), followed by fund split explanation, then specific signing instructions. Every sentence earns its place without redundancy.

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

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

Given the high complexity (cryptographic signing, financial distribution) and lack of output schema, the description adequately covers the input mechanism but is incomplete regarding operational risks. For a tool that moves money irreversibly, it should warn about finality and double-check requirements before signing.

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?

While schema coverage is 100%, the description adds crucial semantic context by mapping the parameters to the Verdict struct fields that must be signed ({ jobId, toPayee... }), clarifying the relationship between the signature parameter and the other inputs. This goes beyond the schema's individual field 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 specific action (submit a signed EIP-712 verdict), the resource (escrow dispute), and the outcome (resolve dispute). It distinguishes from sibling tools by specifying this is for arbitrators submitting final verdicts with fund splits, contrasting with tools like request_revision or get_dispute_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 provides context for when to use (resolving escrow disputes as an arbitrator) and implies the role requirements by mentioning 'Your arbitrator fee.' However, it lacks explicit guidance on when NOT to use (e.g., before reviewing evidence) or alternatives like requesting revisions, and omits prerequisites like arbitrator registration.

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

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

No annotations provided, so description carries full burden. Compensates well by detailing the two verification protocols (well-known file placement vs DNS TXT record) with precise paths/domains. Missing details on failure modes, retry behavior, or verification persistence duration.

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

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

Two tightly constructed sentences. First establishes purpose and prerequisite; second details both methods with specific technical requirements. Every clause delivers actionable information without redundancy. Front-loaded with critical prerequisite (websiteUrl requirement).

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?

Appropriately complete given 3 well-documented parameters and no output schema. The external setup requirements (DNS/file) are thoroughly explained. Could improve by indicating whether verification is persistent or requires periodic re-verification.

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

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

Schema coverage is 100% with agent_id, agent_key, and method all documented. Description adds substantial value by explaining method semantics beyond enum values—specifically the exact file path (/.well-known/humanpages-verify.txt) and DNS record location (_humanpages.yourdomain.com) required for each approach.

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?

Excellently clear: specifies verb (Verify), resource (domain ownership), target (registered agent), and distinguishes from sibling verification tools (verify_payment_activation, verify_social_activation) by focusing exclusively on domain-specific ownership validation.

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 clear prerequisite ('agent must have a websiteUrl set') and enumerates both available methods with specific implementation requirements. Lacks explicit 'when not to use' guidance comparing to sibling verification tools, but the domain-specific scope is self-evident.

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 success outcome (PRO tier activation), but omits critical behavioral details for a blockchain tool: failure modes, required confirmation blocks, idempotency, or return value structure.

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

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

Two sentences with zero waste: first establishes purpose, second discloses the success outcome. Every sentence earns its place with 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?

Lacks an output schema, so the description partially compensates by describing the success outcome. However, it fails to describe the return value format (boolean, object, or status) or error conditions, leaving gaps in the contract definition for a verification tool.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description does not add parameter-specific semantics (e.g., tx_hash format standards, network enum values) beyond what the schema already documents.

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 provides a specific verb ('Verify') and resource ('on-chain payment for PRO tier activation'), clearly distinguishing this from sibling tools like get_payment_activation (status retrieval) by emphasizing the activation outcome.

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 implied usage context ('On success, your agent is activated'), suggesting this is invoked after making a payment. However, it lacks explicit guidance on when to use this versus alternatives like claim_free_pro_upgrade or get_payment_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?

No annotations are provided, so the description carries the full disclosure burden. It fails to state what side effects occur (does it update agent status? is it idempotent?), what 'verified trust badge' actually grants, error conditions, or whether the verification is irreversible. Only the optional nature is disclosed.

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

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

Two sentences with zero waste. The first sentence defines purpose and outcome; the second clarifies optionality and distinguishes from registration. Every clause earns its place.

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

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

Given only two simple string parameters and no output schema, the description adequately covers high-level purpose. However, for a verification/mutation operation with no annotations, it lacks critical behavioral context (state changes, success indicators) that would be needed for safe 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% with complete descriptions for both agent_key and post_url in the schema. The description references 'social media post' and 'activation code' which align with the parameters, but adds no syntax, format, or example guidance beyond the schema definitions (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 clearly states the tool 'Verify[es] a social media post containing your activation code' to obtain 'a verified trust badge.' It distinguishes this from mandatory activation by noting it is 'Optional' and that 'agents are auto-activated on registration,' implicitly contrasting with register_agent and get_activation_status 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 when NOT to use the tool ('Not required for API access') and clarifies this is optional for a trust badge versus mandatory API access. However, it stops short of explicitly naming prerequisites (e.g., requiring request_activation_code first) or direct alternatives.

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