Habitica MCP Server

Server Quality Checklist

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

Latest release: v0.0.5
Disambiguation4/5
Most tools have distinct purposes targeting specific Habitica resources like tasks, checklist items, pets, mounts, inventory, and user data. However, some potential overlap exists between 'score_task' and 'score_checklist_item' as both involve scoring/marking items, though they target different resource levels. Overall, the descriptions clearly differentiate the tools.
Naming Consistency3/5
The naming follows a mostly consistent verb_noun pattern (e.g., create_task, delete_task, get_tasks), but there is inconsistency in language with some tools in Chinese (e.g., '购买商店物品' for buy_item, '装备物品' for equip_item) and others in English. This mixed language usage reduces predictability and readability, though the verb_noun structure is generally maintained.
Tool Count3/5
With 26 tools, the count is on the higher side for an MCP server, bordering on heavy. While Habitica is a feature-rich platform with tasks, pets, mounts, inventory, and user management, the tool set might be slightly over-scoped, potentially leading to complexity for agents. It's not extreme, but it feels borderline for efficient use.
Completeness5/5
The tool set provides comprehensive coverage of Habitica's core domain, including full CRUD operations for tasks and checklist items, user profile and stats management, inventory and shop interactions, pet and mount handling, and notification management. There are no obvious gaps; agents can perform typical workflows like task creation, scoring, and resource management without dead ends.
Average 2.3/5 across 26 of 26 tools scored. Lowest: 1.7/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

