MCP Probe Kit

by mybolide

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v3.7.0
Disambiguation2/5
Many tools have overlapping purposes: start_feature vs add_feature, fix_bug vs start_bugfix, ask_user vs interview, and code_review/refactor/fix_bug all blur boundaries. The presence of a 'workflow' meta-tool to decide which tool to use further highlights ambiguity.
Naming Consistency3/5
Naming mixes verb_noun (fix_bug, ask_user), noun_verb (code_review, git_work_report), abbreviated forms (gencommit, gentest), and inconsistent prefixes for similar roles (start_*, init_*, add_*). While all names are lowercase and readable, the pattern is not uniform.
Tool Count2/5
With 30 tools, this server significantly exceeds the typical well-scoped range. Several tools could be consolidated (e.g., start_* variants), and the breadth makes it heavy for an agent to navigate effectively.
Completeness4/5
The tool surface covers major development activities: project init, spec generation, estimation, code review, refactoring, bug fixing, testing, UI design, and memory CRUD. Minor gaps exist, such as no spec update/delete tool or explicit test execution, but core workflows are largely complete.
Average 3.8/5 across 30 of 30 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
The description states the tool performs bug fixing (mutation), but annotations declare readOnlyHint=true. This is a direct contradiction. The description does not disclose any behavioral traits beyond the workflow steps, and the annotation conflict severely undermines 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?
Description is two sentences, front-loaded with purpose, and contains no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 13 parameters and no output schema, the description only outlines the workflow process. It fails to describe return values, side effects, or prerequisites. The annotation contradiction further reduces 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 coverage is 100% with all parameters having descriptions. The tool description adds no additional semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for finding problems, fixing bugs, and troubleshooting anomalies. It also describes the default workflow steps. However, it does not differentiate from the sibling tool 'fix_bug', which appears to 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (bug fixing/troubleshooting) but provides no explicit when-not-to-use or alternatives. Given the presence of sibling 'fix_bug', the lack of comparative guidance could lead to confusion.
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?
The description claims the tool generates interview record files (side effects), but annotations declare readOnlyHint=true and idempotentHint=true, which imply no state changes. This is a direct contradiction, severely undermining transparency. Without annotations, the description itself would provide some behavioral context, but the contradiction makes it misleading.
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 sentence that packs essential information: use case, function, output, and type constraint. It is concise but could be better structured (e.g., separate sentences for clarity). Still, it efficiently conveys key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object parameter ('answers') and no output schema. The description fails to explain the structure of the interview answers or the format of the generated record file. It mentions the output is used by other tools but lacks details needed for correct invocation and understanding the tool's full 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 coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema descriptions for 'answers', 'description', and 'feature_name'. It mentions that 'answers' are for submitting results and 'description' starts the interview, but this is already captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: clarify requirements through structured questions when they are unclear. It specifies that it generates interview record files for subsequent tools and only supports 'feature' type. While it lacks explicit differentiation from sibling tools like 'ask_user', the purpose is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: when user requirements are unclear and need clarification. It also mentions the output is used by start_feature/add_feature, indicating the tool's place in the workflow. However, it does not provide when-not-to-use scenarios or alternative tools.
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?
The description claims the tool generates directories and scripts (write operations), but the annotation 'readOnlyHint' is true, indicating a read-only action. This is a direct contradiction. Additionally, no details about authorization, rate limits, or consequences are provided beyond the safety defaults mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose ('start Ralph Wiggum Loop') and add safety context. Every sentence contributes value without 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?
Despite 12 optional parameters and no output schema, the description omits post-execution behavior or expected output. The annotation contradiction further undermines completeness, as the description's claim of file generation conflicts with the readOnly hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter well-documented in the schema itself. The description adds no extra meaning beyond repeating the high-level purpose, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates a Ralph Wiggum Loop development cycle, generating directory structure and scripts with safety defaults. It distinguishes itself from sibling tools like start_bugfix or start_feature by specifying a unique loop development pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when starting a Ralph Wiggum Loop but provides no explicit guidance on when not to use it or which alternative tools to consider. The sibling list includes many start_* tools, yet no comparison is made.
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?
The description contradicts the annotation 'readOnlyHint: true' by detailing that the tool generates multiple artifacts (PRD, prototype, etc.) and updates context, indicating mutation. According to the scoring rules, a contradiction results in a score of 1. The description does add context about the workflow outputs, but the contradiction is severe.
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 relatively concise, with each sentence contributing value. It front-loads the purpose and lists steps clearly. Minor inefficiency: the list could be formatted but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-step workflow, the description covers the steps and output (viewable HTML prototype) adequately. However, it does not mention any prerequisites or what happens if required parameters are missing. No output schema exists, so the description's mention of the output helps. Still, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (6 parameters all described). The tool's description does not add significant meaning beyond the schema; it mentions 'description' as the foundation but no further parameter details. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it orchestrates a complete product design workflow from requirements to an interactive HTML prototype. The verb 'orchestrate' and the enumerated steps provide a clear and specific purpose. It distinguishes itself from sibling tools like start_feature or start_bugfix by focusing on end-to-end product design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a full product design workflow is needed, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., start_feature for individual features) or when not to use it. No exclusions or prerequisites are stated.
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?
The description discloses that the tool generates code and templates, which implies mutation of files, contradicting the annotation `readOnlyHint: true`. This contradiction reduces trust, hence a score of 1 per rule.
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: two sentences that front-load the purpose and then enumerate the steps. No wasted words; every clause adds value.
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 (10 parameters, no output schema), the description provides a high-level overview of the workflow but lacks details on return values or how to interpret results. It is functional but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and schema descriptions. The main description does not add detail beyond that, so it meets the baseline of 3 but does not exceed it.
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 as an all-in-one UI development orchestrator that automates the entire process from design system checking to code rendering. It uses specific verbs ('检查', '生成', '搜索/生成', '渲染') and distinguishes from siblings like ui_design_system and ui_search by positioning itself as an integrated solution.
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 indicates suitability for rapid prototyping and ensuring style consistency, but does not explicitly state when to use this tool over alternatives like start_feature or ui_search. Usage context is implied but lacks direct comparison or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states '生成' (generate/create), which implies a write operation creating new documents, but annotations declare readOnlyHint=true. This is a direct contradiction, undermining the agent's ability to predict side effects. Per the scoring rules, any contradiction must result in a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the purpose and usage. It avoids unnecessary detail and every phrase contributes to understanding, despite slight redundancy in repeating '生成...文档'.
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?
With no output schema and 6 optional parameters, the description should explain more about the tool's behavior and outputs. It does not describe the generated document structure, layout options, or template profiles, and the annotation contradiction further reduces trust in the available context.
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 provides 100% description coverage for all 6 parameters, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond what the schema already supplies, so no reason to exceed the baseline.
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 generates new feature specification documents (requirements/design/task list) based on project context, using explicit verbs ('生成') and resource ('新功能规格文档'). It distinguishes itself from generic operations by specifying the exact output content, making its purpose unmistakable.
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 a clear when-to-use trigger ('当用户需要添加新功能、生成功能规格文档时使用'), but it does not mention alternatives or exclusions. While this is sufficient for basic usage, the lack of explicit differentiation from sibling tools like start_feature prevents a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no side effects. The description adds that this is a 'guide-type tool' and that MCP does not automatically generate or run tests, which provides some additional behavioral context but does not contradict annotations.
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 (two sentences) and front-loaded with the key usage scenario. Each sentence serves a purpose, though the second sentence could be structured more clearly. Still, no filler.
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 4 parameters and lack of output schema, the description explains when to use, what to provide, and what the agent does. However, it omits details about return values and does not clarify the 'test checklist' concept. It is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description mentions '注入 code/file_path 与测试清单' but '测试清单' is not a parameter in the schema, potentially causing confusion. Overall, the description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is used for generating unit tests for code ('当用户需要为代码生成单元测试时使用'). It specifies the action (generate tests) and resource (code/file_path). While it doesn't explicitly distinguish from siblings, the purpose is distinct enough among the listed 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 guidance ('当用户需要为代码生成单元测试时使用', '指南型工具') and clarifies that MCP does not auto-generate or run tests. However, it lacks explicit when-not-to-use instructions or alternatives, making it only moderately helpful for decision-making.
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?
Annotations provide idempotentHint=true and destructiveHint=false, so the safety profile is clear. The description adds the list of sources but does not disclose details about cache behavior, conflict resolution, or authentication needs.
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?
Description is very concise with a single sentence and source list. Purpose is front-loaded, but the brevity omits potentially helpful usage context. Not overly verbose but lacks some detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two optional parameters and no output schema, the description provides minimal but adequate context. However, it does not explain cache lifecycle, error handling, or integration with sibling UI tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters have clear descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool synchronizes UI/UX data to local cache and lists the data sources (uipro-cli, shadcn/ui registry, etc.), making the purpose specific and distinguishable from sibling tools like ui_search.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, restrictions, or scenarios where syncing is appropriate or inappropriate.
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?
Description discloses a write side effect (auto-creating/updating .agents/skills/mcp-probe-kit/SKILL.md and AGENTS.md), but annotations declare readOnlyHint=true and idempotentHint=true, directly contradicting the described mutation. Per rules, score 1 and flag as annotation contradiction.
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?
Two sentences; the first gives purpose and trigger, the second discloses the side effect. No waste, but the significant side effect could be emphasized more. Overall concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the side-effect trigger, but doesn't specify the structure of the 'firstTool + phases' response. With no output schema, that's a gap. It's adequate but lacks detail on what the returned guide looks like and when the write occurs beyond 'missing'.
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?
All three parameters have solid descriptions in the schema (100% coverage), so the description doesn't need to add parameter details. It ties the 'intent' parameter to the routing behavior but provides no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a fallback router that returns a phased MCP guide (firstTool + phases) based on intent. It also mentions a project setup side effect. This distinguishes it from the many task-specific sibling tools like start_feature or fix_bug.
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?
Explicitly instructs to use when unsure which MCP tool to select, giving a clear trigger condition. It does not name specific alternatives but the 'when uncertain' framing is sufficient to guide the agent away from direct task tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating the tool is safe and may access external resources. The description adds that it generates context documentation, but does not detail the process or potential side effects beyond what annotations convey. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two very concise sentences that convey the purpose and process without any wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description is adequate but minimal. It does not explain what 'context documentation' entails, prerequisites, or expected outcomes, which could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions, achieving 100% coverage. The tool description does not add any additional semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is used for quickly starting a new project by generating context documentation. It distinguishes from siblings like 'init_project' by focusing on onboarding and documentation generation, but does not explicitly differentiate from potentially similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool (when starting a new project), but does not specify when not to use it or mention alternative tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate readOnlyHint=true and idempotentHint=true, the description adds that the agent performs the actual fix and the MCP only injects a worksheet and gatekeeping. This is consistent and provides extra context beyond annotations.
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 short, front-loaded two sentences that efficiently state purpose and behavioral notes. While concise, it could be slightly more 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 11 parameters and no output schema, the description covers the main purpose and methodology but lacks details on return values or output format. It is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 11 parameters. The description does not add further semantic value beyond the schema, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for finding problems, fixing bugs, and troubleshooting. It specifies a methodology (SRC-8/TBP-inspired) but does not explicitly contrast with sibling tools like 'start_bugfix' or 'code_review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when user needs to fix bugs, and notes that the MCP does not automatically fix bugs. However, it lacks explicit 'when not to use' guidance or alternatives, leaving the agent to infer context from sibling list.
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?
The description implies the tool generates spec documents (编排：生成规格) and outputs to a docs directory, which contradicts the readOnlyHint=true annotation that suggests the tool makes no persistent changes. It also fails to disclose file creation, required permissions, or reversibility. The contradiction makes this score 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose, then the orchestration flow, then the alternative. Every phrase earns its place with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, orchestration workflow), the high-level flow is provided but key behavior is missing: what the tool actually returns, that it likely writes spec files to docs_dir, and how optional parameters (e.g., requirements_mode, loop_* settings) affect the process. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the 11 parameters with detailed descriptions. The tool description does not add additional explanation beyond the orchestration steps, so the baseline score of 3 is appropriate—the schema already carries the semantic weight.
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 orchestrates a full new-feature development flow with explicit steps (check context → generate spec → estimate workload), and it explicitly distinguishes itself from sibling add_feature for spec-only needs. This is a specific verb+resource+process description that differentiates from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use ('when the user needs a complete new feature development process') and an explicit alternative for a related case ('if only need a spec document, use add_feature'). This constitutes a clear when/when-not/alternative pairing, exceeding the 'clear context' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool injects code/file_path and a checklist, the agent reads code and outputs structured issues, and that MCP does no static scanning. This adds behavioral context beyond the readOnlyHint annotation without contradiction.
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 (two sentences in Chinese plus a short note) and gets to the point quickly, though it could be slightly more structured for scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's approach and mentions output format (severity, category, suggestion) but lacks details on how parameters like project_root and file_path interact, and has no output schema to compensate. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters. The tool description adds no additional semantic meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is used for reviewing code quality and checking code issues, and distinguishes it by noting it's a guideline tool that does not perform static rule scanning, providing a specific verb and resource.
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 says to use when reviewing code quality and clarifies it's not static scanning, but does not explicitly state when not to use it or compare to sibling tools like 'code_insight', leaving adoption decision partially ambiguous.
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?
Annotations already declare readOnlyHint and idempotentHint, so the tool is known to be non-destructive and idempotent. The description adds that it outputs story points, time ranges, and risk points, providing useful behavioral context beyond annotations, but does not disclose any further behavioral traits like accuracy dependencies or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences in Chinese, front-loaded with the use case and followed by the output. Every sentence adds value, with no superfluous information.
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 lack of an output schema, the description appropriately explains the return values (story points, time range, risk points). However, it does not detail how parameters like team_size or experience_level affect the output, leaving some context incomplete for a thorough 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%, so the schema already documents parameters adequately. The description adds no new parameter semantics beyond what the schema provides, only stating the output. Baseline score of 3 is appropriate as the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for estimating development workload and evaluating task time, specifying outputs like story points, time ranges, and risk points. This provides a specific verb-resource combination and distinguishes it from sibling tools that handle different tasks like code review or bug fixes.
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 explicitly states when to use the tool ('when users need to estimate development workload'), but does not provide when-not-to-use scenarios or mention alternative tools. The context is clear but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only and non-deterministic nature is covered. The description adds that the search is semantic and targets shared memory, but does not elaborate on side effects, authorization, or rate limits. It adds some value beyond annotations but is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, and the second provides usage context and a reference to a sibling tool. It is front-loaded, efficient, and contains no redundant information.
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?
While the description explains the purpose and usage context, it lacks information about the return value or output format. Since there is no output schema, the description should have mentioned what the search returns (e.g., identifiers, summaries) to fully inform the agent. This is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already provides clear descriptions for all four parameters. The tool description does not add additional meaning beyond what is in the schema, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool performs semantic search over the shared memory library, and distinguishes it from siblings like read_memory_asset by specifying that after a hit, the user should use read_memory_asset to read the full text. It also gives usage context outside start_* tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool for proactively finding historical bug fixes or reusable patterns outside start_* workflows, and directs users to read_memory_asset after a hit. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述补充了工具基于Spec-Driven Development理念，生成多种文档，与idempotentHint一致，无矛盾。
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?
描述简洁，三句话涵盖目的和适用场景，信息密度适中。
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?
在无输出模式的情况下，描述了输出内容（需求分析/技术设计/任务拆解），整体完整。
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?
输入模式全覆盖，描述未增加参数层的新信息，仅重申了input的用途（一句话需求）。
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?
描述明确说明工具用于处理一句话需求并生成项目规格文档，但未区分同系列工具如start_project等。
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?
明确提示在用户提供一句话需求时使用，并说明适合项目初期，但未提供排除条件或替代方案。
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no side effects. The description adds that it generates outputs (Markdown, JSON) but does not disclose additional behavioral traits such as reliance on AI inference or any limitations. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the main purpose and then listing outputs. Every sentence provides value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generative nature, 5 parameters, and no output schema, the description covers input requirements, optional parameters, and output types (Markdown, JSON, design spec docs). It is fairly complete but could mention the generation process or any constraints to achieve a perfect score.
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 coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema, such as explaining product_type as the core input for the inference engine and stack as generating tech-specific suggestions. This additional information helps the agent understand parameter usage.
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 it is an intelligent design system generator that produces complete design system recommendations including UI styles, color schemes, and more. It uses specific verbs ('generate') and resources ('design system') and is distinct from sibling tools like ui_search or start_ui.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating design systems based on product type and requirements, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or when-not-to-use guidance.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, read-only operation. The description adds value by listing searched item categories but doesn't disclose additional behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that covers essential information without unnecessary words. It is front-loaded with the core purpose and efficiently presents key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 3 modes, no output schema), the description covers the search scope and modes adequately. It could mention return format or result structure, but it is largely sufficient for an AI agent to understand 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?
Schema coverage is 100%, so parameters are fully described in the schema. The description adds a high-level overview of modes and categories but does not provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a UI/UX database, listing specific item types and three operation modes. It distinguishes from siblings like ui_design_system by specifying the broad search scope and modes.
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 explains the three modes (search, catalog, template) and their applicability, including that catalog doesn't require a query. However, it doesn't explicitly guide when to use this tool over alternatives like ui_design_system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true) are consistent with asking a user. The description adds behavioral context beyond annotations by noting support for multiple questions, options, and importance, and that it can be used at any time. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. Every sentence adds value, and there is no redundant or wasted text. It effectively communicates the tool's functionality in a compact form.
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 simple input schema and lack of output schema, the description covers when to use and what it does. However, it does not explain the expected response format or behavior on errors, which could be helpful for a tool that interacts with users.
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 parameter-level descriptions. The tool description provides an overview of parameter capabilities but does not add significant semantic value beyond what the schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to ask users questions when the AI needs more information or encounters uncertainty. It specifies that it supports single/multiple questions, options, and importance marking, which distinguishes it from sibling tools like search_memory or interview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: '当 AI 需要更多信息、遇到不确定因素时使用' (use when AI needs more info or uncertainty). It also notes it can be used at any time. However, it does not explicitly state when not to use or mention alternatives, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds details on multiple analysis modes, default backend, and automatic degradation with error reporting, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey purpose, modes, and fallback behavior. Every word serves a purpose 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?
While the high-level purpose is clear, the description does not explain the return value or output format. Given the complexity (10 parameters, 4 modes) and no output schema, some indication of what the user gets 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 coverage is 100%, so the baseline is 3. The description does not add additional parameter-level meaning; the schema already describes each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing call chains, context, and impact using a code graph. It specifies the modes (query/context/impact) and the default backend (GitNexus), making it distinct from siblings like code_review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (when analyzing code graph relationships) and mentions auto-degradation when unavailable. It does not provide explicit exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by detailing what the validation checks (placeholder, missing sections, etc.) and implying a report output. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose, includes the validation scope, and embeds usage timing. No superfluous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only validation tool with no output schema, the description covers the essential context: what is checked, when to use it, and the follow-up action. It could benefit from mentioning the report format or exit behavior, but it is sufficient for correct invocation. The rich annotations compensate for missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented (e.g., feature_name pattern, project_root auto-detection). The description reinforces the feature_name path pattern but does not add substantial new semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (校验) and resource (功能规格 docs/specs/<feature_name>/requirements|design|tasks.md), and lists exact validation checks (placeholder detection, missing sections, FR/acceptance criteria, FR coverage). This distinguishes it from all sibling tools, which focus on coding, review, or memory tasks.
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?
Explicitly states when to call (写完规格后、进入实现前) and the rerun loop (未通过按报告补全后重跑). It provides clear contextual guidance, though it does not explicitly mention when not to use it or name alternative tools. The when-to-use is strong enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds that the tool returns spec and prompts for git diff if changes are not provided, providing additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and includes necessary clarifications without superfluous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what is returned (spec, steps, template, examples) and the behavior when changes are missing. It is complete for this helper-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters. The description adds minimal extra context (e.g., prompting behavior for missing changes), but does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for generating Git commit messages and specifies that it returns Conventional Commits specification, steps, templates, and examples. It distinguishes itself from sibling tools by focusing on commit message generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (when needing a commit message) and what it does not do (does not write the final message, should not be considered empty). However, it does not explicitly mention alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive. Description adds that the tool writes to specific files (AGENTS.md, layout.json) and delegates follow-up actions. Could be more explicit about side effects or overwrite 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 concise, front-loading the core action and directing use cases. It packs essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While purpose and usage are clear, the description lacks details on the returned plan structure and how the agent should use it. With no output schema, more completeness would improve 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 coverage is 100% with each parameter described. The description does not add additional semantic context beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates/updates project context writing plan, writing AGENTS.md and layout.json, and directs the agent to write associated documents. It distinguishes from sibling tools like start_feature and start_bugfix by indicating separate workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use alternatives: for new features use start_feature, for bug fixes use start_bugfix. This provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: content changes trigger re-vectorization, the original ID is preserved, and deprecated fields are noted. Annotations already indicate idempotentHint=true and destructiveHint=false, and the description aligns without contradiction.
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 three sentences, each providing essential information without redundancy. It is front-loaded with the core purpose and efficiently covers usage context and behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, usage context, and important behavioral details despite having 13 parameters and no output schema. It could be improved by mentioning return value or error cases, but it is adequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as all 13 parameters have descriptions. The description adds only marginal value for parameters (e.g., warning about source_project/source_path). Baseline 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '更新' (update) and the resource '共享记忆库中的已有资产' (existing memory asset), and explicitly notes that the original ID is preserved. This distinguishes it from siblings like add_feature, memorize_asset, or delete_memory_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: '适用于修正摘要、正文或标签' (for correcting summary, content, or tags) and warns about cross-repo sharing by forbidding source_project/source_path. However, it does not explicitly list when not to use the tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, openWorld, and idempotent hints. The description adds context about the orchestration phase and the type of content returned (full code/specs), which aligns with and supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The condition is front-loaded, and the purpose is immediately clear. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately explains when to use and what it returns (full code/specs). No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter asset_id has 100% schema description coverage. The tool description merely restates that it reads by asset_id, adding no new information beyond what the schema already provides.
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 reads memory asset details by asset_id, and it is used when a memory summary is retrieved and full details are needed. This distinguishes it from siblings like search_memory or memorize_asset.
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 specifies the exact scenario when to use: after orchestration retrieves a memory summary. It does not explicitly state when not to use, but the context implies it is for retrieving a specific asset's full details, not for search or update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description does not need to reiterate destructiveness. It adds value by explaining the confirm parameter behavior and the recommendation to read before delete. However, it does not mention error handling for missing asset_id or permanence of deletion, which would fully leverage the absence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. First sentence states the core action, second provides use case and prerequisite. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, annotations cover safety), the description covers purpose, prerequisites, and use case. It could mention that deletion is permanent or what happens if asset_id is not found, but overall it is mostly complete for the scope.
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?
Input schema coverage is 100%, with clear descriptions for both parameters. The description does not add additional semantic detail beyond summarizing the operation and mentioning the soft confirmation behavior, which is already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an asset by asset_id from a shared memory repository. It specifies the resource, verb, and condition, and distinguishes from siblings like update_memory_asset and read_memory_asset by mentioning cleanup use cases and recommending confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (cleaning outdated, erroneous, or duplicate precipitations) and recommends prior confirmation with read_memory_asset. Also implies the confirm parameter for soft confirmation, providing clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). It specifies content formatting rules and deprecation of certain fields, but does not elaborate on behavior on duplicates or success indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines core purpose, second gives critical usage instructions. No redundant words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, bug fix conventions, cross-repo handling. With 12 parameters (3 required), schema covers the rest. Lacks return value info but no output schema expected. Fairly complete for a storage 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?
Schema has 100% parameter description coverage, baseline 3. Description adds value by specifying type='bugfix' for bug fixes, structured content requirements, and deprecation of source_project/source_path, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool stores retrievable assets into a shared memory bank, with specific verb '沉淀' (precipitate) and resource '资产' (assets). It distinguishes from sibling tools like delete_memory_asset, read_memory_asset, and update_memory_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidelines for bug fix assets (type=bugfix, structured content) and cross-repo sharing (omit source_project/source_path, include path in content). Lacks explicit when-not-to-use vs alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: it is a guidance tool that injects code/file_path, analyzes, and outputs a refactoring plan JSON, and explicitly states that MCP does not modify source files. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The description is front-loaded with the purpose and immediately clarifies the tool's non-modifying nature and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (0 required) and no output schema, the description explains the output (refactoring plan JSON) and behavior (no file modification). It lacks details on how conflicting inputs (both code and file_path) are handled, but overall it is sufficient for an agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters adequately. The description mentions 'injection of code/file_path' but adds no new information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for refactoring code and improving code structure. It specifies it's a guidance tool that outputs a refactoring plan JSON without modifying files, distinguishing it from sibling tools like fix_bug or add_feature.
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?
Description explicitly indicates when to use ('当用户需要重构代码、改善代码结构时使用') and mentions it's a guidance tool with no automatic file modification. It does not explicitly state when not to use, but the context is clear enough for an agent to choose appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses core behaviors: reading git commits, running git show, AI analysis of diffs, and output formatting. Annotations confirm readOnly and idempotent nature, which matches the description. No contradictions.
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?
Well-structured with clear sections (core function, output format, usage examples). Every sentence adds useful information without redundancy. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema, the description fully specifies the output format (bullet points, Chinese, professional style, excluded elements). Parameters are fully covered. The tool's complexity is well addressed.
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?
All parameters are described in the schema (100% coverage). The description adds value by explaining the difference between date (daily mode) and start_date/end_date (periodic mode), and notes output_file is optional.
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?
Clearly states the tool generates work reports from Git diff analysis, supports daily and periodic modes, and provides concrete examples. Distinguishes from sibling tools by specifying a unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage modes (daily vs periodic) with parameter examples. Does not explicitly mention when to avoid using, but the context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, making the safety profile clear. The description adds value by detailing how the tool behaves in different modes (single-segment vs. directory scanning) and how parameters affect scanning behavior, without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose and then delivers precise usage guidelines. Every sentence adds value with no redundancy, efficiently packing information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, multiple modes, integration with memory system), the description covers essential usage contexts well. However, it does not describe the output format or what constitutes a 'pattern', which would be helpful since there is no output schema. Still, it is largely complete for an experienced 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?
All 8 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description enriches this by explaining the relationship between 'project_root' and 'directory_path', best practices, and which parameters to use in which scenario, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: extracting reusable patterns from code snippets, single files, or entire directories, with the intent to potentially persist them into the memory system. It uses a specific verb ('scan and extract') and resource ('patterns from code'), and distinguishes itself from sibling tools like 'memorize_asset' and 'read_memory_asset' which handle direct memory operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (when needing to extract patterns for possible memorization) and how to parameterize it for directory scanning: recommending to pass 'project_root' as absolute and 'directory_path' as relative, with a warning against semi-relative paths. It also implies when not to use certain parameter combinations.
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:

[![mcp-probe-kit MCP server](https://glama.ai/mcp/servers/mybolide/mcp-probe-kit/badges/card.svg)](https://glama.ai/mcp/servers/mybolide/mcp-probe-kit)

Score Badge

Copy to your README.md:

[![mcp-probe-kit MCP server](https://glama.ai/mcp/servers/mybolide/mcp-probe-kit/badges/score.svg)](https://glama.ai/mcp/servers/mybolide/mcp-probe-kit)

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/mybolide/mcp-probe-kit'

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