PlanManager MCP Server

by Danson-dan

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
There is significant overlap between tools like create_plan, create_plan_batch, create_study_plan, create_travel_plan, and guided_plan_creation, which all create plans with varying approaches. However, descriptions help clarify distinctions (e.g., batch creation vs. guided creation), and tools like backup_plans or fix_old_dates have unique purposes, preventing complete confusion.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_plan, delete_plan, update_plan_status), with clear actions and targets. Minor deviations exist, such as backup_plans (noun_verb) and get_operation_logs (get_noun_noun), but the overall naming is predictable and readable.
Tool Count3/5
With 20 tools, the count feels heavy for a plan management server, bordering on excessive. While the domain supports many operations, some tools (e.g., create_plan_batch vs. guided_plan_creation) could be consolidated, making the set feel slightly bloated rather than well-scoped.
Completeness5/5
The tool set provides comprehensive coverage for plan management, including CRUD operations (create, get, update, delete), specialized templates (study, travel), batch and guided creation, status updates, rescheduling, search, statistics, logs, backups, and validation. No obvious gaps exist for core workflows in this domain.
Average 3.1/5 across 20 of 20 tools scored. Lowest: 2.3/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('get') without detailing traits like whether it's read-only (implied but not explicit), performance considerations, error handling, or output format. For a tool with no annotations, this minimal description fails to provide necessary behavioral context, though it doesn't contradict any annotations.
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 ('获取计划统计信息'), consisting of a single phrase. While it avoids waste, it is under-specified rather than efficiently informative. It lacks front-loaded detail that could clarify purpose or usage, making it too brief to be optimally helpful, though not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's minimalism is partially mitigated. However, for a tool with no annotations and siblings that may overlap, the description should do more to explain what statistics are retrieved and how this differs from other tools. It is minimally viable but leaves gaps in contextual understanding.
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%, meaning the schema fully documents the lack of inputs. The description does not add parameter-specific information, which is unnecessary here. A baseline of 4 is appropriate as the schema adequately handles the parameter semantics for a parameterless tool.
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 plan statistics) states a general purpose but is vague. It specifies the resource ('plan statistics') but lacks detail about what statistics are retrieved (e.g., counts, metrics, trends) or scope (e.g., all plans, recent plans). It does not distinguish from siblings like 'get_plan_details' or 'list_plans', which might provide overlapping or related information.
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. With siblings such as 'get_plan_details' (for specific plan info), 'list_plans' (for plan listings), and 'get_operation_logs' (for logs), there is no indication of context, prerequisites, or exclusions. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions searching by name or description but doesn't disclose behavioral traits such as whether it's read-only, how results are returned (e.g., pagination, sorting), or any limitations like rate limits or authentication needs, which are critical for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by a simple Args section. It avoids unnecessary words, but the structure could be improved by integrating the parameter info more seamlessly rather than as a separate list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations and low schema coverage, it lacks context on behavior, usage, and parameter details. For a simple search tool, it's minimally adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that 'keyword' is a search term for name or description, which provides basic meaning beyond the schema's title 'Keyword'. However, with 1 parameter and no details on format, constraints, or examples, it doesn't fully compensate for the low 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 states the tool searches plans by name or description, which is a clear purpose. However, it doesn't distinguish itself from sibling tools like 'list_plans' or 'get_plan_details' that might also retrieve plan information, making it somewhat vague in comparison.
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 'list_plans' and 'get_plan_details', the description lacks context on whether this is for fuzzy matching, filtering, or specific use cases, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieving logs but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, what format the logs are in, or if there are rate limits. The description is minimal and lacks essential context for a logging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and another explaining the parameter. It's front-loaded with the main function. However, the structure could be improved by separating the purpose from parameter details more clearly, and it's slightly terse for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations and minimal parameter coverage, it's incomplete for a logging tool that might involve sensitive data or complex behavior. It covers the basics but lacks depth in usage context and behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'limit' parameter by explaining it controls the number of recent log entries to display and provides a default value (20). However, with 0% schema description coverage and only 1 parameter documented, this is adequate but not comprehensive. It compensates somewhat for the schema gap but doesn't cover other potential aspects like filtering or sorting.
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 states the tool '获取操作日志记录' (get operation log records), which is a clear verb+resource combination. However, it doesn't distinguish this from potential sibling tools like 'get_plan_details' or 'get_plan_statistics' that might also retrieve data. The purpose is understandable 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. It doesn't mention context like whether this is for auditing, debugging, or monitoring, nor does it reference sibling tools. There's no indication of prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions a 'step-by-step' process but does not disclose behavioral traits like whether it's interactive, requires user input during execution, modifies data, has side effects, or handles errors. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by parameter details. It avoids unnecessary elaboration, though the parameter section could be more integrated. Overall, it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values. However, with no annotations, 1 parameter at 0% schema coverage, and multiple sibling tools, the description is incomplete—it lacks details on behavior, differentiation, and full parameter context, making it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists 'plan_type' with enum values, adding meaning beyond the input schema which has 0% description coverage and only defines the parameter type. However, it does not explain what each plan type entails or how it affects the creation process, providing only basic semantic clarification.
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 states the tool '一步步帮助用户创建完整计划' (step-by-step helps users create complete plans), which provides a vague purpose without specifying what resources it operates on or how it differs from sibling tools like 'create_plan' or 'create_study_plan'. It mentions '引导式创建计划' (guided plan creation) but lacks specificity about the mechanism or outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'create_plan' or 'create_study_plan'. The description implies a step-by-step process but does not specify contexts, prerequisites, or exclusions, leaving the agent without clear usage instructions.
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 states 'Add a step' which implies a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether changes are reversible, rate limits, or what happens on success/failure. The description adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear opening sentence followed by parameter explanations. Every sentence earns its place by defining the tool and its parameters. However, the parameter explanations are in a different language (Chinese) which may affect clarity in some contexts, and the structure could be more front-loaded with key usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers all parameters semantically but lacks behavioral context for a mutation tool. The output schema reduces need to explain return values, but more guidance on usage and error handling would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all 5 parameters with brief explanations in Chinese, adding meaning beyond the schema's titles (e.g., '父计划的id' clarifies plan_id is for parent plans, '何时应该完成此步骤' explains scheduled_at timing). However, it doesn't provide format details (e.g., ISO 8601 for scheduled_at is only in schema title) or usage examples, leaving gaps.
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 a step') and the target resource ('to an existing plan'), specifying it's a sub-task. It distinguishes from siblings like 'create_plan' by focusing on adding to existing plans rather than creating new ones. However, it doesn't explicitly differentiate from tools like 'update_plan_status' that might also modify plans.
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., plan must exist), exclusions, or compare to sibling tools like 'create_plan_batch' or 'guided_plan_creation'. Usage is implied by the action but lacks explicit 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 full burden. It states 'create' which implies a write/mutation operation, but doesn't disclose any behavioral traits: no information about permissions needed, whether creation is reversible, what happens on success/failure, rate limits, or what the created template includes beyond the input parameters. The description is minimal and lacks crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by parameter documentation. The structure with 'Args:' section organizes parameter information efficiently. No unnecessary verbiage, though the parameter explanations could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and no annotations, the description is moderately complete for a creation tool. It covers the basic purpose and parameters but lacks important context: no behavioral transparency, no usage guidelines compared to siblings, and incomplete parameter semantics. For a 5-parameter creation tool with 0% schema coverage, this is the minimum viable level.
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 0%, so the description must compensate. It provides parameter names and brief examples/format hints in Chinese (e.g., '云南' for destination, 'YYYY-MM-DD' for dates), which adds some semantic value beyond the bare schema. However, it doesn't explain the meaning of 'budget' (currency? per person/total?) or 'description' (what should it contain?), leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '快速创建旅行计划模板' (quickly create travel plan template). It specifies the verb 'create' and the resource 'travel plan template', making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'create_plan' or 'guided_plan_creation', which appear to serve similar functions.
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 multiple sibling tools like 'create_plan', 'guided_plan_creation', and 'create_plan_batch', there's no indication of when this specific 'create_travel_plan' tool is preferred, what distinguishes it, or any prerequisites 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions '级联删除所有子计划' (cascading deletion of all sub-plans), which is valuable behavioral information about destructive side effects. However, it doesn't disclose other critical behaviors: whether deletion is permanent/reversible, what permissions are required, error conditions, or what the output contains. For a destructive operation 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 - just 7 Chinese characters that convey the core action and key behavioral trait (cascading deletion). Every word earns its place with no wasted text. It's front-loaded with the primary action followed by the important qualification.
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 destructive mutation tool with no annotations, the description is incomplete. While it mentions cascading deletion (important context), it doesn't address critical aspects: confirmation requirements, permanence of deletion, error handling, or what the output schema contains. The existence of sibling tools like 'preview_delete_plan' suggests there might be a safer alternative, but the description provides no guidance on this.
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 schema has 0% description coverage (no parameter descriptions in schema), but the tool has only 1 parameter. The description doesn't explicitly mention the 'plan_id' parameter, but the cascading deletion context implies it operates on a specific plan. Since there's only one parameter and the schema clearly defines it as a required integer, the description doesn't need extensive parameter explanation. A baseline of 4 is appropriate for single-parameter tools.
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 states the action ('删除计划' meaning 'delete plan') which is a clear verb+resource combination. However, it doesn't distinguish this tool from its sibling 'delete_plan_by_name' - both appear to delete plans but using different identifiers. The description is vague about what type of plan is being deleted or what system this operates in.
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 like 'delete_plan_by_name', 'cancel_travel_plan', or 'preview_delete_plan'. There's no mention of prerequisites, conditions for use, or comparison with sibling tools. The only implicit guidance is that it requires a plan_id parameter.
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. While 'Update' implies a mutation, the description doesn't address critical behavioral aspects like whether this requires specific permissions, whether status changes are reversible, what happens to associated steps when a plan status changes, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences: a clear purpose statement followed by parameter documentation. The structure is front-loaded with the core functionality. The only minor inefficiency is the slightly vague 'item' reference in the plan_id description instead of being more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values) and only 2 parameters with basic schema coverage, the description provides the minimum viable context. However, as a mutation tool with no annotations, it should ideally address more behavioral aspects like side effects, permissions, or constraints to be fully complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides basic semantic information for both parameters: 'plan_id' is described as 'The ID of the item' and 'status' gets enumerated values. However, it doesn't clarify what constitutes a 'plan' versus a 'step' (mentioned in the first sentence), nor does it explain format expectations beyond the enum list. This provides minimal but adequate parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Update') and resource ('status of a plan or step'), making it immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'reschedule_plan' or 'cancel_travel_plan' that might also involve status changes, 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. With sibling tools like 'cancel_travel_plan' and 'reschedule_plan' that might handle specific status transitions, there's no indication of whether this tool is the general-purpose status updater or when other tools should be preferred.
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. While it mentions validation and saving behaviors, it lacks critical details: what validation rules are applied, whether validation failures prevent saving, what happens when auto_save=false, what permissions are required, whether this is idempotent, or what the response contains. For a mutation tool with database operations, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by parameter explanations. The Args section is well-structured. However, the Chinese-only content might limit accessibility in some contexts, and the parameter explanations could be more informative given the schema coverage gap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, for a validation and database save operation with 3 parameters and no annotations, the description should provide more context about validation rules, error conditions, and the relationship to sibling creation tools. The current description is minimally adequate but leaves significant gaps in understanding tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides basic parameter explanations in the Args section, clarifying that plan_data should be a JSON string and auto_save controls database persistence. However, it doesn't explain the JSON structure expected for plan_data, what constitutes a valid name, or the implications of the auto_save default value. The description adds some value but doesn't fully compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '验证计划数据并保存到数据库' (validate plan data and save to database). This specifies both the validation action and the saving action with the target resource (plan data to database). However, it doesn't explicitly differentiate from sibling tools like 'create_plan' or 'create_plan_batch', which likely 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. With multiple sibling tools for plan creation and management (create_plan, create_plan_batch, create_study_plan, create_travel_plan), there's no indication of when validation-and-save is preferred over direct creation tools or when auto_save should be enabled/disabled.
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. '备份' (backup) implies a read operation that might create a copy or export, but the description doesn't specify if this requires permissions, affects system state, involves rate limits, 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 with a single phrase ('备份所有计划数据'), which is front-loaded and wastes no words. Every part of the sentence directly contributes to stating the tool's purpose, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description's job is reduced. However, it's a backup operation with no annotations, and the description doesn't explain what 'backup' entails (e.g., file format, location, or if it's a destructive read). With output schema handling return values, the description is minimally adequate but lacks context for a mutation-like tool.
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 add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as it avoids redundancy and the lack of parameters is well-handled by the schema.
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 states the action ('备份' meaning backup) and resource ('所有计划数据' meaning all plan data), which clarifies the tool's purpose. However, it doesn't differentiate this tool from potential siblings like 'get_plan_details' or 'list_plans' that might also retrieve plan data, making it somewhat vague in comparison. It avoids being a tautology by specifying the scope ('all').
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. Given siblings like 'list_plans' or 'get_plan_details', it's unclear if this tool is for archival, data export, or simple retrieval. There are no explicit when/when-not instructions or named alternatives, leaving usage ambiguous.
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 states '快速创建' (quickly create) which implies a write/mutation operation, but doesn't disclose permissions needed, whether creation is reversible, rate limits, or what the output contains. For a creation 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 is appropriately sized and front-loaded with the main purpose first, followed by parameter details. The Args section is well-structured with clear parameter explanations. Every sentence serves a purpose, though the Chinese-only text might limit accessibility in some contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates study plans (moderate complexity), has no annotations, but has an output schema (which reduces need to describe returns), the description is moderately complete. It covers parameters well but lacks behavioral context and usage differentiation from siblings. The presence of an output schema helps, but more context about the creation process would be beneficial.
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?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters in the Args section with clear examples and formats. It adds meaningful context beyond the bare schema, such as example subjects ('Python编程') and date format (YYYY-MM-DD), though it doesn't cover all possible constraints or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '快速创建学习计划模板' (quickly create study plan template), which specifies the verb 'create' and the resource 'study plan template'. It distinguishes from siblings like 'create_plan' by specifying 'study plan' rather than generic plans, though not explicitly contrasting with other plan-creation tools.
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 siblings like 'create_plan', 'guided_plan_creation', and 'create_travel_plan', there's no indication of when this specific study plan creation tool is appropriate or what differentiates it from other creation 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. It states the tool updates dates, implying a mutation operation, but doesn't specify whether this is destructive (e.g., overwrites dates irreversibly), requires specific permissions, handles errors (e.g., if no old dates exist), or provides feedback on changes. 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, and the 'Args' section succinctly explains the parameter. There's no wasted text, but it could be slightly more structured (e.g., separating usage notes). Overall, it's efficient with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 1 parameter), no annotations, and an output schema (which handles return values), the description is partially complete. It covers the purpose and parameter semantics adequately but lacks behavioral details (e.g., safety, permissions) and usage guidelines. With an output schema, it doesn't need to explain returns, but the gaps in other areas make it only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema. The schema has 1 parameter with 0% description coverage, only listing 'year' as a string with a default. The description explains that 'year' is the '目标年份' (target year) used to update dates before it to that year, clarifying its role in the update logic. This compensates well for the low schema coverage, though it doesn't detail format (e.g., YYYY) or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '修复过去的日期 - 将指定年份之前的计划日期更新为指定年份' (Fix old dates - update scheduled dates before a specified year to that year). It specifies the verb ('update'), resource ('scheduled dates'), and scope ('before a specified year'), distinguishing it from siblings like 'reschedule_plan' or 'update_plan_status' by focusing on date correction rather than general rescheduling or status changes. However, it doesn't explicitly differentiate from all siblings, such as 'backup_plans' or 'create_plan_batch', which might involve date handling indirectly.
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 existing plans with old dates), exclusions (e.g., not for future dates), or comparisons to siblings like 'reschedule_plan' (which might handle individual date changes) or 'update_plan_status' (which focuses on status, not dates). Usage is implied by the purpose but lacks explicit context for selection.
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 details but doesn't cover critical aspects like whether it's read-only (implied by 'Get' but not explicit), authentication needs, rate limits, error handling, or what happens if the plan_id is invalid. For a tool with zero annotation coverage, this is a significant gap, scoring 2 for partial 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 sentence that front-loads the core action ('Get the full details and structure of a plan') and adds necessary scope ('including all its steps'). There is no wasted verbiage or redundancy, making it highly concise and well-structured, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with one parameter), no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers the basic purpose but lacks usage guidelines, behavioral details, and parameter semantics. With the output schema reducing the need to explain returns, it's complete enough for a basic tool but has clear gaps, scoring 3.
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 1 parameter (plan_id) with 0% description coverage, so the schema provides no semantic context. The description doesn't mention the parameter at all, failing to compensate for the coverage gap. However, with only one parameter, the baseline is higher; the description implies the parameter indirectly by referring to 'a plan', but doesn't add meaningful details like format or constraints, resulting in a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('full details and structure of a plan'), including the scope ('including all its steps'). It distinguishes from siblings like 'list_plans' (which likely lists multiple plans) and 'get_plan_statistics' (which focuses on metrics). However, it doesn't explicitly differentiate from 'search_plans' or other detail-oriented tools, keeping it at 4 rather than 5.
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 valid plan_id), exclusions, or comparisons to siblings like 'search_plans' (which might return partial details) or 'list_plans' (for overviews). This lack of context leaves the agent to infer usage, scoring 2 for minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a change operation, implying mutation, but doesn't cover critical aspects like permissions needed, whether changes are reversible, side effects on related steps, or rate limits. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by parameter details in a structured 'Args:' section. It's efficient with minimal waste, though the 'plan_id' description could be more precise (e.g., specifying it's for a plan, not just 'item').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is moderately complete. It covers the basic operation and parameters but lacks behavioral context and usage guidelines, which are important for a mutation tool in a complex sibling set.
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 0%, so the description must compensate. It adds meaningful context: 'plan_id' is described as 'The ID of the item' (though vague), and 'new_time' specifies format as 'ISO 8601 date string' with an example. This provides essential semantics beyond the bare schema, though it could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Change') and resource ('scheduled time for a plan or step'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'update_plan_status' or 'fix_old_dates', which might also involve time adjustments, so it doesn't fully achieve sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, exclusions, or compare it to siblings such as 'update_plan_status' or 'fix_old_dates', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '批量删除' (batch deletion), indicating a destructive operation, but doesn't disclose critical behavioral traits: whether deletions are permanent/reversible, authentication requirements, rate limits, confirmation steps, or what '所有旅行相关计划' (all travel-related plans) entails (e.g., how plans are identified as travel-related). For a destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose and context, followed by a structured 'Args:' section for parameters. There's no wasted text, though the parameter descriptions could be slightly more detailed given the lack of schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (destructive batch operation), no annotations, 0% schema coverage, but an output schema exists, the description is moderately complete. It covers purpose, context, and parameter roles, but lacks behavioral details (e.g., deletion permanence, error handling) and doesn't explain return values (though output schema may cover this). For a tool with significant implications, it should do more to compensate for missing annotations.
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 0%, so the description must compensate. It adds meaning for both parameters: 'reason' is described as '取消原因' (cancellation reason) with a default, and 'keyword' as '搜索关键词' (search keyword) with a default search for travel-related plans. This clarifies their roles beyond schema titles, but doesn't detail constraints (e.g., reason length, keyword matching logic). With 2 parameters and low schema coverage, this provides basic but incomplete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '取消旅行计划' (cancel travel plans) with the context of '当用户时间变动时批量删除所有旅行相关计划' (batch delete all travel-related plans when user's schedule changes). It specifies the verb (cancel/delete), resource (travel plans), and scope (batch deletion). However, it doesn't explicitly differentiate from sibling tools like 'delete_plan' or 'delete_plan_by_name', which likely handle individual deletions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('当用户时间变动时' - when user's schedule changes) and scope ('批量删除所有旅行相关计划' - batch delete all travel-related plans), suggesting this is for bulk operations triggered by schedule conflicts. However, it doesn't explicitly state when NOT to use it (e.g., for single deletions or non-travel plans) or name alternatives like 'delete_plan' for individual cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions '级联删除所有子计划' (cascading deletion of all sub-plans), which is a critical behavioral trait indicating destructive, irreversible action. However, it lacks details on permissions required, error handling, confirmation steps, or what the output schema returns. For a destructive 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the structure is inefficient: the first sentence mixes purpose and behavioral traits, while the second is a parameter note. It's front-loaded with key information but could be better organized (e.g., separating purpose, behavior, and parameters). Some redundancy exists (e.g., repeating 'plan_name' in the description).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive deletion with cascading effects), no annotations, and an output schema (which reduces need to describe returns), the description is partially complete. It covers the destructive nature and parameter semantics but misses critical context like permissions, error cases, or confirmation requirements. It's adequate for basic use but has clear gaps for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema: it explains that 'plan_name' supports '模糊匹配' (fuzzy matching), which is not evident from the schema alone (schema description coverage is 0%). With only one parameter, the description compensates well for the low schema coverage by clarifying the matching behavior, though it could specify fuzzy matching rules (e.g., partial matches).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '按名称删除计划' (delete plan by name) with the specific action of deletion and target resource of plans. It distinguishes from the sibling 'delete_plan' by specifying deletion by name rather than ID, though it doesn't explicitly contrast with other deletion-related tools like 'preview_delete_plan'. The purpose is specific but could be more differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: it mentions '适合语音交互' (suitable for voice interaction) and implies usage when deleting by name with fuzzy matching. However, it doesn't explicitly state when to use this tool versus alternatives like 'delete_plan' (likely by ID) or 'preview_delete_plan', nor does it provide exclusions or prerequisites. The guidance is implied but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions filtering by category and status but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'top-level' means operationally. For a read operation with siblings that modify data, more transparency about safety and constraints is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. Every sentence earns its place with no wasted words, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and an output schema (which handles return values), the description is moderately complete. It explains the tool's scope and parameters but lacks behavioral context (e.g., pagination, errors) and sibling differentiation, which are important for a listing tool among many plan-related operations.
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 0%, so the description must compensate. It adds meaning by explaining that parameters filter results (e.g., 'category: Filter by category') and provides examples ('travel', 'study'), which clarifies usage beyond the schema's basic types. However, it doesn't cover all possible values or constraints, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List top-level plans (items without a parent).' It specifies the verb ('List') and resource ('top-level plans'), and distinguishes from siblings by focusing on parentless items. However, it doesn't explicitly differentiate from 'search_plans' or 'get_plan_details', which slightly limits 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. With siblings like 'search_plans' and 'get_plan_details' available, there's no indication of when this filtered listing is preferred over broader searches or detailed views. Usage context is implied but not stated.
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 states the tool creates a plan but doesn't disclose behavioral traits like whether it requires authentication, what happens on success/failure, if it's idempotent, or what the output contains. For a creation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with a brief purpose statement followed by clearly labeled parameter explanations. Every sentence earns its place by providing essential information, though the formatting with 'Args:' and bullet-like structure could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 6 parameters with good semantic coverage in the description, but zero annotations and no behavioral context, the description is moderately complete. It adequately explains what the tool does and what parameters mean, but misses important behavioral aspects for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 6 parameters. Each parameter gets a Chinese description with concrete examples (e.g., '我要去云南旅行' for name, '旅行' for category), format specifications (ISO 8601), and usage context. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a generic plan ('创建一个通用计划'), which is a specific verb+resource combination. It distinguishes itself from more specialized siblings like create_travel_plan and create_study_plan by being generic, though it doesn't explicitly contrast with them.
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 multiple sibling tools for plan creation (create_plan_batch, create_travel_plan, create_study_plan, guided_plan_creation), there's no indication of when this generic version is preferred over specialized ones or batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a creation tool (implying mutation) but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling, or what happens on success/failure. The description adds minimal behavioral context beyond the basic 'create' action, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a clear purpose statement, usage context, and parameter explanations with a helpful example. Every sentence adds value, and it's front-loaded with the core functionality. The 'Args:' section organizes parameter details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 4 parameters, no annotations), the description is moderately complete. It covers purpose, usage, and most parameters but lacks behavioral details (e.g., permissions, side effects). The presence of an output schema means return values don't need explanation, but for a creation tool with no annotations, more behavioral transparency would improve completeness.
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?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters: 'name' (name of main plan), 'children' (JSON string of step objects with example), and 'category' (category for plan and children). It clarifies that 'children' must be a JSON string (not just any string) and provides a concrete example. However, it omits the 'description' parameter entirely, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a plan with multiple steps in one go.' It specifies the verb ('create'), resource ('plan'), and scope ('with multiple steps'), distinguishing it from sibling tools like 'create_plan' (singular) and 'create_study_plan' (specific type). The examples ('Weekly Study Plan', '21-Day Challenge') further clarify the use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Useful for generating full schedules like...' It implies this is for batch creation of multi-step plans, suggesting alternatives like 'create_plan' for single-step plans. However, it doesn't explicitly state when NOT to use it or name specific sibling alternatives, keeping it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a preview/simulation tool that doesn't perform actual deletion, which is valuable behavioral context. However, it doesn't disclose other important behavioral traits like what specific impact information is returned, whether it requires special permissions, or if there are rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured - a single clear purpose statement followed by parameter documentation. Every sentence earns its place, with no wasted words. The bilingual presentation (Chinese description with English parameter label) is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 1 parameter with 0% schema coverage, and no annotations, the description provides adequate coverage for a preview/simulation tool. It clearly establishes the tool's purpose and safety profile (non-destructive), though could benefit from more detail about what 'impact' information is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'plan_id' by specifying it's '要预览的计划ID' (the plan ID to preview). With 0% schema description coverage and only 1 parameter, this provides adequate semantic clarification beyond the basic schema type information, though it could specify format expectations more clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('预览删除计划的影响' - preview the impact of deleting a plan) and resource ('计划' - plan), and explicitly distinguishes it from actual deletion with '不实际删除' (does not actually delete). This differentiates it from sibling tools like 'delete_plan' and 'delete_plan_by_name'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool - to preview deletion impact before actual deletion. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'delete_plan' for actual deletion, though the distinction is strongly implied through the '不实际删除' clause.
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:

[![plan_mcp_service MCP server](https://glama.ai/mcp/servers/Danson-dan/plan_mcp_service/badges/card.svg)](https://glama.ai/mcp/servers/Danson-dan/plan_mcp_service)

Score Badge

Copy to your README.md:

[![plan_mcp_service MCP server](https://glama.ai/mcp/servers/Danson-dan/plan_mcp_service/badges/score.svg)](https://glama.ai/mcp/servers/Danson-dan/plan_mcp_service)

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/Danson-dan/plan_mcp_service'

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