Xadeus-QQ-MCP
Server Quality Checklist
Latest release: v0.1.1
- Disambiguation5/5
Each tool has a clearly distinct purpose, with descriptions explicitly differentiating them (e.g., send_message vs send_image vs send_voice). Overlap is minimal and well-documented.
Naming Consistency5/5All tools follow a consistent verb_noun snake_case pattern (e.g., add_timer, list_timers, send_message). No mixing of conventions.
Tool Count3/533 tools is high, but the domain (QQ bot management, wake rules, timers, configuration) justifies the count. Still, it feels heavy compared to typical well-scoped sets.
Completeness4/5The tool surface covers the core domain comprehensively: messaging, group management, context handling, wake configuration, and debugging. Minor gaps exist (e.g., no message editing), but overall coverage is strong.
Average 4.4/5 across 33 of 33 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds 'Mutates the group by muting a member' and default duration, but lacks details on error states or behavior when bot lacks privileges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the purpose, and efficient. However, it repeats parameter explanations that could be inferred from the schema, making it slightly less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main points: purpose, parameters, prerequisite, and reversal. Lacks details on error handling or behavior when member is already muted. Acceptable for a simple mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter: group_id as QQ group number, user_id as QQ number, and duration with default 600 seconds. This adds meaning beyond the schema's type/title only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mute a member in a QQ group' and explains parameters. It mentions unmute_member as a sibling tool but does not explicitly differentiate from other sibling tools like kick_member or set_member_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes prerequisite 'Requires bot to have admin privileges' and suggests unmute_member for reversal. However, it does not provide guidance on when to prefer mute over other mutation tools like kick_member.
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 says 'sends a test keystroke' which is not idempotent, contradicting idempotentHint: true. Also adds platform behavior but contradiction lowers score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded purpose, no wasted words, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, platform, and effect on QQ. Missing explicit return values for Windows, but sufficient for a no-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100% so baseline 3. Description adds no param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it manually triggers wake activation and sends test keystroke. Distinguishes from siblings by specifying it's for verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use to verify wake system functionality and notes platform limitation. No explicit alternatives mentioned but context sufficient.
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 idempotentHint annotation (true) by warning that excessive notices may be rate-limited, implying non-idempotent behavior. Annotations already indicate mutation (readOnlyHint=false), but the description adds useful admin privilege requirement and rate limit warning; nevertheless, the contradiction mandates 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 lines) and front-loaded with the core purpose. Every sentence adds value: purpose, parameters, requirements, caveats, and sibling differentiation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers prerequisites (admin privileges), behavior (persistent, visible to all), side effects (mutates group), and a caveat (rate limiting). It lacks return value or error details, but overall is sufficient for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining group_id as 'the QQ group number' and content as 'announcement text (plain text only)'. This adds meaning beyond the schema, though format details are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a group announcement to a QQ group, using specific verbs ('send') and resources ('group announcement'). It distinguishes from the sibling tool send_message by noting persistence and visibility to later joiners.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (persistent notices) and contrasts it with send_message. It warns about rate limiting and suggests not posting too frequently, but does not explicitly list when not to use it or other alternatives.
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 readOnlyHint=false. The description adds that changes 'take effect immediately' and are 'persisted across restarts,' which goes beyond the annotations. However, it does not disclose potential side effects, permission requirements, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~80 words) and well-structured: it starts with the overall purpose, then explains each parameter, and ends with behavioral notes. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no output schema), the description covers the core functionality and persistence. It lacks explicit mention of what happens when both parameters are null (likely resetting to defaults), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% coverage (no parameter descriptions), so the description fully compensates by explaining both parameters in detail: window_title_patterns are substrings for matching window titles, and focus_shortcut is a keyboard shortcut for focusing the input box. Examples are provided, adding essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure the wake target window and focus shortcut.' It uses a specific verb and resource, and the explanation of parameters distinguishes it from sibling tools like get_wake_config (read-only) and add_wake_rule (adds rules rather than setting config).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as add_wake_rule or set_wake_enabled. It only describes what it does without context about appropriate scenarios or exclusions.
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 readOnlyHint=false and destructiveHint=false, and the description explicitly states that it mutates the timer configuration and that timers persist across restarts, adding valuable behavioral context beyond annotations. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear first sentence, bullet-like examples for scheduling, a note on constraints, and cross-references to sibling tools. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, parameter details, and mutation behavior, but it omits any mention of what the tool returns (e.g., success indication, timer ID). With no output schema, this gap may leave the agent unsure how to handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by providing examples for cron_expr and interval_seconds, explaining the once flag, and noting the constraint that at least one of cron_expr or interval_seconds must be provided. The message parameter is required and self-explanatory, but no additional detail is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a timer task with a message at scheduled times, and specifies two scheduling methods. It mentions related sibling tools (list_timers, remove_timer) but does not explicitly distinguish from add_wake_rule, which is a close sibling also dealing with scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: supports cron and interval scheduling, with examples; notes that at least one must be provided; explains the 'once' flag; and points to list_timers and remove_timer for management. However, it does not specify when not to use this tool or compare it to alternatives like add_wake_rule.
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 readOnlyHint=false (mutates). The description adds context: 'same rate limiting and dedup as send_message', 'sent as QQ-native image', and explicitly states 'Mutates the chat'. No contradictions with annotations and adds useful behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences without wasted words. Each sentence adds distinct value: purpose, sibling alternatives, exclusivity, behavioral note, mutation acknowledgment. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 parameters, the description covers the core functionality but omits error handling, response format, size limits, and authentication. The openWorldHint suggests unknown side effects not clarified. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It clarifies that 'image' is base64-encoded and that 'target_type' defaults to group, but does not explain 'target' format, 'reply_to', or constraints like allowed image formats/sizes. Insufficient compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a base64-encoded image to a QQ group or friend. It explicitly distinguishes from siblings like send_message, send_voice, and send_file, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by referencing siblings: 'For text messages use send_message. For audio use send_voice. For files use send_file. This tool only sends images.' It lacks mention of prerequisites or edge cases but is above average.
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?
The description adds significant details beyond annotations: raw messages are replaced and unrecoverable, compression uses client LLM via MCP sampling with fallback. It fully aligns with destructiveHint=true and provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line followed by bullet points. It is concise but could be slightly more compact. No unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and no output schema, the description covers the essential aspects: usage, behavior, fallback, and side effects. It is sufficiently complete for an agent to understand what the tool does and its consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameters but does not. 'target' and 'target_type' are not described, leaving the agent to infer their meaning from the tool's purpose. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: compressing buffered messages into a summary to free space. It uses a specific verb-resource pair and distinguishes from related tools like get_recent_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('after get_recent_context when you want to archive old conversations') and notes the destructive nature. However, it could more directly state when not to use it (e.g., when raw messages are needed).
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 useful context beyond annotations: 'Timers are renumbered after removal' and reaffirms destructiveness. Annotations already cover destructiveness and idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no wasted words. Main action and key usage notes are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one param and no output schema, description covers action, prerequisite, renumbering behavior, and destructiveness. Could mention error handling for invalid index.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'index' is only described as the position from list_timers but lacks specifics on indexing (0-based vs 1-based) or valid range. With 0% schema coverage, description insufficiently compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Remove a timer task by index.' with specific verb and resource. Distinguishes from siblings like add_timer and list_timers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use list_timers to get current indices.' and warns about renumbering after removal, guiding proper usage sequence and caution.
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 detail beyond annotations: explains what happens when pending is True vs False, and states 'Mutates the wake monitor state.' Annotations already indicate idempotentHint=true and non-read-only, and the description aligns without contradiction, adding useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 short sentences) and front-loaded with the tool's purpose. Every sentence adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single boolean parameter, no output schema), the description is largely complete. It explains the parameter, use case, and side effects. Minor gaps: no mention of permissions, error conditions, or return values, but these are not critical for a simple state setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description fully explains the sole parameter 'pending' by detailing the behavior for True and False values. This adds significant meaning beyond the schema, which only specifies type and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: manually set the wake pending state to block or allow new wakes. It uses specific verbs ('set', 'block', 'allow') and identifies the resource ('wake pending state'). However, it does not explicitly differentiate from sibling tools like set_wake_config or set_wake_enabled, but the distinct boolean parameter makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: 'Use this to prevent duplicate wakes while the agent is already working.' This gives context but lacks explicit guidance on when not to use it or alternatives (e.g., set_wake_enabled) that might be more appropriate.
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, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds: 'Read-only. No side effects.' It also explains efficiency and error handling ('uses at most 2 OneBot API calls... errors for unmonitored targets'). No 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 5 sentences, front-loaded with the purpose. Each sentence adds value. Could be slightly more structured, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (batching, two params, no output schema), the description covers efficiency, error handling, and usage context. It does not describe return format, but that is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not directly describe the 'targets' or 'limit' parameters. The description gives context about targets being multiple groups/friends but lacks details on structure or meaning. This is insufficient for a 0% coverage tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query recent messages for multiple groups/friends in one call.' It uses a specific verb and resource, and distinguishes from the sibling 'get_recent_context' by emphasizing batching and efficiency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this when you need to read context from 2+ conversations at once. For a single target, use get_recent_context instead (simpler).' This provides clear context and an alternative.
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 that it creates a fake message and may invoke the wake callback, and that it is 'read-only with respect to QQ'. These details add value beyond the annotations (readOnlyHint, destructiveHint, idempotentHint). No contradiction detected because the description qualifies the read-only scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two paragraphs) and front-loads the purpose. Every sentence contributes, though the second paragraph could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains the response fields, distinguishes from diagnose_wake, and covers the main purpose. However, it does not mention error cases or prerequisites. Given no output schema, the description adequately describes expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions parameters only in passing ('from the given target_id and target_type') without explaining valid values, constraints, or semantics. This provides minimal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Simulate a wake trigger to debug the wake pipeline' and explains the steps and response fields. It explicitly distinguishes from sibling tool 'diagnose_wake' by noting that diagnose_wake is a read-only snapshot without callback invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit alternative: 'Use diagnose_wake for a read-only snapshot without triggering the callback.' It also explains the purpose (debugging) and what it checks, making it clear when to use this tool.
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, destructiveHint, and idempotentHint. The description adds context about the in-memory buffer behavior: messages older than the buffer window are lost, and periodically calling compress_context is necessary to preserve conversations. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating purpose, followed by return details, alternatives, and cautions. It is slightly lengthy but every sentence adds value. Could be more concise, but no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, but informative annotations, the description covers purpose, behavior (read-only, buffer loss), and alternatives. Missing details on return format specifics and error handling, but sufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'target' is a group or friend but does not explain 'target_type' or 'limit' parameters. No additional details about parameter values or constraints are provided beyond the schema's defaults and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent messages for one group or friend from the in-memory buffer, specifying the return type. It distinguishes itself from siblings like batch_get_recent_context and compress_context by naming them and their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that this is the primary tool for reading chat context, advises using batch_get_recent_context for multiple targets to reduce API calls, and recommends compress_context to archive old messages and preserve important conversations. It also warns about buffer window data loss.
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, destructiveHint=false, idempotentHint=true. The description adds 'Read-only. No side effects' which reinforces but does not significantly add 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second provides guidance, third summarizes behavior. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the tool is simple with no parameters and clear annotations. The description lacks return structure details but is sufficient given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter details, but baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Return the current wake configuration (window title patterns, shortcut)' which is a specific verb+resource pair and distinguishes from the sibling 'set_wake_config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to use 'set_wake_config' for modifications, providing clear context for when to use this tool vs the alternative. No exclusions beyond that.
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 auto-conversion to SILK, same rate limiting, and no reply_to parameter. Annotations confirm mutation (readOnlyHint=false). Adds valuable context beyond annotations, though could mention size limits or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, followed by conversion info and sibling comparisons. Three sentences plus a behavior note are concise and well-structured. Could be slightly more streamlined, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage alternatives, conversion, and behavioral constraints. No output schema needed; complexity moderate. Missing explicit parameter details but otherwise complete for sending a voice message.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description does not explicitly map parameters to variables. While overall context hints at target and audio, it lacks detailed semantics for each parameter, which is needed given no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Send' with specific resource 'base64-encoded voice message to a QQ group or friend.' Differentiates from siblings like send_message, send_image, send_file by naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives ('For text use send_message...'). Also mentions rate limiting same as send_message and notes that voice messages cannot be replied to.
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=false, destructiveHint=false, idempotentHint=true. The description adds that it 'Mutates the member's group card,' which aligns. It does not disclose additional behavioral traits like rate limits or error handling, but the annotation coverage is sufficient to avoid major gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a purpose: purpose, parameter explanation, privilege and mutation note. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential: what it does, parameters, and admin requirement. It lacks details on possible errors or validation (e.g., invalid card length), but for a straightforward mutation, it is almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter: 'group_id: the QQ group number. user_id: the QQ number. card: the new nickname text.' It adds meaning beyond schema, but could be more explicit about formats (e.g., numeric strings).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set a member's group nickname (card)' with the verb 'set' and resource 'member's group nickname'. It also notes the empty string behavior, distinguishing it from any sibling tool that might alter member properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a crucial prerequisite: 'Requires bot to have admin privileges.' It implicitly guides when to use this tool (to change a nickname). However, it does not explicitly mention when not to use it or provide alternatives, though no direct competitor exists among siblings.
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?
The description adds significant behavioral details beyond annotations: Playwright usage, base64 PNG, rendering logic (bottom-aligned, overflow cut), error condition, and read-only nature. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three main sentences and extra notes. Front-loaded with purpose. Every sentence adds value, though slight redundancy in read-only statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description specifies base64 PNG and error conditions. Prerequisites and usage flow are clear given sibling tools. Slight gap in target parameter explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains message_id usage well but does not clarify target (group/user ID?) or target_type (default group). Only partial param semantics covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a QQ-style dark-mode chat screenshot starting from a given message. It specifies the resource (chat screenshot) and action (render) and differentiates from siblings like send_message or get_recent_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises to use get_recent_context first to find valid message IDs, providing a clear prerequisite. It does not explicitly state when not to use or list alternatives, but the context implies it's for visual output.
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 rate-limiting (60s dedup window), blocking behavior on reply, and reply content. Annotations are minimal, so description adds significant context beyond readOnlyHint and destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with core function, example, behavior, and alternatives grouped. Slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, behavior, splitting, and alternatives. Lacks error cases and full reply format, but is sufficient for a messaging tool given 7 params and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description partially compensates by explaining content splitting and wait_reply behavior, but lacks explicit description for all parameters (e.g., num_chunks is only indirectly hinted).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a text message to a QQ group or friend with optional reply waiting. It distinguishes from siblings by naming alternative tools for images, audio, files, and standalone waiting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use alternatives (e.g., send_image for images) and describes message splitting technique with </分段> tags. This guides the agent to choose correctly.
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 non-readOnly, non-destructive, idempotent. Description adds context that mutation occurs and what disable means (skipped but kept). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main action, no redundant sentences, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with two parameters, the description covers purpose, usage, and behavioral effects adequately with no output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds that index can be None (all rules) but this contradicts schema which marks index as required integer. Otherwise, parameters are minimally explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (enable/disable) and resource (wake rule), and distinguishes from siblings like list_wake_rules and remove_wake_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use list_wake_rules to see current indices/states, explains disabled rules are skipped but remain, and directs to remove_wake_rule for permanent deletion.
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 provide readOnlyHint, destructiveHint, idempotentHint. The description adds context by stating 'Read-only. No side effects. Safe to call at any time' and describes the return values. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the purpose, and every sentence adds value. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and no output schema requirement, the description fully covers what the tool does, its return values, and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline of 4 for zero parameters is appropriate; the description adds no param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clearly defines the resource (QQ login status, NapCat connection, monitored targets). It distinguishes itself from siblings by stating it's a health check, not a query like get_group_list or get_friend_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to use this tool to verify the server is running correctly before calling other tools. It also contrasts with similar tools, providing clear context. No explicit when-not-to-use scenarios are mentioned, but the guidance is clear.
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, destructiveHint=false, idempotentHint=true. The description adds 'Read-only. No side effects,' which reinforces but doesn't significantly expand beyond annotations. It does mention return fields, adding some 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no wasted words. The main purpose is front-loaded, and each sentence adds value: purpose, return fields, usage, alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains return data (group IDs, names, member counts). The tool is simple with no parameters, and the description covers all needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage). The description compensates by explaining what the tool returns and how to use it, which is sufficient. Baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all QQ groups the bot has joined.' It specifies the return data (group IDs, names, member counts) and distinguishes from siblings like get_friend_list and batch_get_recent_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('discover valid group IDs for send_message, get_recent_context, or other group-targeting tools') and provides alternatives: 'For friend list use get_friend_list instead. For batch name resolution use batch_get_recent_context.'
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?
Discloses temporary directory usage, cleanup after upload, support for any file type, 60-second timeout, and that it mutates chat. Adds value 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs, front-loaded with main purpose, then behavioral details and alternatives. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential behavioral details and usage distinctions, but lacks explicit parameter descriptions for all four parameters. Output schema absent but acceptable given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description mentions file_url and file_name (optional) and target_type (defaults group), but does not explain 'target' parameter (group ID vs friend ID). Partial clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it downloads a file from a URL and sends to QQ group/friend. Distinguishes from siblings by naming send_message, send_image, send_voice for alternative content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (download and send file from URL) and when not (text, image, audio). Mentions requirement of publicly accessible URL without auth.
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 read-only, idempotent, non-destructive. Description adds detail on output fields and explicitly states 'Read-only. No side effects.', reinforcing safety but not adding new behavioral insight 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive: first sentence states purpose, then structured list of outputs, then usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's output and usage context. No missing information for a debugging tool with no parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the current state of the wake monitor for debugging, listing specific components. Distinguishes from sibling 'debug_wake_pipeline' which injects fake messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use as first step when wake is not working, and contrasts with 'debug_wake_pipeline' for more aggressive testing.
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, destructiveHint, idempotentHint. Description confirms 'Read-only. No side effects.' No contradictions, but doesn't add much beyond annotations. Still accurate and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four succinct sentences with no wasted words. Front-loaded with the core action, then usage context, then contrast with sibling. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and rich annotations, the description is fully complete. It explains purpose, usage, and alternatives, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4 as per rule. Description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all QQ friends of the bot account, specifying it returns user IDs and nicknames. It distinguishes itself from get_group_list, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use this to discover friend IDs for send_message or get_recent_context, and advises using get_group_list for groups. This provides clear when-to-use and 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds 'Read-only. No side effects.' consistent with annotations, and lists exact return fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences plus a bulleted list; front-loaded with purpose; no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only info retrieval with two obvious parameters and no output schema, the description provides all necessary context: what it does, return fields, and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but parameters (group_id, user_id) are self-explanatory from names. Description does not elaborate on them, but minimal explanation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns detailed info for a specific QQ group member, lists fields, and distinguishes from sibling tool get_group_member_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool (before muting, kicking, setting card) and when to use alternative (get_group_member_list for enumeration).
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 and idempotentHint=true. Description adds that the tool is 'Read-only. No side effects.' and discloses pagination behavior for large groups, which adds useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with clear structure: main purpose, return fields, usage alternatives, pagination note, and read-only statement. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one simple parameter, no output schema, the description covers return fields, usage context, pagination, and safety. Complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It implies that group_id identifies a QQ group and suggests using get_group_list to discover valid values. This provides sufficient meaning for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all members of a QQ group' with verb and resource. It distinguishes from siblings by mentioning get_group_member_info for single member and get_group_list for valid group_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit alternatives: use get_group_member_info for single member details, use get_group_list to discover valid group_id values. Also notes pagination handling for large groups (>200 members).
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 provide readOnlyHint, destructiveHint, and idempotentHint. The description reinforces these and adds detail on what each rule's output contains, which is helpful but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no wasted words. Front-loaded with purpose, followed by output details and sibling pointers. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with thorough annotations, the description is complete. It explains what is listed and what fields are shown, compensating for lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description does not need to add parameter details beyond what the empty schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all configured wake rules and specifies the fields shown (target type, ID, keywords, etc.). It distinguishes from siblings by mentioning add_wake_rule, remove_wake_rule, and set_wake_enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('List all configured wake rules'), mentions alternatives for related operations, and declares read-only nature, guiding appropriate selection.
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?
The description adds significant behavioral context beyond the annotations. It details the permanent deletion for all members, time limits, permission requirements, and the source of message_id. This fully informs the agent of the tool's side effects and constraints, complementing the destructiveHint=true annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first line, parameter details, usage conditions, and a final note. While it is slightly verbose, every sentence adds necessary information. Front-loading of the core purpose is good, though the parameter explanation could be integrated more concisely. Overall, it is effective without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one simple parameter, no output schema, and annotations already cover destructiveness, the description is fully complete. It covers permissions, time constraints, message source, scope (only bot's messages), and the permanent deletion effect. No important aspect is missing for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (message_id) with no description in the schema itself. The tool description fully explains what message_id is, where to obtain it (from send_message or send_image responses), and its role in the operation. This adds complete semantic meaning beyond the schema's type and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool recalls (deletes) a message sent by the bot. It specifies the action ('Recall (delete)'), the target resource ('a message sent by the bot'), and distinguishes it from sibling tools like send_message or send_image by focusing on deletion. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidelines on when to use the tool ('Use this to undo accidental sends') and constraints (only within 2 minutes unless bot has admin/owner privileges, cannot recall other users' messages). It implicitly tells the agent not to use it for messages from other users. While it does not explicitly name alternative tools, the context is sufficient for correct selection.
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?
Discloses mutation of wake rule configuration, persistence across restarts, and specifics about keyword and target_id behavior. Aligns with annotations (idempotentHint true) 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured: first sentence states purpose, second clarifies usage with siblings, third gives parameter details. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, persistence, and key parameter semantics. Lacks mention of return value or behavior if rule already exists, but still fairly complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds meaning for target_id ('matches any source') and keywords ('empty list matches any message'). However, target_type and ignore_if_focused are not explained, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a wake rule that activates opencode on matching messages. It differentiates from siblings by naming related tools (list, remove, set_wake_enabled) for other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to create rules) and provides alternatives for other operations (list, remove, toggle). Also clarifies persistence and default behaviors for empty/null parameters.
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?
Adds context beyond annotations: renumbering after removal, permanent deletion. Annotations already mark destructiveHint=true, but description reinforces and explains behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with no wasted words. Front-loaded with action, then steps, then alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main usage and alternatives. Lack of output schema is fine. Could mention error cases (e.g., invalid index) but overall adequate for single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'index' is explained as identifier for the rule. Schema provides no description coverage, but description adds that index is used to select which rule to remove. Could specify starting index (e.g., 0-based) but not essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states removal of wake rule by index. Distinguishes from siblings by referencing list_wake_rules for indices and set_wake_enabled for temporary disable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (permanent delete), prerequisite (list indices), and alternative (use set_wake_enabled for temporary disable).
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?
Describes mutation effect ('Mutates the group by unmuting a member'), idempotency (no-op if already unmuted), and admin privilege requirement. Adds value beyond annotations which already indicate idempotent and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Multiple sentences but each adds essential information (action, parameters, requirements, behavior, alternatives). Front-loaded with main purpose. Could be slightly shorter but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers return behavior (success), idempotency, and prerequisites. Sufficient for a simple mutation tool. Annotations already cover safety and idempotency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds context to both parameters by calling group_id a 'QQ group number' and user_id a 'QQ number', clarifying their meaning beyond the schema's generic titles. Schema coverage 0%, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Unmute a member in a QQ group', providing specific verb and resource. Distinguishes from sibling 'mute_member' by mentioning it. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (when member is muted), when-not (no-op if not muted), prerequisites (admin privileges, check member list via get_group_member_list), and alternatives (mute_member). Comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint; description adds context that it shows specific fields (index, message, cron, etc.) and confirms 'Read-only. No side effects.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the main action. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers what fields are shown (index, message, cron, etc.), making it complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description doesn't need to add param info; it correctly implies no arguments needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all configured timer tasks,' using a specific verb and resource. It distinguishes from sibling tools like add_timer and remove_timer by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly mentions when to use this tool (listing) and provides alternatives: 'Use add_timer to create timers, remove_timer to cancel.'
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?
Adds value beyond annotations: describes blocking behavior, timeout (max 300), return filtering (only others' messages), and explicitly states read-only and no side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with clear sections. Front-loaded with purpose. Every sentence adds distinct value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and siblings, description fully explains behavior, constraints, side effects, and use cases. References sibling tool send_message for combined functionality. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by explaining the timeout parameter and its max value. Implicitly describes target as 'specific group or friend' and target_type via context, though not as precisely as possible. Adds meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it blocks until a new message arrives from a specific group or friend, distinguishes from send_message by noting it returns only others' messages and has a timeout. Differentiates from sibling send_message by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: as a standalone follow-up after send_message with wait_reply=False or when waiting without sending first. Clearly tells when not to use: if sending and waiting in one call, use send_message with wait_reply=True. Provides alternative.
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 indicate destructive and idempotent hints. Description adds key behavioral traits: irreversible for current session, returns error on privileged users, and clarifies reject_add_request behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with action. Each sentence serves a purpose, no redundancy, and efficiently covers all necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (irreversibility, admin privileges, error cases), description covers all necessary context, including effects and alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains all three parameters: group_id, user_id, and reject_add_request, providing meaning and usage context beyond type hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Kick a member from a QQ group' with specific verb and resource. Distinguishes from sibling tool mute_member by emphasizing irreversible nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends mute_member as a less drastic alternative, mentions admin privileges required, and explains limitations (cannot kick group owners/admins).
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/mouse114514/Xadeus-QQ-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server