Behavior1/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. 'Buy reward' implies a transactional mutation (likely spending resources), but the description does not specify costs, side effects (e.g., inventory changes), permissions required, or response format. This leaves critical behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise to the point of under-specification. 'Buy reward' is a two-word phrase that fails to convey necessary details, making it inefficient rather than succinct. It lacks structure and does not front-load critical information, requiring the agent to infer too much.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transactional tool with no annotations and no output schema, the description is severely incomplete. It does not explain what 'buying' involves (e.g., currency, success conditions), what happens post-purchase, or return values. This inadequacy hinders effective tool use by 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%, with the single parameter 'key' documented as 'Reward key or ID'. The description adds no additional meaning beyond this, such as examples of valid keys or where to find them. With high schema coverage, the baseline is 3, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Buy reward' is a tautology that restates the tool name without adding meaningful context. It specifies a verb ('Buy') and resource ('reward'), but lacks any elaboration on what 'buying' entails or what a 'reward' is in this system. Compared to siblings like 'buy_item' or 'get_shop', it fails to distinguish itself clearly, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description does not mention prerequisites (e.g., needing currency or specific conditions), exclusions, or related tools like 'buy_item' or 'get_shop'. Without any context, an agent cannot determine appropriate usage scenarios.
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 but provides none. 'Cast spell' doesn't indicate whether this is a read-only operation or has side effects, what permissions or resources are required, whether it consumes spell slots or mana, what happens on success/failure, or any rate limits. For a tool that presumably performs a magical action in a game system, this complete lack of behavioral information is severely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Cast spell' is certainly concise, it represents under-specification rather than effective brevity. The two-word description fails to provide the necessary information an AI agent needs to understand and use this tool appropriately. Every word should earn its place, but here the description is so minimal that it doesn't fulfill its basic purpose of explaining what the tool does beyond its name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by a spell-casting tool in what appears to be a game system, the description is completely inadequate. With no annotations, no output schema, and a minimal description that doesn't explain what casting actually does, what the expected outcomes are, or how this integrates with the broader game mechanics visible in sibling tools, this description fails to provide the contextual completeness needed for effective tool 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 schema has 100% description coverage, with both parameters documented in the schema itself. The description adds no additional information about what spellId represents (is it a spell name, code, or learned spell reference?) or what targetId is used for (creature, location, or self?). While the schema provides the baseline documentation, the description doesn't enhance understanding of parameter meaning or usage context beyond what's already in the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cast spell' is essentially a tautology that restates the tool name without adding meaningful context. While it identifies the action (cast) and resource (spell), it doesn't specify what casting a spell actually does in this system or how it differs from other magical actions that might exist. The description fails to distinguish this tool from potential alternatives like 'activate_spell' or 'invoke_spell' that might have different mechanics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like having the spell learned or sufficient mana), appropriate contexts (combat vs. utility), or what makes casting different from other magical actions. Given the sibling tools include various game mechanics like buying items, feeding pets, and scoring tasks, the description offers no help in determining when spell-casting is the appropriate choice.
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. 'Create new task' implies a write/mutation operation but reveals nothing about authentication requirements, rate limits, side effects, what happens on success/failure, or the response format. For a creation tool with zero annotation coverage, this is completely inadequate - it doesn't disclose any behavioral traits beyond the basic implication of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this represents under-specification rather than effective conciseness. The description doesn't earn its place - it provides minimal value beyond the tool name itself. Good conciseness balances brevity with information density, which this description fails to achieve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a creation/mutation tool with no annotations, no output schema, and 6 parameters (2 required), the description is completely inadequate. It doesn't explain what happens after creation, what the tool returns, error conditions, or any system context. For a tool that presumably modifies user data in a task management system, this level of documentation is insufficient for an AI agent to use it 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?
The schema description coverage is 100%, with all parameters well-documented in the schema itself (including enums for type, difficulty, and priority with clear value mappings). The description adds no parameter information beyond what's already in the schema. According to the rules, when schema coverage is high (>80%), the baseline score 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new task' is essentially a tautology that restates the tool name 'create_task' with minimal elaboration. While it does specify the verb 'create' and resource 'task', it lacks any distinguishing details about what kind of task system this is or how it differs from sibling tools like 'score_task' or 'update_task'. It meets the basic requirement of stating what the tool does but doesn't provide meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With sibling tools like 'create_tag', 'delete_task', 'update_task', and 'score_task', there's no indication of when creation is appropriate versus modification, deletion, or scoring. There's no mention of prerequisites, context, or any usage boundaries.
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 but offers none. 'Delete task' implies a destructive mutation, but the description doesn't disclose whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting related checklist items), or provides any confirmation. For a destructive operation with zero annotation coverage, this represents a critical safety gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with only two words, this description represents under-specification rather than effective brevity. Every sentence should earn its place, but here the minimal content fails to provide necessary information. The structure is front-loaded by default due to extreme brevity, but this doesn't compensate for the lack of substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations, no output schema, and 15 sibling tools including similar operations, the description is completely inadequate. It doesn't explain what happens upon deletion, whether the action is reversible, what permissions are required, or how it relates to other task management tools. The agent lacks essential context for safe and appropriate 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 schema description coverage is 100% with a single parameter 'taskId' documented as 'Task ID'. The description adds no parameter information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter details in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete task' is a tautology that merely restates the tool name without adding any meaningful context. It specifies the verb ('Delete') and resource ('task'), but fails to distinguish this tool from siblings like 'delete_checklist_item' or provide any additional purpose information. This minimal description offers no differentiation or clarification beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., task must exist), exclusions (e.g., cannot delete completed tasks), or relationships to sibling tools like 'delete_checklist_item' or 'update_task'. The agent receives zero contextual direction for tool selection.
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 but fails completely. It doesn't indicate whether this is a read or write operation, what permissions are required, whether it's destructive, what happens to previously equipped items, or what the expected outcome is. The single Chinese phrase offers no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two Chinese characters, this represents severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an AI agent understand or use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'equipping' means in this context, what happens when items are equipped, how this affects game state, or what the tool returns. The lack of any meaningful description leaves critical gaps for agent 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?
Schema description coverage is 100%, with both parameters documented in the schema itself. The description adds zero additional information about parameter meaning, usage, or relationships. However, with complete schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '装备物品' (equip item) is a tautology that merely restates the tool name in Chinese without adding any meaningful context. It doesn't specify what 'equipping' means in this system, what resource is being acted upon, or how this differs from sibling tools like 'feed_pet' or 'cast_spell'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or relationships to sibling tools like 'get_inventory', 'get_mounts', or 'get_pets' that might provide items to equip.
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 full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a mutation operation, what permissions might be required, whether changes are reversible, or what side effects might occur. The description fails to provide any behavioral context beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this is under-specification rather than effective brevity. The description fails to provide necessary information that would help an AI agent understand and use the tool correctly, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool actually does, when to use it, what behavior to expect, or what the result might look like. The minimal description fails to compensate for the lack of structured metadata.
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 all 4 parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update checklist item' is a tautology that restates the tool name without adding any meaningful detail. It doesn't specify what aspects can be updated or distinguish this tool from sibling tools like 'score_checklist_item' or 'delete_checklist_item' that also operate on checklist items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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's no mention of prerequisites, appropriate contexts, or distinctions from related tools like 'score_checklist_item' or 'update_task' that might handle similar operations.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Update task' implies a mutation operation but reveals nothing about permissions, side effects, error conditions, or response format. It doesn't indicate whether updates are partial or complete, if changes are reversible, or what happens to unspecified fields. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Update task' is technically concise, it represents under-specification rather than effective brevity. The description is too minimal to be helpful, failing to convey essential information that would justify its existence. A single word doesn't constitute appropriate structure or front-loading of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 is completely inadequate. It doesn't explain what 'update' entails, what fields are modifiable, what the tool returns, or how it differs from other task-related tools. Given the complexity of task management in this context and the lack of structured metadata, the description fails to provide necessary context for effective tool 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%, with all four parameters clearly documented in the input schema (taskId, text, notes, completed). The description adds no parameter information beyond what the schema provides, so it neither compensates for gaps nor enhances understanding. This meets the baseline score 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update task' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what aspects of a task can be updated or distinguish this tool from sibling tools like 'update_checklist_item' or 'score_task'. While the verb 'update' is clear, the description fails to elaborate on the resource or scope beyond the minimal name restatement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 existing task ID), compare it to related tools like 'create_task' or 'delete_task', or indicate appropriate contexts. With multiple sibling tools for task management, this lack of differentiation leaves the agent without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete checklist item' implies a destructive mutation, but it doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., affecting task completion), or what happens on success/failure. The description is minimal and fails to address critical behavioral aspects for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase 'Delete checklist item', which is overly concise to the point of under-specification. While it avoids waste, it lacks necessary structure (e.g., not front-loading key details) and fails to convey essential information, making it inefficient for an agent's understanding.
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's complexity (a destructive mutation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'delete' entails (e.g., permanent removal, effects on task status), return values, or error conditions. For a deletion tool in a system with multiple checklist-related siblings, more context is needed to ensure safe and correct usage.
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 description adds no parameter semantics beyond what the input schema provides. However, schema description coverage is 100%, with clear descriptions for 'taskId' and 'itemId', so the baseline score is 3. The description doesn't compensate or add value, but the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete checklist item' is a tautology that merely restates the tool name without adding specificity. It doesn't clarify what resource is being deleted (e.g., from which system or context) or distinguish it from sibling tools like 'delete_task' or 'update_checklist_item'. While the verb 'delete' is clear, the description lacks meaningful elaboration beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 a task ID and item ID), exclusions, or relationships to sibling tools like 'update_checklist_item' or 'score_checklist_item'. Without any context, an agent must infer usage solely from the name and schema.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get inventory' implies a read operation but reveals nothing about permissions, rate limits, data format, pagination, or error conditions. For a tool with zero annotation coverage, this description is completely inadequate in describing 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Get inventory' is technically concise, it's under-specified rather than appropriately concise. The two words fail to provide essential context about what inventory means in this system. Conciseness should not come at the expense of clarity—this description is too brief to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the description's extreme brevity, this is completely inadequate. The description doesn't explain what 'inventory' encompasses in this context (items, pets, mounts, etc.), what format the data returns, or any behavioral aspects. For a tool in a system with many similar retrieval tools, this description provides insufficient context.
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% description coverage, meaning the schema fully documents that no parameters are required. The description doesn't need to add parameter semantics since there are none to explain. A baseline score of 4 is appropriate as the description doesn't contradict the schema (which shows no parameters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get inventory' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what inventory is being retrieved (e.g., user inventory, shop inventory, game inventory) or what resources are included. While it uses a clear verb ('Get'), it lacks the specificity needed to distinguish this tool from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. Given the numerous sibling tools (e.g., get_shop, get_pets, get_stats, get_tasks), there's no indication whether this tool retrieves a comprehensive inventory or a specific subset. No prerequisites, exclusions, or comparative context are mentioned.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create tag' implies a write operation but offers no details about permissions, side effects, error conditions, or response format. This is inadequate for a mutation tool with zero annotation 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 extremely concise with just two words, making it front-loaded and free of unnecessary information. However, this brevity comes at the cost of clarity and completeness, though it technically earns full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a mutation tool. It fails to explain what a tag is, how creation works, what happens on success or failure, or any behavioral traits, leaving critical gaps for agent 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?
Schema description coverage is 100%, with the single parameter 'name' documented as 'Tag name'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create tag' is a tautology that merely restates the tool name without adding meaningful context. It specifies the verb 'create' and resource 'tag' but lacks any distinguishing details about what a tag represents in this system or how it differs from similar tools like 'get_tags'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, appropriate contexts, or exclusions, leaving the agent with no information about when this tool is applicable compared to sibling tools like 'get_tags' or 'create_task'.
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 full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation (likely a mutation based on context), what permissions are required, whether it's destructive, what happens on success/failure, or any rate limits. The single phrase provides zero behavioral context beyond the basic action.
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 at just two Chinese characters ('孵化宠物'), which directly conveys the core action. There's no wasted language or unnecessary elaboration. While it's arguably too brief for completeness, as a standalone phrase it's efficiently structured with zero redundancy.
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 this is a mutation tool (implied by 'hatching') with no annotations and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, what happens to the egg and potion after hatching, error conditions, or relationship to other pet-related tools. The two-character phrase is inadequate for the complexity of a tool that transforms inventory items into pets.
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 parameters ('egg' and 'hatchingPotion') documented in the schema as requiring string keys. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '孵化宠物' (hatch pet) is a tautology that essentially restates the tool name 'hatch_pet' in Chinese. While it indicates the action (hatching) and target (pet), it doesn't specify what resources are involved or distinguish this from sibling tools like 'feed_pet' or 'get_pets'. The purpose is recognizable but lacks specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 are no indications of prerequisites (e.g., needing an egg or potion first), no mention of when-not-to-use scenarios, and no reference to related tools like 'get_inventory' or 'get_pets' that might be needed beforehand. Usage context is completely absent.
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 for behavioral disclosure but offers minimal insight. 'Score' implies a mutation (likely updating a score value), but the description doesn't specify what scoring does (e.g., affects user stats, triggers rewards), whether it's reversible, or any side effects. It mentions 'habits only' for the direction parameter but doesn't explain why or the broader behavioral impact.
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 extremely concise ('Score task / habit') but under-specified rather than efficiently informative. While it avoids unnecessary words, it fails to provide essential context that would help an agent understand the tool's purpose and usage, making it more of a placeholder than a helpful description.
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, no output schema, and a mutation tool with potential complexity (scoring tasks/habits), the description is incomplete. It doesn't explain what scoring entails, the expected outcomes, or how it integrates with other tools like 'get_stats' or 'get_tasks'. For a tool that likely affects user progress or rewards, more context is needed.
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 (taskId and direction with enum values). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the scoring mechanism or how direction applies differently to tasks vs. habits. Baseline 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Score task / habit' is a tautology that essentially restates the tool name 'score_task' without adding meaningful specificity. It mentions both 'task' and 'habit' but doesn't clarify what 'scoring' means operationally or how it differs from similar tools like 'score_checklist_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, appropriate contexts, or exclusions, and fails to differentiate it from sibling tools like 'score_checklist_item' or 'update_task' despite the server having multiple task-related 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. 'Get user stats' implies a read operation but doesn't specify what stats are included, how data is formatted, or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool with no structured safety hints.
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 phrase, 'Get user stats', which is concise but under-specified rather than efficiently informative. It lacks structure or front-loading of key details, making it too brief to be helpful beyond the name.
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, no output schema, and low complexity (0 parameters), the description is incomplete. It doesn't explain what 'user stats' entails, the return format, or behavioral traits, leaving the agent 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.
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 doesn't add parameter details, but that's appropriate here, as the schema fully handles the absence of inputs, justifying a baseline score above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user stats' restates the tool name 'get_stats' with minimal elaboration, making it a tautology. It specifies the resource ('user stats') but lacks a clear verb beyond 'get' and doesn't differentiate from sibling tools like 'get_user_profile' or 'get_inventory', leaving the scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 doesn't mention context, prerequisites, or exclusions, and with siblings like 'get_user_profile' that might overlap, the agent has no basis for choosing between them.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get tasks list' only indicates a read operation without details on permissions, rate limits, pagination, or response format. This is inadequate for a tool with no annotation coverage, failing to disclose essential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Get tasks list', which is front-loaded and wastes no words. However, it is under-specified rather than efficiently informative, slightly reducing its effectiveness, but it earns credit for brevity and clarity in its minimal form.
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 lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., task details, list format) or behavioral aspects like error handling. For a tool with no structured data support, this leaves significant gaps in understanding its full context and usage.
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 'type' documented as 'Task type' and an enum list. The description adds no parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting, but does not compensate or add extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tasks list' restates the tool name 'get_tasks' with minimal elaboration, making it tautological. It specifies the verb 'Get' and resource 'tasks list' but lacks detail on scope or differentiation from sibling tools like 'get_task_checklist' or 'get_stats', which also retrieve task-related data.
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. For example, it does not clarify if this is for general task listing versus specific operations like 'get_task_checklist' for checklist details or 'get_stats' for task statistics, leaving usage context implied at best.
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 the full burden of behavioral disclosure. 'Get user profile' implies a read operation but doesn't specify whether this requires authentication, what data format is returned, whether it's cached or real-time, or if there are rate limits. For a tool with zero annotation coverage, this minimal description leaves significant behavioral questions unanswered.
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 extremely concise at just three words, but this borders on under-specification rather than effective brevity. While it's front-loaded with the core action, it lacks the additional context needed for a tool in a complex system with many sibling tools. The conciseness comes at the cost of completeness.
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 the system (24 sibling tools including various get operations) and the absence of both annotations and an output schema, the description is insufficiently complete. It doesn't explain what a 'user profile' contains, how it differs from other user data tools, or what format the return data takes. For a tool in this rich context with no structured metadata, more descriptive content is needed.
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 description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. A baseline of 4 is appropriate since there are no parameters requiring semantic explanation beyond what the schema already provides (which is none).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user profile' is a tautology that restates the tool name without adding meaningful specificity. It doesn't distinguish this tool from sibling tools like 'get_stats' or 'get_inventory' that also retrieve user data. While it indicates a read operation on user profile data, it lacks detail about what constitutes a 'profile' in this context.
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. With sibling tools like 'get_stats' and 'get_inventory' that also retrieve user information, there's no indication of what distinguishes a 'profile' from 'stats' or other data types. No context about prerequisites, timing, or exclusions is provided.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. '喂养宠物' implies a mutation (feeding likely consumes food or changes pet state), but it doesn't specify effects (e.g., does it reduce inventory, affect pet stats, have cooldowns, or require permissions). This is inadequate for a tool with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('喂养宠物'), which is maximally concise and front-loaded. There's no wasted verbiage, making it efficient for quick understanding, though it lacks depth.
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 (a mutation tool with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral traits, usage context, or output expectations, leaving significant gaps for an AI agent to infer how and when to invoke it 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 parameters ('pet' and 'food') documented as keys. The description adds no meaning beyond the schema, not explaining what valid keys are or how they relate (e.g., if 'food' must be compatible with 'pet'). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '喂养宠物' (feed pet) states a clear verb and resource, but it's vague about what feeding entails in this system. It doesn't distinguish from siblings like 'hatch_pet' or 'buy_item' (which might involve food purchases), leaving ambiguity about whether this is a consumption action, a status update, or something else.
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. With siblings like 'hatch_pet', 'get_pets', and 'buy_item', it's unclear if feeding requires prior steps (e.g., owning a pet, having food in inventory) or if it's a standalone action. The description offers no context for usage.
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 implies a mutation (scoring/marking), but doesn't specify whether this is a toggle, requires permissions, has side effects (e.g., affecting task completion), or what the response looks like. For a mutation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single phrase, making it front-loaded and efficient. However, it borders on under-specification, as it could benefit from slightly more detail to clarify the action without becoming verbose.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., how scoring works, error conditions), doesn't explain return values, and provides minimal context beyond the basic action, making it inadequate for full agent 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 clear descriptions for 'taskId' and 'itemId' in the input schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or relationships between parameters. Given the high schema coverage, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Score checklist item (mark complete/incomplete)' states the action (score/mark) and target (checklist item), which clarifies the basic purpose. However, it's somewhat vague about what 'score' specifically means in this context (e.g., is it toggling status, setting a specific value?), and it doesn't distinguish this tool from sibling tools like 'score_task' or 'update_checklist_item', which might have overlapping 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing checklist item), exclusions, or how it differs from similar tools like 'score_task' or 'update_checklist_item', leaving the agent to infer usage from the name 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 for behavioral disclosure. It states the action is a purchase but doesn't cover critical aspects like whether it deducts currency, requires authentication, has rate limits, or what happens on failure. This is a significant gap for a transactional 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 phrase with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 a purchase transaction with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error handling, and how it integrates with sibling tools like 'get_shop' or 'get_inventory', leaving the agent under-informed.
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 ('itemKey' and 'quantity'). The description adds no additional meaning beyond what the schema provides, such as explaining what 'itemKey' refers to or valid quantity ranges, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '购买商店物品' (buy store items) states a clear verb+resource action, indicating the tool purchases items from a store. However, it doesn't distinguish from sibling tools like 'buy_reward' or specify what types of items are available, leaving the purpose somewhat vague.
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., having sufficient currency), exclusions, or how it differs from similar tools like 'buy_reward', leaving the agent with no usage context.
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 only states the action ('get shop items') without details on permissions, rate limits, response format, or whether it's read-only or has side effects. For a tool with no annotation coverage, 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 a single phrase ('获取商店物品'), which is extremely concise and front-loaded with the core action. There is no wasted verbiage or unnecessary elaboration, making it efficient for quick understanding.
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's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks context on what 'shop items' includes (e.g., prices, availability), how results are returned, or any behavioral traits. Without annotations or output schema, the description should provide more detail 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 single parameter 'shopType' documented as '商店类型' (shop type) and an enum list. The description adds no additional meaning beyond this, such as explaining what each shop type entails or how it affects results. With high schema coverage, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取商店物品' translates to 'get shop items', which states the verb ('get') and resource ('shop items'), providing a basic purpose. However, it's vague about scope (e.g., all items or filtered) and doesn't distinguish from siblings like 'get_inventory' or 'buy_item', which involve similar resources. It avoids tautology by not merely restating the name 'get_shop'.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention context like retrieving items for purchase vs. viewing inventory, nor does it reference siblings such as 'get_inventory' or 'buy_item' for comparison. This leaves the agent without explicit or implied usage rules.
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. 'Get' implies a read operation, but the description doesn't disclose any behavioral traits - no information about permissions needed, rate limits, what happens if the taskId doesn't exist, or the format/structure of returned checklist items. For a tool with zero annotation coverage, this is insufficient.
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 at just 4 words, front-loaded with the core purpose. There's zero wasted language or redundancy. Every word earns its place in conveying the basic 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 no annotations, no output schema, and a read operation that likely returns structured data, the description is incomplete. It doesn't help the agent understand what will be returned (checklist item details, completion status, etc.) or any constraints on the retrieval. For a tool in a system with many related operations, more context is needed.
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% (taskId parameter is fully documented in schema), so the baseline is 3. The description adds no additional parameter information beyond what the schema already provides about the single required taskId parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get task checklist items' clearly states the action (get) and resource (task checklist items), but it's vague about scope - it doesn't specify if this retrieves all items for a task or has other limitations. It distinguishes from siblings like 'get_tasks' but not clearly from 'score_checklist_item' or 'update_checklist_item' which also involve checklist items.
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. The description doesn't mention prerequisites, context, or exclusions. With siblings like 'get_tasks' and various checklist manipulation tools, the agent receives no help in selecting this specific retrieval function.
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 only states the action ('获取通知列表') without mentioning any traits like permissions needed, pagination, rate limits, or what the return format might be (e.g., list structure, fields included). This leaves significant gaps for a tool that likely returns data.
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 phrase ('获取通知列表'), which is very concise and front-loaded with the core action. It wastes no words, though it could benefit from slightly more detail without losing efficiency. This earns a high score for brevity and clarity in structure.
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 (a data retrieval tool with no parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., notification objects, fields, or how to handle results), which is critical for an agent to use it effectively. More context is needed to bridge these 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's acceptable here. A baseline of 4 is appropriate as the schema fully handles the parameter aspect, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取通知列表' (Get notification list) states a clear verb ('获取' - get) and resource ('通知列表' - notification list), providing basic purpose. However, it lacks specificity about scope (e.g., unread/all, user-specific) and doesn't distinguish from the sibling 'read_notification' tool, which suggests a more targeted operation. This makes it vague in context.
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. For example, it doesn't clarify if this is for listing all notifications versus unread ones, or how it relates to 'read_notification' (which might mark notifications as read). Without such context, the agent has minimal direction on appropriate usage.
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 for behavioral disclosure. 'Get tags list' implies a read-only operation, but it doesn't specify whether this requires authentication, what format the list returns, if there are rate limits, or any error conditions. For a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get tags list' is extremely concise at three words, with zero wasted language. It's front-loaded with the core action. However, it borders on under-specification given the lack of context about what 'tags' are, which slightly reduces its effectiveness despite the brevity.
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 (simple read operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what 'tags' are in this system, what the return format looks like, or any behavioral aspects. For a tool with no structured data beyond an empty input schema, 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since there's no parameter information to provide beyond what the empty schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tags list' states the basic action (get) and resource (tags list), making the purpose understandable. However, it's vague about what 'tags' refer to in this context and doesn't differentiate from sibling tools like 'create_tag' beyond the verb difference. It lacks specificity about what kind of tags or what system they belong to.
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 any prerequisites, context for usage, or relationship to sibling tools like 'create_tag' or 'get_tasks'. The agent must infer usage purely from the tool name and description without any explicit direction.
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 for behavioral disclosure. It states the tool performs an addition operation, implying a write/mutation, but doesn't disclose any behavioral traits such as permissions required, whether it's idempotent, error conditions, or what happens on success (e.g., returns the new item ID). 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 extremely concise at just four words, front-loading the core action and target without any wasted words. Every element ('Add', 'checklist item', 'to task') earns its place by defining the tool's scope. It could benefit from more detail, but as-is, it's perfectly structured for brevity.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral nuances. While the purpose is clear, the lack of context for usage, parameters, and outcomes makes it inadequate for safe and 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?
The input schema has 100% description coverage, with both parameters ('taskId' and 'text') clearly documented in the schema. The description adds no additional meaning about parameters beyond what the schema already provides (e.g., no examples, formatting hints, or constraints). According to the 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('checklist item to task'), making the purpose immediately understandable. It distinguishes from sibling tools like 'delete_checklist_item' and 'update_checklist_item' by specifying the creation operation. However, it doesn't explicitly mention what type of checklist item is being added (e.g., to a task management system), which prevents 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 existing task), when not to use it (e.g., for updating existing items), or refer to related tools like 'get_task_checklist' for context. The agent must infer usage from the tool name 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list but doesn't describe the return format (e.g., array of mount objects), pagination behavior, error conditions, or whether it requires authentication. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 phrase ('获取坐骑列表') that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise for a simple tool.
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's simplicity (0 parameters) and lack of annotations or output schema, the description is minimally complete but inadequate. It doesn't explain what the list contains (e.g., mount names, stats, or IDs), how it's structured, or any behavioral traits. For a tool in a context with many sibling 'get' operations, more differentiation or detail would be helpful.
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 doesn't add parameter information, which is appropriate here. A baseline of 4 is given because the schema fully covers the lack of parameters, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取坐骑列表' (Get mounts list) states a clear verb ('get') and resource ('mounts list'), making the basic purpose understandable. However, it doesn't distinguish this tool from similar sibling tools like 'get_inventory', 'get_pets', or 'get_tasks', which all follow the same 'get [resource]' pattern without clarifying what makes mounts unique.
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 user must own mounts), exclusions (e.g., if it only shows equipped mounts), or relationships to sibling tools like 'get_inventory' (which might include mounts) or 'equip_item' (which might modify mounts).
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. The description only states what the tool does ('get pet list') without mentioning any behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, 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 extremely concise ('获取宠物列表')—just three characters in Chinese. It's front-loaded with the core purpose and has zero wasted words. For a simple tool with no parameters, this level of brevity is appropriate and efficient.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list format, pet attributes), any prerequisites, or error conditions. For a tool with no structured metadata, the description should provide more context to be fully helpful to an AI agent.
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, meaning there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate for tools with no parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取宠物列表' (Get pet list) clearly states the verb ('get') and resource ('pet list'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'get_inventory', 'get_mounts', or 'get_stats', which all follow similar 'get [resource]' patterns. The purpose is clear but lacks 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 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 are multiple sibling 'get' tools (e.g., get_inventory, get_mounts, get_stats), but the description doesn't explain what makes 'get_pets' distinct or when it should be preferred. No usage context or exclusions are mentioned.
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 implies a mutation ('mark as read') but doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, what happens on success/failure, or side effects. For a mutation tool with zero annotation coverage, 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 a single, efficient phrase in Chinese that directly states the action. It's front-loaded with zero waste, making it highly concise and well-structured for its purpose, though it could benefit from additional context.
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's mutation nature, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'marking as read' entails (e.g., updates a status, returns confirmation), potential errors, or how it interacts with sibling tools like 'get_notifications'. For a tool that modifies state, more context is needed.
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?
Schema description coverage is 100%, with the single parameter 'notificationId' well-documented in the schema. The description doesn't add any parameter details beyond the schema, but with 0 parameters needing extra explanation (since schema covers it fully), a baseline of 4 is appropriate as it doesn't detract from understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '标记通知为已读' (Mark notification as read) states a clear verb ('mark as read') and resource ('notification'), but it's vague about scope and doesn't distinguish from sibling tools like 'get_notifications'. It specifies what the tool does but lacks precision about which notifications it affects or how it differs from 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 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 a notification ID from 'get_notifications'), exclusions, or comparisons to sibling tools. Without such context, the agent must infer usage from the tool name alone.
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:

[![habitica-mcp-server MCP server](https://glama.ai/mcp/servers/iBreaker/habitica-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/iBreaker/habitica-mcp-server)

Score Badge

Copy to your README.md:

[![habitica-mcp-server MCP server](https://glama.ai/mcp/servers/iBreaker/habitica-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/iBreaker/habitica-mcp-server)

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/iBreaker/habitica-mcp-server'

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