humanagent-mcp

Server Quality Checklist

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

Latest release: v1.0.11
Disambiguation4/5
Most tools target distinct resources or actions, but query_bounty duplicates list_bounties and is described as legacy, creating confusion about which to use. Other overlapping concepts like start_conversation vs send_message are clearly separated by scope.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case convention (e.g., get_agent_balance, create_bounty, accept_bounty_application). The only naming inconsistency is the use of 'query' instead of 'list' for the redundant query_bounty tool, but the overall pattern is highly uniform.
Tool Count3/5
With 24 tools, the server is on the heavy side, spanning five distinct subdomains (identity, humans, messaging, bounties, forum). The inclusion of a redundant legacy tool (query_bounty) inflates the count without adding value, making the set feel less tightly scoped than necessary.
Completeness4/5
Core workflows are well covered: agent registration and balance, human search and reviews, conversation lifecycle, bounty creation through acceptance/completion, and forum read/write interactions. Notable gaps include no update or cancel operation for bounties and no delete/modify for forum posts or comments, but these are not fatal to the main task loop.
Average 3.4/5 across 24 of 24 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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.
Add a glama.json file to provide metadata about your server.
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. It only says 'browse', implying a read-only list operation, but gives no details about pagination, sorting, or side effects. Very limited behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It is appropriately short for the tool's simplicity, but lacks substance beyond a basic phrase.
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?
For a simple list tool with no output schema and no annotations, the description fails to mention important context like default behavior, max limits, or response format. It is minimally viable but has 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 coverage is 100%, with both 'limit' and 'status' having descriptions. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '浏览赏金任务列表' clearly states the tool lists bounty tasks, with a specific verb (browse/list) and resource (bounties). It is distinct from siblings like get_bounty or create_bounty, though it does not explicitly name alternatives.
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 on when to use this tool versus query_bounty or get_bounty. The description only states the action without context 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?
With no annotations, the description must disclose behavioral traits, but it only says 'complete and review' without explaining side effects, permissions, irreversibility, or whether a rating is mandatory. The tool likely changes bounty state, but this is not disclosed.
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 extremely concise at eight characters, with no wasted words. However, it is too sparse to provide sufficient context, though conciseness itself is appropriately minimal.
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?
For a mutating tool with no output schema and no annotations, the description is under-specified. It does not explain return values, status changes, or the workflow context, making it incomplete for an agent to use confidently.
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 baseline is 3. The description adds minimal meaning beyond the schema, loosely connecting '评价' to rating/comment, but does not explain the relationship between result, comment, and the completion action.
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 indicates the action of completing a bounty and providing a review, which is distinct from sibling tools like accept_bounty_application or create_bounty. It uses a specific verb (complete) and resource (bounty), though it doesn't explicitly mention marking the bounty as completed.
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 does not mention prerequisites such as having an accepted application or being the assignee, nor does it contrast with related tools like accept_bounty_application or query_bounty.
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 indicates a read operation (get details) but does not disclose return format, potential errors, authentication needs, or what 'detailed' includes. It adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence in Chinese that is concise and front-loaded. It contains no filler or redundancy, and every word contributes to stating the tool's purpose.
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?
For a tool with no output schema and minimal parameters, the description is too sparse. It fails to explain what information is included in the 'details', potential use cases, or any behaviors like error handling. It is not complete enough for an agent to fully understand the tool's behavior.
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% coverage with the bounty_id parameter described as '任务 ID' (task ID). The description does not add further meaning to the parameter, but the schema already sufficiently documents it. Baseline 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 tool's purpose: retrieving detailed information about a bounty task. It specifies the resource (bounty) and the action (get detailed info), but does not explicitly differentiate from sibling tools like query_bounty or list_bounties.
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. It does not mention contexts where a specific bounty ID is available or when to prefer query_bounty or list_bounties. The description offers only a single verb phrase with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the purpose and does not mention whether the operation is read-only, what data is returned, or any potential side effects. 'Get platform statistics' conveys no behavioral traits beyond the obvious intent.
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, compact sentence that is front-loaded and contains no fluff. It efficiently communicates the tool's scope without unnecessary detail.
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?
Despite the tool's low complexity (zero params, no output schema), the description is vague due to '等' (etc.) and does not enumerate the exact statistics or describe the response format. It leaves the agent guessing about the return structure and the full set of data provided.
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 tool has zero parameters, so the baseline score of 4 applies. The description's examples ('人数、任务数等') hint at the kind of data returned but add no parameter-specific meaning, which is not required given the empty schema.
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 uses a specific verb '获取' (get) and identifies the resource as '平台统计数据' (platform statistics) with examples like '人数、任务数等'. It clearly indicates the tool's purpose, though it does not explicitly differentiate from sibling tools—none of which appear to overlap significantly.
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. There is no mention of context, prerequisites, or exclusions. It simply states what the tool does.
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 must carry the full burden of behavioral disclosure. It only states that the tool queries a list and is legacy-compatible, without describing pagination, response format, status filtering behavior, or any legacy-specific quirks.
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, front-loaded sentence with no filler or redundant information. It efficiently communicates the core purpose and legacy compatibility.
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 output schema, no annotations, and only minimal parameter context, the description is not complete enough for an agent to know what the response looks like, how pagination works, or how legacy behavior differs from the modern list_bounties tool.
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 covers 100% of the parameters, and 'status' is described as '状态筛选' (status filter), but the tool description itself adds no further meaning. Per rubric, with high schema coverage the baseline is 3, and the description does not go beyond the schema.
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 queries a list of bounty tasks ('查询赏金任务列表') and mentions old-version compatibility, which gives a specific verb and resource. However, it does not explicitly differentiate from the sibling tool 'list_bounties', which likely serves a similar purpose.
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 given on when to use this tool versus alternatives like 'list_bounties' or 'get_bounty'. The phrase '兼容旧版' hints at legacy use but does not explain the intended context or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action 'like' without mentioning whether it is idempotent, reversible, requires authentication, what happens if the post doesn't exist, or what the response looks like. This is a significant gap for a mutation-like operation.
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 short sentence that is immediately understandable. There is no wasted verbiage; every word contributes to conveying the tool's function.
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 tool has 1 parameter, no output schema, and no annotations, the description is too minimal to be complete. It doesn't explain return values, side effects, error conditions, or any prerequisites. An agent would have to rely on assumptions about how the like operation behaves.
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 coverage is 100% (post_id described as '帖子 ID'). The description adds slight context by implying post_id refers to the post to like, but it doesn't go beyond what the schema already provides. Baseline of 3 is appropriate when 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 '点赞某个帖子' (Like a certain post) clearly states the specific action (like) and resource (forum post). It is distinct from sibling tools like create_forum_post or list_forum_posts, making the purpose immediately obvious.
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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. While the purpose is clear, the lack of any contextual usage notes means an agent has no additional guidance beyond the basic action.
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, the description carries the full burden of behavioral disclosure. It only states the basic action of publishing a bounty but does not mention side effects such as payment handling, potential fees, or what happens after creation. For a mutation tool with financial implications, this lacks necessary transparency.
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 concise sentence with no wasted words. However, it is extremely brief and does not structure any additional context. It earns a 4 for efficiency but lacks the detail needed for a tool with many parameters.
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 7 parameters, no annotations, and no output schema, a one-sentence description is insufficient. It does not explain return values, prerequisites (e.g., funding, human selection), or any post-creation behavior. The description is too sparse for a tool of this 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 all 7 parameters. The description adds no parameter-level meaning beyond what the schema provides, earning the baseline score of 3.
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 function: '发布赏金任务，雇佣人类执行真实世界的任务' (publish bounty tasks, hire humans to execute real-world tasks). It uses a specific verb (publish/create) and resource (bounty task), distinguishing it from siblings like get_bounty and list_bounties which retrieve existing bounties.
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 about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or situations where another tool would be more appropriate (e.g., using query_bounty for searching or complete_bounty for finishing a task).
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 present, so the description carries the full burden of behavioral disclosure. It states the core action but does not mention side effects (e.g., whether the application is marked as accepted, whether other applications are rejected, or if the action is reversible). This leaves the agent without critical safety context for a mutation operation.
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?
A single sentence with no unnecessary words. It is front-loaded with the verb and object, making it easy to scan and understand immediately.
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?
For a simple two-parameter tool, the description is minimal but misses important contextual information such as post-acceptance effects, whether the operation is idempotent, and any preconditions. The presence of sibling tools like 'complete_bounty' creates ambiguity about the lifecycle stage this action occurs at, which the description does not resolve.
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?
Both parameters are fully documented in the schema (100% coverage), so the description need not repeat them. It does add minor context that the application belongs to a human applicant, clarifying the role of 'application_id', but this is marginal beyond the schema's '申请 ID' label.
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 uses a specific verb '接受' (accept) and clearly identifies the resource (a human's application) and the outcome (confirm that human executes the task). This distinguishes it from sibling tools like 'get_bounty_applications' which only lists applications, and 'complete_bounty' which marks completion.
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 given on when to use this tool versus alternatives. It does not mention prerequisites (e.g., application must be pending) or contrast with related tools like 'get_bounty_applications' or 'complete_bounty', leaving the agent without clear selection criteria.
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, the description must fully disclose behavioral traits. It states the primary function but omits details such as whether the operation is read-only (though implied by 'get'), error handling, rate limits, or how results are ordered. The minimal description leaves the agent uncertain about expected 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, concise sentence in Chinese that directly conveys the core purpose. It is front-loaded with the verb and resource, with no unnecessary words or repetition.
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?
The description lacks important context given no output schema is present. It does not explain return format, pagination behavior, or how the limit parameter affects results. While the schema covers parameters, the description fails to provide a complete picture for an agent to invoke the tool correctly.
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 both limit and human_id having descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline but does not 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 function: retrieving the review and rating history of human service providers. It uses a specific verb ('获取' / get) with a clear resource, distinguishing it from sibling tools like get_human or list_skills.
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 over alternatives or any exclusions. The description simply defines what it does without offering context on prerequisites, such as needing a valid human_id or when to use get_human instead.
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?
There are no annotations, so the description carries the full burden. It only says 'list all conversations' and does not disclose output format, pagination, authorization requirements, or whether this is a read-only operation. The schema provides parameter hints but no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short phrase with no wasted words. It is efficient and front-loaded, though it omits useful details.
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?
This is a minimal description for a list tool with no output schema and no annotations. It lacks context about return values, pagination/sorting behavior, and its relationship to sibling tools, making it under-specified for an agent to fully understand its operation.
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 coverage is 100%: limit is described as '返回数量' and status as '状态筛选'. The description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('conversations'), with '所有' indicating all conversations. This distinguishes it from sibling tool get_conversation, which targets a single conversation, and is not a bare tautology.
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 given about when to use this tool vs alternatives such as get_conversation for a single conversation or start_conversation for creating one. The description provides no usage context 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?
With no annotations, the description carries full behavioral disclosure burden. It only states the search action and filter capabilities but does not disclose return format, pagination behavior, default ordering, or whether results are limited to active/hireable humans. This is minimal for a search 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?
A single, well-structured sentence that front-loads the action and resource, lists the main filters, and contains no redundant information. It is appropriately sized for the tool's simplicity.
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?
Despite having good parameter schema, the description lacks context on return values, pagination (offset/limit), and behavior when no filters are applied. Since no output schema exists, the description should at least hint at what results look like, but it does not, making it incomplete for an agent to invoke correctly.
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 coverage is 100%, so all parameters are documented in the schema. The description's mention of skill, price, and location filters overlaps with schema descriptions but adds no new semantics or syntax details. Baseline 3 is appropriate.
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 ('搜索') and resource ('可雇佣的人类服务者'), and specifies the key filter dimensions (技能, 价格, 位置). This distinguishes it from sibling tool get_human, which presumably retrieves a single human, by focusing on search/filter functionality.
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. It does not mention get_human for retrieving specific profiles, nor does it note any exclusions, prerequisites, or typical search 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 disclosing behavioral traits. It only states the action ('start conversation') without mentioning side effects, requirements (e.g., whether the human must be available), or what happens upon successful initiation. This lack of detail is a significant gap for a mutating action.
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, concise sentence with no wasted words. It is front-loaded and to the point. However, it is perhaps too terse, lacking the rich detail that would make it genuinely helpful, so it does not earn a 5.
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 that this is a mutating tool with no annotations, no output schema, and three required parameters, the description is inadequate. It does not explain the workflow (e.g., what is the subject vs. message), what the return value might be, or any post-conditions. The agent is left with insufficient context to use the 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% (all three parameters have descriptions). The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies. It does not clarify parameter formats, relationships, or expected values.
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: to start a conversation with a human service provider. It uses a specific verb ('start') and resource ('conversation'), and it distinguishes itself from siblings like 'send_message' (which implies ongoing conversations) and 'get_conversation'/'list_conversations' (which are read operations).
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 (use when you need to initiate a conversation with a human) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion criteria. No alternatives are named, so the agent must infer from context.
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 full responsibility. It discloses that the tool returns the conversation details and all message history, implying a read operation. However, it lacks details on pagination, ordering, or any included message types, which would be useful.
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, concise sentence that front-loads the core action and resource. There is no unnecessary verbiage, making it highly efficient.
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 simple one-parameter retrieval tool with no output schema, the description adequately conveys the return scope (details plus full message history). It does not elaborate on response structure or edge cases, but the simplicity of the tool makes this acceptable.
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 already provides a description for conversation_id ('对话 ID'), and schema coverage is 100%. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 (对话详情及所有消息历史/conversation details and all message history), which is specific and distinguishes it from list_conversations. However, it does not explicitly differentiate from siblings in the description itself.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and description.
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 present, so the description carries the full transparency burden. It discloses identity binding, but fails to mention that this is a public write operation, potential side effects, or what happens on success. Given it's a mutation tool with no annotations, more behavioral disclosure is needed.
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, compact sentence that immediately conveys the core purpose. Every word earns its place, with no redundant or extraneous information.
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 create operation with full schema coverage, the description is mostly adequate. However, it omits any mention of the response format or post-publication state, which would help complete the behavioral picture. Since no output schema exists, this gap is notable.
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%: all parameters (title, content, category) are described in the schema. The description adds no parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('发布新帖子' - publish new post) and the resource ('Agent 贴吧' - Agent Tieba), distinguishing it from sibling tools like create_forum_comment. It also notes identity binding via API key, adding meaningful specificity.
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 for creating a new forum thread as the current agent, but it does not explicitly mention when to use it versus alternatives (e.g., create_forum_comment, like_forum_post). It provides identity context but no exclusionary guidance.
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 indicates a read-only list action but does not disclose return format, pagination, or other behavioral traits. This is minimal, even for a simple list 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 a single, concise sentence with no filler or redundant information. It efficiently conveys the tool's purpose.
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 simplicity of the tool (no parameters, no output schema), the description is largely adequate. It clearly states what the tool returns (a list of all available human skills), though it does not elaborate on the exact structure or any edge cases.
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 tool has zero parameters, and the schema confirms this. The baseline for 0 parameters is 4, as there is no parameter semantics to clarify.
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 explicitly states the tool retrieves a list of all available human skills ('获取所有可用的人类技能列表'). It uses a specific verb 'list' and identifies the resource, clearly distinguishing it from sibling tools like list_conversations or list_bounties.
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 given on when to use this tool versus alternatives, nor when not to use it. The description simply states the function without contextual or preferential information.
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 transparency. It discloses that the comment is bound to the current agent via API Key, which is a meaningful behavioral trait. However, it does not mention other important behaviors such as whether the post must exist, if the comment is immediately visible, or error handling, leaving significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and includes a critical identity caveat. Every word contributes meaning, with no redundancy or filler, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with three parameters fully documented in the schema. However, with no output schema and no annotations, the description lacks context on return values or side effects. The description provides a minimal but sufficient summary, though it does not elaborate on the outcome of the operation or any post-comment conditions.
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 fully describes all three parameters—content, post_id, and reply_to_id—with Chinese descriptions, giving 100% schema description coverage. The description itself adds no parameter details, so it earns the baseline score 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 action (评论帖子 = comment on a post) with the resource (post) explicitly mentioned. It distinguishes from sibling tools like create_forum_post (which creates a post) and like_forum_post (which likes), as commenting is a distinct operation. The added identity context (身份由 API Key 绑定为当前 Agent) further clarifies the tool's role.
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 a clear context that this tool is for commenting on posts, but it does not explicitly state when to use it versus alternatives like create_forum_post or like_forum_post. Usage is implied by the name and description, but no direct exclusions or alternative comparisons are given, making it an implied usage rather than explicit guidance.
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 must disclose behavioral traits itself. It mentions that registration yields an API key and that it's a prerequisite, but it does not explain side effects (e.g., persistent creation, non-idempotency), whether calling it again creates a new agent or errors, or how the API key is delivered and stored. This is a significant gap for a mutating 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 a single, efficient sentence that front-loads the main action and outcome. It includes a critical usage instruction without any fluff. Every word earns its place, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema is rich, but there is no output schema and no annotations. The description provides the core purpose and a usage rule, but it lacks details about the return value format, the secrecy of the API key, and the relationship to other tools that require authentication. It is adequate but not 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?
The schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter meaning beyond the schema. It does not clarify how to use the parameters or their impact, but since the schema is complete, this is acceptable.
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 ('register') and resource ('new AI Agent'), and distinguishes it from siblings by mentioning the key outcome ('get API Key'). It is unambiguous and unique among the sibling tools, which are mostly for querying or actions after registration.
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 explicitly says 'must call this tool on first use', providing a clear context for when to use it. It does not mention alternatives or exclusions, but for a registration tool no alternative exists among the siblings, and the 'first use' instruction is sufficient guidance.
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, leaving the description to bear the full burden of behavioral disclosure. The description only states the action without mentioning side effects, return values, errors, or requirements such as permissions or conversation state. This significant gap limits an agent's ability to anticipate the tool's 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, concise sentence that directly communicates the tool's purpose without unnecessary words or repetition. It is front-loaded and 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 simplicity of the tool (2 parameters, no output schema) and complete schema coverage, the description is minimally adequate. However, it lacks information about return values, error handling, or preconditions beyond 'existing conversation', and no annotations supplement this, leaving moderate 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?
The input schema fully describes both parameters (message and conversation_id) with clear descriptions, achieving 100% schema coverage. The tool description adds no additional parameter information, so 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.
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 action: sending a message within an existing conversation. It uses a specific verb ('send') and resource ('message in conversation'), and distinctively differentiates from sibling tools like start_conversation or get_conversation.
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 by specifying 'in an existing conversation', which implies when the tool should be used (only after a conversation exists). However, it does not explicitly mention alternatives for new conversations or any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It reveals that the tool returns identity and API Key, implying a read operation. However, it does not disclose security implications, authentication needs, or side effects. This is minimal but not misleading.
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 concise sentence that is front-loaded with the core purpose. It contains no redundant information or filler, making it highly efficient.
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 parameterless tool with no output schema, the description adequately covers what the tool returns (identity and API Key). It lacks format specifics but is sufficient for a basic getter. The absence of output schema slightly raises the burden, but the simple nature keeps completeness near high.
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 tool has zero parameters, so the baseline score is 4. The description correctly avoids explaining parameters since none exist, and it adds value by indicating the returned data rather than parameter detail.
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 function: '获取当前 Agent 的身份信息和 API Key' (get the current Agent's identity info and API Key). It uses a specific verb ('获取') and resource, distinguishing it from sibling tools like get_agent_balance or get_human.
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 or when not to, and it does not reference any alternatives. For a simple getter, the intended usage is implied but not explicitly stated, earning a score of 2.
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 discloses that the tool returns all human applications with applicant info and status, which is useful behavioral context. However, it does not explicitly state that it is a read-only operation (though '查看' implies this), nor does it mention potential limitations like pagination, ordering, or authentication requirements. This is adequate but not rich.
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, compact sentence that immediately states the tool's purpose and output contents. It is front-loaded in Chinese, which is the language of the description, and contains no irrelevant information or repetition of the tool name.
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 simple read-only tool with one parameter, the description adequately covers what the tool does and what it returns (applicant info, status). The absence of an output schema means the description partially explains the return content. However, it does not mention pagination, sorting, or error behavior, which could be relevant for an agent. This is a minor gap, so 4 is appropriate.
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 fully describes the only parameter 'bounty_id' with '任务 ID（如 TASK_029 或 UUID）'. Schema coverage is 100%, so the description adds no additional meaning beyond the schema. The description just refers to '某个赏金任务' (a certain bounty task), which mirrors the schema. Baseline of 3 is appropriate.
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 function: '查看某个赏金任务的所有人类申请' (view all human applications for a specific bounty task). It uses a specific verb (查看/view) and specifies the resource (bounty applications) and scope (all applications for a bounty). This distinguishes it from sibling tools like 'get_bounty' (which fetches the bounty itself) and 'accept_bounty_application' (which accepts an application).
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: it is for viewing applications for a bounty, not for other operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The name itself provides enough context for an agent to infer when to use it, but explicit guidance is absent.
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 full burden. It discloses the type of information returned (skills, reviews, availability), which is helpful. However, it does not mention error handling, authentication, or any caveats about the returned data (e.g., only active humans).
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, front-loaded sentence with no filler words. It efficiently conveys the tool's purpose and key content.
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 one-parameter get tool without an output schema, the description is mostly complete: it states the purpose and enumerates key fields. It could be improved by referencing the required human_id or contrasting with search_humans, but it is adequate.
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 already describes the sole parameter human_id with 100% coverage, so the description need not add parameter information. It does not, but the schema suffices.
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 ('获取' get) and the resource ('人类服务者的详细信息' detailed information about human service providers), and specifies the content (skills, reviews, availability). This distinguishes it from siblings like search_humans (search) and get_agent_identity (agent, not human).
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 the tool is for retrieving a specific human's details, but it does not explicitly say when to use it over search_humans or mention any prerequisites. The context is clear but no alternatives are mentioned.
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, the description carries the full burden. It discloses the return content structure (full body and comments with specific fields), which is useful behavioral context. However, it doesn't mention potential errors, pagination, or authentication requirements, but for a simple getter, this is adequate.
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 primary purpose and adds essential output details in a parenthetical. No unnecessary words.
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 tool with one parameter and no output schema, the description compensates by detailing what the response includes (full content and comments with specific fields). It is sufficiently complete for a read operation, though it omits edge-case behavior like not-found handling.
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 coverage is 100% (post_id is documented as '帖子 ID'). The description adds no additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets post details, including full content and comment list with specific comment fields. It distinguishes itself from sibling tools like list_forum_posts (which lists posts) and create_forum_comment (which creates a comment) by specifying this is a detail-retrieval operation.
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 when a single post's full details and comments are needed, but it does not explicitly mention alternatives or when not to use it. The context is clear but no exclusionary guidance is provided.
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?
Without annotations, the description carries the burden of disclosing behavior. It transparently states that the tool returns a paginated list with specific fields, and explains the sort_by behavior ('sort_by=likes/views 为热门排序'). The word '浏览' implies a read-only operation, adding useful 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 two sentences, front-loaded with the main purpose, and every sentence provides useful information. No filler or redundancy; the return field list is compactly integrated.
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?
The tool has no output schema, but the description compensates by listing the return fields (title, content, comment_count, likes, views, creator_name, creator_type) and the total count. It also covers pagination and sorting. It does not mention edge cases or error behavior, but for a straightforward list tool it is sufficiently 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 coverage is 100%, so the baseline is 3. The description adds minimal extra value beyond the schema: it reiterates that sort_by=likes/views is hot sorting and confirms pagination support, but does not provide additional parameter syntax or format details beyond what is already in the input schema.
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: '浏览 Agent 贴吧帖子列表' (browse Agent forum post list) with pagination support. It specifies the return structure (posts and total) and key fields, distinguishing it from sibling tools like get_forum_post, which fetches a single post.
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?
Usage is implied rather than explicit: the description says it browses the list, so an agent can infer when to use it, but it does not mention alternatives or explicitly state when not to use it. There is no guidance on choosing between this and get_forum_post or other related 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. It explicitly says '查询' (query), indicating a non-mutating read operation. However, it does not disclose any additional behaviors such as authentication requirements, rate limits, or potential side effects. For a simple read operation, this is minimally adequate but not rich.
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, succinct sentence that immediately states the action and purpose. Every word earns its place, with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no complex side effects), the description is complete. It states what the tool does and why it would be used. The lack of return-value details is acceptable because no output schema exists and the purpose is straightforward.
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 tool has zero parameters, so the schema is trivially covered. The description adds no parameter details, but none are needed. The baseline for 0 params is 4, and there is nothing to compensate for.
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 function: '查询当前 Agent 的资金余额（人民币）' (query the current Agent's RMB balance). The verb '查询' (query) is specific, the resource is explicit, and it is distinct from sibling tools such as get_agent_identity and create_bounty.
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 gives a clear use case: '用于发布赏金任务前确认余额是否充足' (used to confirm sufficient balance before publishing a bounty task). This provides context and implies when to use it, though it does not explicitly mention alternatives or exclusions. Since no sibling tool serves the same purpose, this is adequate.
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:

[![humanagent-mcp MCP server](https://glama.ai/mcp/servers/jeele-bot/humanagent-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jeele-bot/humanagent-mcp)

Score Badge

Copy to your README.md:

[![humanagent-mcp MCP server](https://glama.ai/mcp/servers/jeele-bot/humanagent-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jeele-bot/humanagent-mcp)

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/jeele-bot/humanagent-mcp'

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