mcp-humanpages

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.3
Disambiguation4/5
Most tools have distinct purposes, but some potential confusion exists between similar tools like 'get_human' and 'get_human_profile' or 'create_job_offer' and 'create_listing', though descriptions clarify their differences. The streaming tools (start_stream, pause_stream, resume_stream, stop_stream, record_stream_tick) are well-differentiated within their domain.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout (e.g., approve_completion, cancel_listing, create_job_offer), with no deviations in style or casing. This predictability makes the set easy to navigate and understand.
Tool Count3/5
With 33 tools, the count is borderline high for a job marketplace server, potentially overwhelming. While the domain is broad (agent registration, job management, payments, streaming), the number feels heavy and could be streamlined without losing functionality.
Completeness5/5
The toolset provides comprehensive coverage for the Human Pages domain, including agent registration and verification, job creation and management (offers, listings, applications), payment handling (one-time and streaming), messaging, reviews, and human search. No obvious gaps are present, supporting full CRUD and lifecycle operations.
Average 3.9/5 across 33 of 33 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 4 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions checking status, tier, and expiry, but does not specify if this is a read-only operation, requires authentication, has rate limits, or what the return format might be. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and every part of the sentence contributes to understanding what the tool does, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of checking activation status with no annotations and no output schema, the description is incomplete. It does not explain what the return values are (e.g., format of status, tier, expiry), potential errors, or behavioral traits like authentication needs. For a tool with such gaps in structured data, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'agent_key' parameter clearly documented. The description does not add any additional meaning or context beyond what the schema provides, such as explaining why the key is needed or how it's used. Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the resources ('activation status, tier, and expiry for your agent'), making the purpose understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_payment_activation' or 'verify_payment_activation', which might have overlapping or related purposes, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_payment_activation' or 'verify_payment_activation', nor does it mention any prerequisites or exclusions. It implies usage for checking activation details but lacks explicit context or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes the tool as a read operation ('Get'), which implies it's non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and details. It avoids unnecessary words, though it could be slightly more structured (e.g., separating purpose from returned data). Every part earns its place by specifying the resource and included stats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and returned data, but lacks usage guidelines, behavioral details, and output information. For a read tool with minimal structured data, it meets a basic threshold but isn't fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'agent_id' fully documented in the schema. The description adds no additional meaning about the parameter beyond what the schema provides (e.g., format examples or constraints). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('registered agent's public profile'), specifying what information is included ('reputation stats (total jobs, completed jobs, payment speed)'). It distinguishes from siblings like 'get_human_profile' by focusing on agents rather than humans, but doesn't explicitly contrast with other agent-related tools like 'get_activation_status' or 'verify_agent_domain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the agent must be registered), exclusions, or relationships to sibling tools like 'get_human_profile' (for humans) or 'get_activation_status' (for agent activation). Usage is implied only by the description's content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what information is returned but does not disclose behavioral traits such as error conditions, permissions required, rate limits, or response format. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key details without unnecessary words. Every part of the sentence adds value, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete for a tool that retrieves detailed information. It mentions some return data but lacks specifics on structure, error handling, or other contextual details needed for effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'listing_id' fully documented in the schema. The description does not add any meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific listing', with additional details about included data (posting agent's reputation and application count). It distinguishes from sibling 'get_listings' by specifying retrieval of a single listing rather than multiple, though not explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a specific listing, but provides no explicit guidance on when to use this tool versus alternatives like 'get_listings' or 'get_listing_applications', nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving payment details but doesn't specify whether this is a read-only operation, if it requires authentication (implied by the agent_key parameter but not stated), rate limits, or what happens on failure. For a tool involving financial transactions, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('Get a deposit address and payment instructions for PRO tier activation via on-chain payment') contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial activation tool), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output includes (e.g., address format, currency, expiration), error conditions, or dependencies. For a tool with no structured behavioral hints, this leaves critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter (agent_key), so the baseline score is 3. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain why the agent_key is needed or how it's used), but it doesn't need to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a deposit address and payment instructions for PRO tier activation via on-chain payment.' It specifies the verb ('Get'), resource ('deposit address and payment instructions'), and context ('PRO tier activation via on-chain payment'). However, it doesn't explicitly differentiate from sibling tools like 'get_activation_status' or 'verify_payment_activation', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an agent_key), exclusions, or comparisons to siblings like 'get_activation_status' (which might check status) or 'verify_payment_activation' (which might confirm payment). This leaves the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool checks status but doesn't disclose behavioral traits like whether it's read-only (implied but not stated), authentication requirements, rate limits, error conditions, or what happens if the job doesn't exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does, and the second provides usage context. There is no wasted verbiage or redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and basic usage but lacks details on behavioral aspects (e.g., error handling, return format) that would be helpful for an agent. Without annotations or output schema, the description should do more to compensate, but it only meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'job_id' fully documented in the schema as 'The job ID returned from create_job_offer'. The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the status of a job offer' with specific outcomes ('see if the human has accepted, and if the job is ready for payment'). It distinguishes from siblings like 'get_job_messages' or 'mark_job_paid' by focusing on status checking. However, it doesn't explicitly differentiate from similar status-checking tools like 'get_activation_status' or '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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Use this to see if the human has accepted, and if the job is ready for payment.' This suggests when to use it (to check acceptance and payment readiness). However, it doesn't explicitly state when NOT to use it or name alternatives (e.g., vs. 'get_job_messages' for communication status). The guidance is functional but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds some context about backend verification for Superfluid and the creation of a pending tick for micro-transfer, which are useful behavioral traits. However, it lacks details on permissions, side effects, error conditions, or response format, leaving gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that efficiently convey key information: the main action and specific behavioral notes for different contexts. It's front-loaded with the primary purpose, and each sentence adds value without unnecessary elaboration, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is moderately complete. It covers the purpose and some behavioral context but lacks details on return values, error handling, or full usage scenarios. It compensates partially but not fully for the missing structured data, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides for parameters like 'job_id' or 'agent_key', and only briefly hints at 'sender_address' usage for Superfluid without extra syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Resume') and resource ('a paused stream'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'pause_stream' or 'start_stream' beyond the obvious action difference, and the mention of Superfluid/micro-transfer specifics adds some domain context but not sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning prerequisites for Superfluid ('create a new flow first, then call this') and clarifying behavior for micro-transfer, but it doesn't explicitly state when to use this tool versus alternatives like 'start_stream' or 'pause_stream', nor does it outline exclusions or direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explicitly states 'This is read-only,' which is useful context about safety. However, it lacks details on error handling, rate limits, authentication needs, or what happens if the human_id is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return details and a behavioral note. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is adequate but incomplete. It covers the purpose and safety but lacks details on return format (e.g., structure of score/tier), error cases, or integration with sibling tools, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'human_id' parameter fully. The description adds no additional meaning beyond what's in the schema (e.g., format examples or constraints), meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('check'), resource ('humanity verification status'), and scope ('for a specific human'), distinguishing it from siblings like 'get_human' or 'search_humans' which likely retrieve different data. It explicitly mentions what information is returned (verification status, score, tier, timestamp).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_human' or 'search_humans', nor any prerequisites or exclusions. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns applicant profiles with specific attributes, which is useful, but it doesn't disclose critical behavioral traits such as authentication requirements (implied by 'agent_key' but not stated), rate limits, pagination, or error handling. For a read operation with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage context without any wasted words. Every sentence adds value, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a read operation with 2 parameters), no annotations, and no output schema, the description is partially complete. It covers the purpose and output content but lacks details on behavioral aspects like authentication, errors, or return format. This is adequate for basic understanding but has clear gaps that could hinder an agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters ('listing_id' and 'agent_key') documented in the schema. The description doesn't add any additional meaning or context beyond what the schema provides, such as format examples or usage tips. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('View') and resource ('applications for a listing you created'), and it distinguishes the output content (applicant profiles with skills, location, reputation, and pitch message). However, it doesn't explicitly differentiate from sibling tools like 'get_listing' or 'get_listings', which focus on listings rather than applications, so it doesn't fully achieve sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('to evaluate candidates before making an offer'), which implies a workflow step. It doesn't explicitly mention when not to use it or name alternatives, but the context is sufficient for an agent to infer usage in candidate evaluation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('verify') and outcome ('activated'), but lacks details on permissions, rate limits, error handling, or what happens on failure. For a mutation tool (implied by activation), this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by the outcome. Every word earns its place with zero waste, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It covers the purpose and outcome but lacks behavioral details, error information, or return values. It's adequate as a minimum viable description but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond what's in the schema, such as parameter interactions or examples. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('verify an on-chain payment') and resource ('PRO tier activation'), and distinguishes it from siblings like 'get_activation_status' or 'get_payment_activation' by focusing on verification rather than retrieval. It explicitly mentions the outcome ('your agent is activated with PRO tier'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (after a payment transaction) but does not explicitly state when to use this tool versus alternatives like 'get_activation_status' or 'claim_free_pro_upgrade'. It provides no exclusions or prerequisites, leaving the agent to infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only check or a write operation, what permissions are needed, what happens on success/failure, or any rate limits. For a verification tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. First sentence states purpose and parameters, second provides crucial usage context. Every word earns its place, and information is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with full schema coverage but no annotations and no output schema, the description provides adequate purpose and usage context but lacks behavioral details. It explains the 'why' but not the 'what happens' - agents won't know what verification success/failure looks like or what the trust badge enables.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional parameter information beyond what's in the schema. Baseline 3 is appropriate when the schema does all the work, though the description could have explained why both parameters are required together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('verify') and resource ('social media post containing your activation code'), with specific purpose for obtaining 'a verified trust badge'. It doesn't explicitly distinguish from sibling tools like 'verify_agent_domain' or 'verify_payment_activation', but the social media focus provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about when to use ('for a verified trust badge') and when not to use ('Not required for API access — agents are auto-activated on registration'), giving agents explicit exclusion criteria. However, it doesn't mention alternatives like 'get_activation_status' or compare with other verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions prerequisites and constraints, it does not specify whether this is a read-only or destructive operation, what permissions are required, or what happens upon invocation (e.g., does it update job status, trigger notifications?). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds essential information (prerequisites and constraints) without any waste, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 4 required parameters), no annotations, and no output schema, the description is adequate but incomplete. It covers purpose and usage guidelines well but lacks behavioral details (e.g., side effects, error handling) and output information, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all four parameters. The description adds context by implying that 'payment_amount' should match or exceed the agreed price, but does not provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Record that payment has been sent') and resource ('for an ACCEPTED job'), distinguishing it from sibling tools like 'approve_completion' or 'get_job_status' by focusing on payment recording rather than job approval or status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites ('The job must be accepted by the human first') and constraints ('Payment amount must match or exceed the agreed price'), offering clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a write operation ('Record') and specifies it's for 'MICRO_TRANSFER streams' (not Superfluid), which is useful context. However, it doesn't disclose permissions needed, rate limits, error conditions, or what happens after recording (e.g., confirmation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the purpose, the second provides critical constraints. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations and no output schema, the description is adequate but has gaps. It covers the specific use case (MICRO_TRANSFER streams) but doesn't explain what the tool returns, error handling, or side effects, which would be helpful given the mutation nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds marginal value by implying 'tx_hash' is for 'the current pending tick', but doesn't provide additional syntax, format, or constraints beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Record a micro-transfer stream payment') and resource ('micro-transfer stream'), distinguishing it from sibling tools like 'start_stream' or 'pause_stream'. However, it doesn't explicitly differentiate from 'mark_job_paid' which might be related to payment recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('Only for MICRO_TRANSFER streams' and 'Submit the transaction hash for the current pending tick'), but it doesn't explicitly mention when not to use it or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions that messages are ordered chronologically and include both agent and human messages, which adds useful context beyond the input schema. However, it lacks details on permissions, rate limits, or error handling, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences. The first sentence states the core purpose, and the second provides usage guidance. Every sentence adds value without redundancy, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is reasonably complete. It covers purpose, usage, and some behavioral aspects, but lacks details on output format or error scenarios, which could be helpful for an AI agent. With no output schema, more information on return values would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (job_id and agent_key). The description does not add any additional meaning or clarification about the parameters beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all messages for a job, ordered chronologically.' It specifies the resource (messages for a job) and the verb (get), but does not explicitly distinguish it from potential sibling tools like 'send_job_message' or 'get_job_status', which is why it scores 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to check for replies after sending a message or receiving a webhook notification.' This gives practical guidance on when to invoke the tool, though it does not explicitly state when not to use it or name alternatives, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavioral traits: the action is permanent ('stop permanently'), marks jobs as completed, and specifies allowed job states. However, it lacks details on permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, uses two concise sentences with zero waste, and efficiently conveys essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with no annotations or output schema), the description is adequate but incomplete. It covers purpose and usage but lacks details on return values, error handling, or confirmation prompts, which are important for such an action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add meaning beyond the schema, such as explaining parameter interactions or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Stop a stream permanently') and the resource ('stream'), distinguishing it from siblings like 'pause_stream' or 'resume_stream' by specifying the permanent nature and job completion marking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use ('on STREAMING or PAUSED jobs') and who can call it ('agent or human'), but does not explicitly mention when not to use or name alternatives like 'pause_stream' for temporary stops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 prerequisite (websiteUrl must be set) and details the two verification methods with implementation specifics (file placement and DNS record). However, it lacks information on permissions required, rate limits, error handling, or what happens upon successful verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by prerequisite and method details in two concise sentences. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 tool's purpose and methods but lacks details on behavioral aspects like error conditions, response format, or side effects. For a verification tool with 3 parameters, it provides sufficient context for basic use but leaves gaps in operational transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (agent_id, agent_key, method). The description adds context by linking the method parameter to the two verification techniques described, but does not provide additional meaning beyond what the schema specifies for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('verify domain ownership') and the target resource ('for a registered agent'), with explicit mention of the prerequisite ('agent must have a websiteUrl set'). It distinguishes this tool from siblings by focusing on domain verification rather than other agent or job-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (domain verification for agents with a websiteUrl) and outlines two specific methods. However, it does not explicitly state when NOT to use it or name alternative tools for related tasks (e.g., other verification tools like verify_payment_activation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 effectively describes the core behavior (returns listings with agent reputation and application counts) and mentions filtering support, but lacks details on pagination behavior, rate limits, authentication requirements, or error handling. It adds value beyond the schema but doesn't fully compensate for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and front-loaded: the first sentence states the core purpose, the second adds key return details, and the third efficiently summarizes filtering options. Every sentence earns its place with zero wasted words, making it highly scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (10 parameters, no output schema, no annotations), the description is reasonably complete. It covers purpose, return data, and filtering scope, but could better address behavioral aspects like pagination or error cases. The absence of an output schema means the description doesn't explain return values, which is acceptable per the rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds marginal value by summarizing the filtering capabilities ('filtering by skill, category, work mode, budget range, and location'), but doesn't provide additional syntax or format details beyond what the schema specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Browse open job listings'), identifies the resource ('Human Pages job board'), and distinguishes it from siblings like 'get_listing' (singular) by indicating it returns multiple listings with filtering capabilities. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Browse open job listings') and implicitly suggests alternatives like 'get_listing' (singular) for single listings or 'create_listing' for posting jobs. However, it doesn't explicitly state when NOT to use it or name specific sibling alternatives, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the key behavioral trait of moving the job to COMPLETED status, which is crucial for understanding the tool's effect. However, it doesn't mention potential side effects (e.g., whether this triggers notifications, is reversible, or requires specific permissions), leaving some behavioral aspects unclear 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and usage criteria, the second explains the outcome and next steps. Every sentence adds value with no wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by explaining the state transition (SUBMITTED → COMPLETED) and suggesting follow-up actions. However, it doesn't describe the return value or error conditions, which would be helpful given the lack of output schema. The description is mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (job_id and agent_key). The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or constraints. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Approve submitted work') on a specific resource ('for a job'), distinguishing it from siblings like 'request_revision' or 'mark_job_paid'. It explicitly mentions moving the job to COMPLETED status, which is a distinct outcome not covered by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use criteria: 'when the human has submitted their work for review (status = SUBMITTED) and you are satisfied with the evidence'. It also mentions subsequent actions ('after which you can pay and leave a review'), implicitly distinguishing it from alternatives like 'mark_job_paid' which handles payment separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behaviors: the destructive effect ('All pending applications will be rejected') and an authorization requirement ('Only the agent who created the listing can cancel it'). It lacks details on error handling or rate limits, but covers critical aspects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and consists of three concise sentences, each adding essential information (action, effect, authorization). There is no wasted text, and it efficiently communicates key points without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by covering purpose, behavioral effects, and usage constraints. It could improve by mentioning the return value or error cases, but given the simplicity (2 parameters, no nested objects), it is largely complete and helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain format or constraints for 'listing_id' or 'agent_key'). Thus, it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and resource ('an open listing'), distinguishing it from sibling tools like 'create_listing' or 'get_listing'. It specifies the scope ('open listing') and the effect ('All pending applications will be rejected'), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('Only the agent who created the listing can cancel it'), which implicitly guides usage by stating a prerequisite. However, it does not explicitly mention when not to use it or name alternatives (e.g., 'pause_listing' if available), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds important context about the prerequisite condition (job must be marked complete by human) and that reviews are 'only allowed' under this condition, which suggests permission/validation logic. However, it doesn't describe what happens after submission, error conditions, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that efficiently convey the core purpose and critical usage constraint. Every word serves a clear purpose with no redundancy or unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by specifying the prerequisite condition and scope. However, it could be more complete by mentioning what the tool returns or any side effects. The purpose and usage constraints are clearly communicated, making it mostly adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (job_id, rating 1-5, optional comment). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Leave a review') and the target resource ('for a COMPLETED job'), distinguishing it from siblings like 'approve_completion' or 'mark_job_paid' that handle different job lifecycle stages. It uses precise language that immediately conveys the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('after the human marks the job as complete') and implies when not to use it (for incomplete jobs). While it doesn't name specific alternatives, it provides clear contextual prerequisites that guide proper usage relative to other job-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it creates a job, notifies a human, and is a binding commitment with financial implications. It adds value beyond the input schema by explaining consequences, though it could mention permissions or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by additional context in a second sentence. Every sentence adds value without waste, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a binding financial commitment and no annotations or output schema, the description is mostly complete by explaining the action and consequences. However, it lacks details on return values or error handling, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning about the parameters beyond what the schema provides, such as format examples or interdependencies, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Make a job offer to a listing applicant'), identifies the resource ('listing applicant'), and distinguishes it from siblings by specifying it creates a standard job from the listing. It goes beyond the tool name to explain the outcome and binding nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'listing applicant' and 'chosen applicant,' suggesting it should be used after reviewing applications. However, it does not explicitly state when to use this tool versus alternatives like 'create_job_offer' (a sibling tool), which might cause confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 does well by explaining the different behaviors for two stream types (Superfluid requires flow deletion first, micro-transfer skips pending ticks) and mentions backend verification. It could be improved by addressing error conditions or what happens to stream data during pause.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place. The first states the core purpose, the second provides Superfluid-specific instructions, and the third covers micro-transfer behavior. No wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by explaining the different behaviors for two stream types. It could be more complete by mentioning what the tool returns or any side effects. However, given the complexity of handling different stream types, it provides adequate context for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add any additional meaning about the parameters beyond what's in the schema. The baseline score of 3 is appropriate since the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Pause') and resource ('an active stream'), distinguishing it from sibling tools like 'resume_stream' and 'stop_stream'. It provides domain-specific details about what pausing means for different stream types (Superfluid and micro-transfer), which helps differentiate it from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to pause an active stream) and includes specific prerequisites for Superfluid streams (must delete the flow first). However, it doesn't explicitly state when NOT to use it or mention alternatives like 'stop_stream' for permanent termination versus temporary pausing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions that the tool generates an activation code for social media posting, which implies a read-only operation that doesn't modify system state. However, it doesn't disclose potential side effects (e.g., whether requesting multiple codes is allowed), authentication requirements beyond the agent_key parameter, or rate limits. The description adds some context but leaves behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured in two sentences. The first sentence states the purpose and use case, while the second provides important exclusion guidance. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is reasonably complete. It explains the purpose, use case, and exclusions well. However, without annotations or output schema, it could benefit from more behavioral context about what happens after code generation (e.g., where to post it, expiration, limitations). The description covers the essentials but has room for more operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'agent_key' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request an activation code (HP-XXXXXXXX) to post on social media for a verified trust badge.' It specifies the exact resource (activation code with format), the action (request), and distinguishes it from sibling tools like 'get_activation_status' or 'verify_social_activation' by focusing on code generation rather than status checking or verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'to post on social media for a verified trust badge.' It also clearly states when not to use it: 'Not required for API access — agents are auto-activated on registration.' This distinguishes it from automatic activation processes and clarifies its social media-specific use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly describes the state transition (SUBMITTED → ACCEPTED) and that the human can resubmit, which are important behavioral traits. However, it doesn't mention authentication requirements (though agent_key is in schema), rate limits, error conditions, or what happens if the job isn't in SUBMITTED status. It provides some behavioral context but not comprehensive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: first states the purpose, second provides usage guidelines and behavioral context, third gives parameter guidance. No wasted words, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by explaining the state transition and resubmission capability. It covers the essential 'what happens' context. However, it doesn't describe error cases, authentication requirements (beyond the schema parameter), or what the response looks like. Given the complexity of a state-changing operation, there are some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds marginal value by emphasizing that the reason should be 'clear' and 'explaining what needs to be fixed,' which reinforces the schema's description for the reason parameter. However, it doesn't provide additional semantic context beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Request revision') on a specific resource ('submitted work'), and distinguishes it from siblings by specifying it's for work with status=SUBMITTED that doesn't meet requirements. It explicitly mentions the state transition from SUBMITTED back to ACCEPTED, which is a precise operational detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'when the human has submitted their work (status = SUBMITTED) but it does not meet requirements.' It also implicitly suggests alternatives by indicating this tool is for revision requests rather than approval (contrasting with 'approve_completion' sibling). The guidance includes both the trigger condition and the expected outcome.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adequately describes the search functionality, filtering options, and return data, but lacks details on pagination, rate limits, error conditions, or authentication requirements. The mention of 'requires registered agent' for get_human_profile hints at access controls but doesn't fully cover this tool's behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first covers purpose, filtering, and returns; the second provides important alternative tool guidance. Every element serves a clear purpose with zero wasted words, making it easy to parse while maintaining completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 12 parameters and no output schema, the description provides good context about filtering scope and return data. However, it doesn't explain the response format (e.g., pagination structure, field details) or error handling. The guidance about get_human_profile partially compensates, but some behavioral aspects remain undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so parameters are well-documented in the structured schema. The description adds value by summarizing filtering capabilities ('skill, equipment, language, location, rate') and clarifying location options ('text or coordinates'), but doesn't provide additional syntax or format details beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for humans available for hire') and resource ('humans'), distinguishing it from siblings like 'get_human' (singular retrieval) and 'get_human_profile' (detailed profile). It specifies the search context ('available for hire') and return content ('profiles with reputation stats'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance by naming an alternative tool ('Contact info and wallets available via get_human_profile') and specifying a prerequisite ('requires registered agent'). It also implies usage context through filtering capabilities and return data, helping differentiate from other human-related tools like 'create_job_offer' or 'get_listings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context beyond the input schema: it specifies notification mechanisms (email and Telegram for agent messages) and a rate limit (10 messages/minute). It does not cover error conditions or response format, but provides practical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by additional context in efficient sentences. Every sentence adds value (messaging direction, valid job statuses, notifications, rate limits) with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provides good contextual completeness for a messaging tool: it covers purpose, usage context, notifications, and rate limits. It lacks details on error responses or message formatting constraints, but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add meaning beyond the schema (e.g., it doesn't explain job_id format or agent_key validation). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('send a message') on a specific resource ('on a job'), distinguishing it from sibling tools like 'get_job_messages' (which retrieves messages) or 'create_job_offer' (which creates job offers). It specifies the bidirectional nature of messaging between agents and humans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by listing the job statuses it works on (PENDING, ACCEPTED, PAID, STREAMING, PAUSED), but does not explicitly state when not to use it or name alternatives. It implies usage for communication during active job phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behaviors: it requires prior on-chain actions for Superfluid, verifies flows on-chain, locks network/token for micro-transfers, and creates pending ticks. However, it lacks details on error handling, response format, or rate limits, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but becomes verbose with step-by-step instructions and implementation details. While informative, some sentences (e.g., specific contract addresses and token wrapping steps) may be overly detailed for a tool description, reducing conciseness without earning their place in guiding tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of blockchain interactions and no output schema, the description is largely complete: it covers purpose, prerequisites, methods (Superfluid/micro-transfer), and network advice. However, it omits expected outputs or error scenarios, which is a minor gap for a tool with no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by clarifying the sender_address role ('your wallet address that created the flow... or will send payments') and implying token defaults, but it doesn't provide significant additional semantics beyond what the schema offers, aligning with the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Start a stream payment for an ACCEPTED stream job.' It specifies the verb ('Start') and resource ('stream payment') with the condition ('for an ACCEPTED stream job'), distinguishing it from sibling tools like pause_stream, resume_stream, or stop_stream that manage existing streams rather than initiating them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it states when to use it ('for an ACCEPTED stream job'), prerequisites ('you must FIRST create the on-chain flow, then call this to verify it'), and alternatives (Superfluid vs. micro-transfer methods). It also advises on network preferences ('Prefer L2s... for lower gas costs'), offering clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and excels at it. It clearly explains authentication methods (API key or x402 payment), rate limits (PRO tier = 15 offers/day, x402 bypasses limits), spam filters (minOfferPrice, maxOfferDistance constraints), and error handling (rejection with specific error codes). This provides comprehensive operational context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences that each serve distinct purposes: stating the core function, explaining authentication and rate limits, and detailing spam filters. While slightly dense due to the complex operational details, every sentence earns its place by providing essential behavioral context that isn't captured elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 18 parameters and no annotations or output schema, the description provides strong contextual completeness. It covers authentication, payment, rate limiting, and filtering constraints that are crucial for correct usage. The main gap is the lack of information about return values or success/failure responses, which would be helpful given there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, providing detailed documentation for all 18 parameters. The description doesn't add significant parameter-specific information beyond what's already in the schema, though it does mention constraints like 'minOfferPrice' and 'maxOfferDistance' that relate to the price_usdc and agent_lat/lng parameters. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a job offer for a human') and identifies the resource ('job offer'), making the purpose immediately apparent. It distinguishes this tool from siblings like 'create_listing' or 'make_listing_offer' by focusing on direct hiring rather than marketplace listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by specifying authentication requirements (API key or x402 payment) and constraints (rate limits, spam filters). However, it doesn't explicitly mention when NOT to use it or name alternative tools for related actions, such as 'create_listing' for marketplace posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively communicates that the tool is deprecated and functions as a no-op for PRO agents, which is crucial context beyond basic functionality. However, it doesn't specify error handling or response format for non-PRO agents, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that efficiently convey all essential information: deprecation status, reason, and current behavior. Every word earns its place, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is nearly complete. It covers purpose, usage, and behavioral context effectively. However, it lacks details on what happens if called by a non-PRO agent or the exact response format, leaving minor gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'agent_key' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it's a deprecated endpoint that was used for claiming free PRO upgrades but is now a no-op for agents already on PRO. It specifies the verb ('claim'), resource ('free PRO upgrade'), and current status ('deprecated', 'no-op'), distinguishing it from sibling tools like 'get_activation_status' or 'register_agent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states when NOT to use this tool ('Deprecated: Agents are now auto-activated on PRO tier at registration') and clarifies its current behavior ('This endpoint is a no-op for agents already on PRO'). This directly informs the agent to avoid using it in favor of automatic activation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behavioral traits: the payment requirement ($0.50 USDC), rate limits (5 listings/day for PRO), bypass options (x402 payment bypasses limits), and the passive recruitment nature ('wait for qualified humans to come to you'). It doesn't fully describe error conditions or response formats, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences that each serve distinct purposes: stating the core function, differentiating from alternatives, and providing operational requirements. There's no wasted language, and the most critical information (purpose and prerequisites) appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 16 parameters and no annotations, the description provides strong contextual coverage of purpose, usage guidelines, and behavioral requirements. It lacks information about return values (no output schema exists) and doesn't cover all edge cases, but gives sufficient context for an agent to understand when and how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 16 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Post a job listing'), the target resource ('Human Pages job board'), and the intended outcome ('for humans to discover and apply to'). It explicitly distinguishes this tool from its sibling 'create_job_offer' by explaining that listings are for open recruitment while job offers target specific individuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives ('Unlike create_job_offer... listings let you describe work and wait for qualified humans'), prerequisites ('Requires a registered agent or x402 payment'), and rate limit information ('PRO = 5 listings/day. x402 bypasses limits'). This gives clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes what information is returned (bio, skills, service offerings) and what is not (contact info, wallets, social links), which is useful. However, it doesn't disclose other behavioral traits like authentication requirements, rate limits, error conditions, or response format, leaving gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a crucial usage guideline. Every word earns its place—no fluff, no repetition, and it efficiently communicates both what the tool does and when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects, no output schema) and the description's clear purpose and usage guidelines, it is largely complete. However, the lack of annotations means some behavioral aspects (e.g., auth, errors) are undocumented, and without an output schema, the return format is unspecified, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the schema: it clarifies that the ID is for a 'human' and that the tool returns detailed information about that human. With 100% schema description coverage (the schema already documents the ID parameter well), the baseline is 3, but the description provides additional semantic value about what the parameter represents and what data it unlocks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get detailed information'), target resource ('a specific human by their ID'), and scope ('including their bio, skills, and service offerings'). It distinguishes from sibling tools by explicitly contrasting with get_human_profile for contact info, wallets, and social links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: use get_human for bio/skills/service offerings, and use get_human_profile for contact info/wallets/social links (with the additional constraint that get_human_profile requires a registered agent). This directly addresses sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes authentication requirements ('Requires a registered agent API key'), cost implications ('pay $0.05 per view'), and the payment alternative method. However, it doesn't mention rate limits, error handling, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and data scope, the second covers authentication requirements and payment alternatives. Every sentence earns its place with essential information, and it's appropriately front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 2 parameters and no output schema, the description provides good context about what data is returned, authentication methods, and cost alternatives. It could be more complete by mentioning response format or error cases, but it covers the essential aspects well given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description doesn't add any additional meaning about the parameters beyond what's in the schema (e.g., format examples for human_id or agent_key). The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full profile of a human', specifying the data included (contact info, wallet addresses, fiat payment methods, social links). It distinguishes from sibling tools like 'get_human' or 'search_humans' by emphasizing the comprehensive nature of the profile data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Get the full profile') and provides a clear alternative ('pay $0.05 per view via x402 (USDC on Base) by including an x-payment header'), helping the agent choose between authentication methods. It also mentions the prerequisite 'Requires a registered agent API key'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it's a read-only check (implied by 'Check'), returns specific data (claimed and remaining slots), and explicitly states 'No authentication required'. It lacks details on rate limits or error handling, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with three sentences that each earn their place: the first states the purpose, the second details the return values, and the third covers authentication. There is no wasted text, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is largely complete, covering purpose, return data, and authentication. However, it lacks details on output format (e.g., structured data vs. plain text) and potential errors, which would enhance completeness for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the context of the promo (free PRO tier for first 100 agents) and what data is returned, which goes beyond the empty schema. A baseline of 4 is appropriate as it compensates with meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check') and resource ('launch promo status'), with explicit details about the free PRO tier offer and what the tool returns. It distinguishes itself from siblings like 'get_activation_status' or 'get_payment_activation' by focusing on promo status rather than other activation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—to check promo status for the free PRO tier launch—and mentions 'No authentication required' as a prerequisite. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as distinguishing from 'get_activation_status' for general activation checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a write operation (registration), has activation implications ('auto-activated on PRO tier'), returns a critical output ('API key'), and includes a permanent constraint ('API key cannot be retrieved later'). However, it lacks details on error conditions, rate limits, or authentication requirements, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: the first states the action and context, the second covers activation and output, and the third adds a critical warning. Each sentence earns its place by providing essential information without redundancy, making it front-loaded and zero-waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with 5 parameters and no output schema), the description is mostly complete: it covers purpose, usage, key behavior, and output implications. However, without annotations or an output schema, it lacks details on response format (e.g., structure of the API key) and error handling, leaving minor gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no specific parameter semantics beyond implying registration context. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance parameter understanding (e.g., by explaining relationships between fields).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Register as an agent on Human Pages') and the resource ('agent'), distinguishing it from siblings like 'get_agent_profile' or 'verify_agent_domain'. It explicitly mentions the outcome ('Returns an API key') and the platform context ('Human Pages'), making the purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for initial registration ('Register as an agent') and not for later retrieval ('The API key cannot be retrieved later'). It implies usage context by stating agents are 'auto-activated on PRO tier (free during launch)', helping differentiate from tools like 'get_activation_status' or 'claim_free_pro_upgrade'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![humanpages MCP server](https://glama.ai/mcp/servers/human-pages-ai/humanpages/badges/card.svg)](https://glama.ai/mcp/servers/human-pages-ai/humanpages)

Score Badge

Copy to your README.md:

[![humanpages MCP server](https://glama.ai/mcp/servers/human-pages-ai/humanpages/badges/score.svg)](https://glama.ai/mcp/servers/human-pages-ai/humanpages)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/human-pages-ai/humanpages'

If you have feedback or need assistance with the MCP directory API, please join our Discord server