TapTap Open API MCP Server

Official

by taptap

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.24.11
Disambiguation4/5
Tools are grouped by feature (ads, multiplayer, leaderboard, etc.) with clear prefixes and detailed descriptions. However, many 'get_*_guide' and 'get_*_integration_guide' tools could cause some confusion if descriptions are not carefully read.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_ads_status, create_leaderboard). No mixing of cases or irregular styles.
Tool Count2/5
52 tools is excessively high. While each sub-area is reasonably scoped, the total number overwhelms the agent and suggests poor scoping of the server's responsibilities.
Completeness4/5
The tool set covers major workflows (ads, multiplayer, leaderboard, share, H5 upload, community). Minor gaps exist, such as no update/delete for leaderboards or share templates, but those are noted as requiring developer center.
Average 4.2/5 across 52 of 52 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 70 community issues answered or closed in the last 6 months
- 123 commits in the last 12 weeks
- Last stable release on August 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description explains the intent (prevent inconsistency) but does not describe actual behavior like what the tool returns or how it operates. It lacks typical behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, includes emojis, bold formatting, and repetitive warnings. It is not concise and could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description fails to specify what the tool actually provides (e.g., the template format). It is incomplete in explaining the tool's output or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 applies. The description adds context about protocol importance but does not detail parameter semantics since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does. It focuses on preventing protocol inconsistency rather than explaining that it provides a template. The purpose is ambiguous; it reads more like a guideline than a tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some usage guidance: 'Use when: Starting multiplayer implementation, adding new interaction types.' However, it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It indicates a mutation ('Update') but offers no details on permissions, side effects, validation rules, or whether updates are partial or full replacements. This is insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 20 words, which is concise. However, it includes the vague phrase 'and more' and lacks structured organization (e.g., bullet points or ordering). It is not front-loaded with critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 12 parameters and no output schema, the description is minimal. It does not explain the update behavior (e.g., whether all fields must be provided, order of processing, or return value). For a complex tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters with detailed requirements (e.g., image dimensions). The description adds a general list of fields but no new semantic depth beyond what the schema provides, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Update) and resource (app's information), listing specific fields like name, genre, description, icon, banner, screenshots. This effectively distinguishes it from sibling tools like create_app or get_current_app_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The description simply says 'Update the app's information' without context on when updates are appropriate or scenarios to avoid.
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?
Adds authentication requirement ('MAC Token'), which is beyond schema but lacks other behavioral details (e.g., response format, user scope, rate limits). With no annotations, description partially carries the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear purpose and essential auth note; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and description of return values; for a data retrieval tool, missing details on user scope (e.g., current user vs specific user) and response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions; description does not add further meaning to parameters beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Get') and resource ('user leaderboard scores'), distinguishing it from sibling tools like 'list_leaderboards' which lists leaderboards themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no exclusions or prerequisites beyond authentication (which is behavioral, not usage context).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only implies a read-only check. It does not disclose side effects, authentication needs, rate limits, or whether it modifies state. For a checking tool, more behavioral detail (e.g., 'Read-only, no side effects') would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one header line, bullet list of detections, and usage note. Every sentence adds value. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool with one parameter and no output schema, the description covers what it detects but does not describe the return format (e.g., 'Returns a report with pass/fail and details'). This is a gap given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'The multiplayer code to check'. The description repeats this but adds no new semantics. Since the schema already fully defines the parameter, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check multiplayer code before deployment' and lists specific issues it detects (rate limiting, field names, etc.). It is distinct from siblings like 'diagnose_multiplayer_issues' which likely handles runtime issues, while this is for pre-deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when: Before finalizing code, or when debugging.' Provides clear context. However, no mention of when not to use or alternatives, though the sibling list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, what data it returns, or any side effects. It only lists API names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose and listing APIs. It could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns. It only says 'quick reference', which implies a list but is not explicit. Missing context on how to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add parameter semantics. Schema coverage is 100% (empty). The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides a 'quick reference' of specific extended APIs, which is clear. It lists the APIs and distinguishes usage by mentioning optional features, though it could be more explicit about differentiating from sibling tools like 'get_multiplayer_guide'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (user requests specific features) and notes these APIs are optional, providing clear guidance and avoiding misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool retrieves metrics and supports optional date ranges but does not disclose whether it is read-only, side effects, error behavior if no app is selected, or any rate limits. It is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the prerequisite in bold. It is efficient and no unnecessary words. However, the first sentence could be integrated more smoothly. Still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisites, and a brief summary of return content. However, with no output schema, it does not specify the structure of returned data, which is a gap for agent parsing. For a simple tool, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema as optional dates in YYYY-MM-DD format. The description adds minimal value by referencing an 'optional date range,' which is already implied. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies it retrieves review overview metrics for the currently selected app, including rating summary, score, positive/neutral/negative counts, and trend data. It distinguishes from siblings like 'get_current_app_reviews' by focusing on aggregated metrics rather than individual reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: an app must be selected first. It advises verifying the selected app context before calling. However, it does not explicitly mention alternatives or when not to use this tool, such as when detailed reviews are needed instead of overview.
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?
Discloses that the tool reads app info from cache and returns an error if no app is selected. However, it does not describe any potential side effects, idempotency, or whether uploads can overwrite existing ones. Adequate but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a workflow label, purpose, prerequisite, and error behavior. Information is front-loaded. The parameter details are in the schema, keeping the main description focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite and error handling, but lacks details on return values or post-upload state. Given the simple parameter set, it is moderately complete but could provide more information on the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed parameter descriptions in the schema. The main description only adds context about using the same path from prepare_h5_upload. Baseline score of 3 is appropriate as schema handles the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (upload), the target (H5 game to TapTap platform), and the workflow context (step 2 after user confirmation). Distinguishes itself from prepare_h5_upload as the subsequent step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite: an app must be selected first. Describes error behavior when prerequisite is not met, guiding user to select an app. Provides clear context for when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'unverified', offering minimal behavioral insight. It does not disclose side effects, authentication requirements, or any other behavioral traits expected for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and usage context, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks needed context: no output schema, no annotations. The description does not explain what 'unverified' means, what the tool returns (e.g., developer ID), or error conditions. It is minimally adequate for a simple creation action but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage), so the baseline is 4. The description adds no parameter details but implicitly confirms no input is needed, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new unverified developer identity on TapTap platform'), distinguishing it from sibling tools like create_app or create_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly instructs when to use ('when user wants to create a new developer account'), providing clear usage context, though it does not mention exclusions or 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?
No annotations provided. Description implies read-only behavior via 'Read', and mentions scope constraint but does not disclose error handling (e.g., if no app selected), performance, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a bolded prerequisite. Every sentence earns its place; no redundancy. Front-loaded with critical prerequisite information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return format or structure. All 5 parameters are optional, but coverage is complete in schema. Lacks details on what data is returned, limiting agent's understanding of the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. Description adds no extra meaning beyond schema descriptions, which are already self-explanatory. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Read', resource 'forum contents', and scope 'for the currently selected app only'. It explicitly distinguishes from cross-game browsing, and the context is unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisite ('An app MUST be selected first'), clear when to use (inspect forum feed before summarizing topics), and explicit prohibition ('MUST NOT be used for cross-game browsing'). No alternative tool is named, but context 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?
No annotations provided, so description bears full behavioral burden. It discloses auto-selection behavior, but doesn't cover permissions, error cases, or impact on existing selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded with purpose, followed by behavioral note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 simple params, description provides purpose, usage context, and a key behavioral trait. Could mention return value or errors, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 3 parameters with 100% description coverage. Description adds no additional meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Create' and resource 'new app/game on TapTap platform'. Distinguishes from sibling tool 'select_app' by noting auto-selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when user wants to create a new app', and the auto-selection note implies no need for select_app after. Lacks explicit when-not-to-use but is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it generates files and returns paths/contents, but does not disclose behavioral traits like whether files are overwritten, any side effects, or required permissions. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise, with a clear emoji header, bullet list of generated files, and a use-case sentence. It is front-loaded and avoids unnecessary words, though the emoji may reduce professional tone slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides enough about inputs and outputs. However, it lacks prerequisites (e.g., does it require an existing project?) and does not clarify whether the same code can be generated multiple times. Adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and schema description coverage is 100%. With no parameters to document, the description has no burden. The baseline for 0 params is 4, and no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates complete multiplayer files (js/MultiplayerManager.js and MULTIPLAYER_GUIDE.md) ready to save. It uses specific verbs and resources, distinguishing it from siblings like check_multiplayer_code or diagnose_multiplayer_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'when user wants quick setup, or says generate multiplayer code/生成多人联机代码'. While it does not list when not to use, the context is clear enough for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read operation ('get') but does not disclose authentication needs, rate limits, or caching behavior despite the ignore_cache parameter. The description is not misleading but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no extraneous information. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is fairly complete. It states the tool's purpose and provides example output states (published, under review, rejected). However, it omits details on the return format and the effect of ignore_cache.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the review status of an app/game.' It specifies the resource (app/game) and action (get status), listing possible states (published, under review, rejected). This distinguishes it from siblings like get_current_app_info which covers broader info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: 'Use this to check if the app is published, under review, or rejected.' However, it does not mention when not to use it or suggest alternatives like get_current_app_info for more detailed status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions optional date range and lists returned metrics, but does not clarify authorization needs, error behavior (e.g., if no app selected), or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence front-loads the critical prerequisite in bold, and the second sentence efficiently states the purpose and scope. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (two optional parameters, no nested objects), the description adequately covers the tool's function and output metrics. However, without an output schema, it could better describe the structure of trend data or any pagination, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides (date range), merely referencing 'optional date range' without further detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving community overview metrics for the currently selected app, listing specific metrics like topic count and page views. It distinguishes from sibling tools such as get_current_app_info and get_current_app_review_overview by focusing on community data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description emphasizes a mandatory prerequisite—an app must be selected first—and advises verifying context before calling. However, it does not provide explicit guidance on when not to use the tool or how it compares to alternatives like get_current_app_forum_contents.
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?
No annotations provided, so the description fully bears the burden. It emphasizes that no SDK installation is needed and tap is a global object, which are key behavioral traits. It outlines what the guide covers, but does not describe side effects or output format. Still, it provides adequate transparency for a read-only informational tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and bullet points. The front-loading with '⭐ READ THIS FIRST' and emphasis on key points is effective. Every sentence adds value, though the bullet list could be slightly more concise but still reasonable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is quite complete: it explains what the tool returns (workflow steps), highlights critical details, and lists covered topics. It could hint at the output format (e.g., textual or structured), but overall it provides sufficient context for an agent to use it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. Baseline is 4 for no parameters. The description does not need to explain parameters and does not add parameter-specific information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a complete step-by-step workflow for TapTap Share API integration, specifying verb 'get' and resource 'share integration guide'. It includes a note to read first. However, it does not explicitly differentiate from other integration guides among siblings, but the detail about share API is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this when the user wants to integrate/share/setup/add share functionality and to use it before making implementation plans. This provides clear context for when to invoke the tool, though it does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the need for user confirmation but does not mention error behavior, rate limits, or authentication requirements. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bold emphasis on key points, but slightly verbose with repeated guidance. Most sentences are informative and earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain the return format or fields of leaderboards. It covers prerequisites and usage well but lacks return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds no extra parameter information beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all leaderboards for currently selected app' which is a specific verb and resource. It clearly distinguishes from sibling tools like get_user_leaderboard_scores and publish_leaderboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (app must be selected) and provides step-by-step instructions if not. Also warns against automatically choosing a leaderboard, giving 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states only a single like action is supported, but does not mention side effects (e.g., idempotency, authentication requirements, or if the like can be undone). This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a prerequisite, main action, important note, and constraint. It is concise but could be slightly shorter without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple like action with one parameter and no output schema, the description covers the prerequisite, the need for confirmation, and the single-action limitation. Minor details like result format are missing but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'review_id' has a clear schema description. The description reinforces its purpose but adds no new semantic information beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('like'), the resource ('specific review for the currently selected app'), and the prerequisite (app must be selected). It distinguishes itself from siblings like 'reply_current_app_review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions are given: first identify the review using 'get_current_app_reviews' or showing to the user, then ask for confirmation. Warnings against guessing the review_id are clear, providing strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that both OAuth token file and app cache are cleared, providing clear effects. It could mention if side effects like forced logout occur, but the listed behaviors are sufficient for understanding the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a numbered list. Every sentence adds value: purpose, use cases, and what is cleared. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple clearing tool with two optional boolean parameters, the description covers purpose, when to use, and effects. It does not explain default behavior when both parameters are omitted, but the statement 'This will clear both' implies default clearing of both, which is accurate. Lacks description of return values, but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by stating 'both OAuth token file and app cache' are cleared, which maps to the two parameters, but does not add significant new meaning beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clears 'all cached authentication data and app selection', specifying the verb and resource. It distinguishes from siblings like start_oauth_authorization and check_environment by focusing on clearing, not authentication flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three use cases (MAC token expired, switch accounts, reset authentication) with a numbered list, giving clear when-to-use guidance. It does not explicitly mention when not to use or alternative tools, but the listed use cases imply appropriate contexts.
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?
Without annotations, the description carries the full burden. It states the output (checklist with solutions), but does not disclose whether the tool has side effects, requires permissions, or is read-only. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured, with the purpose front-loaded and bullet-pointed trigger conditions. Every sentence adds value, and the emoji is not distracting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input parameters and no output schema, the description adequately specifies when to use it and what to expect. It could optionally mention the format of the checklist, but it is sufficiently complete for the intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description already covers the intended usage. No further parameter explanation is needed, earning the baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diagnoses common multiplayer issues, listing specific symptoms. It is a specific verb+resource combination that distinguishes it from siblings like 'get_multiplayer_guide' or 'check_multiplayer_code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists user reports that indicate when to use the tool (e.g., 'Players not visible', 'Connection failed'). It does not mention when not to use it or point to alternatives, but the given scenarios provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool creates a persistent reference file, but does not address whether it overwrites existing files, permissions needed, or return behavior. Adequate but has 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a usage directive. All information is front-loaded and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description covers the key points: output file, location, content, and usage timing. Lacks info on return value or error handling, but is largely complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are no parameters (schema coverage 100%), the description adds value by explaining what the tool accomplishes without inputs, which is essential for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates MULTIPLAYER_GUIDE.md in the user project root, with specific content (API rate limits, playerId rules, data structures). It distinguishes from siblings like get_multiplayer_guide or generate_multiplayer_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use at project start,' providing clear timing. While it doesn't list exclusions or alternatives, the context is sufficient for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read-only retrieval of data structures with no side effects. However, it doesn't describe return format, limitations, or permissions. Adequate but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with key information about content and usage. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides adequate context: what data is included and when to use. Could mention if the data is exhaustive or paginated, but sufficient for a reference tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; schema coverage is 100%. Description adds value by explaining what the tool returns, which compensates for no parameters. Baseline for 0 params is 4, and description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves API return value structures and event callback data, listing examples like connect, matchRoom, etc. This differentiates it from sibling tools which focus on other aspects like ads, environment, or app info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when implementing API calls to avoid guessing data structures.' Provides clear context for use. No when-not-to-use mentioned, but not critical for a reference 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?
Discloses caching behavior via ignore_cache parameter, criticality as first step, and indicates it does not modify state (implied by 'get'). Could explicitly state it's read-only, but overall good for no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, uses bold for critical instruction, and organizes usage with numbered points. Slightly verbose with the general label, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists returned fields but does not specify return format, error conditions, or how to interpret 'no app selected' state. For a tool that gates other operations, more detail on return value would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter (ignore_cache) with full description. The tool description does not add extra meaning beyond the schema, but the baseline is appropriate due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves current selected app/game information with specific fields (developer_id, app_id, miniapp_id, app name). Differentiates from siblings by emphasizing it's a prerequisite for leaderboard operations and other tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (before leaderboard ops, building preview links, verifying cached app) and when not to (H5 upload workflow). Also instructs on alternative flow if no app selected, referencing sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a guide with code template and lists built-in features. However, it does not mention any authentication requirements, rate limits, or potential side effects, though the tool appears read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (core concept, returns, built-in features, usage). It is informative without being overly verbose, though slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides comprehensive context about the tool's purpose, usage, and contents (code template, debug logger, error codes, etc.). It fully answers what the tool does 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined in the schema, so the baseline is 4. The description adds meaning by explaining what the tool returns and the core concept, compensating for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the primary entry for multiplayer guides, defines the core concept with a concrete example, and lists what is returned (complete guide with code template). This distinguishes it from sibling tools like get_multiplayer_code and diagnose_multiplayer_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use when: User wants players to play together...' and mentions it's for any creative H5 game. However, it does not provide explicit when-not-to-use guidance or mention alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses one key behavior: 'NO SDK installation - tap is global object'. However, it lacks details about authentication, rate limits, or potential side effects, leaving gaps in transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but each sentence adds value, especially the front-loaded usage directive. Some redundancy in listing synonyms for vibrate, but overall well-structured and not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a guide tool with no output schema, the description states it returns a 'complete step-by-step workflow' and highlights a critical fact (no SDK). However, it does not detail the content of the guide (e.g., code examples, troubleshooting) which would improve completeness. The tool is simple, but more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds value by explaining what the tool returns (complete step-by-step workflow) beyond the empty schema, but since no parameters exist, additional parameter details are not relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a step-by-step workflow for vibrate/haptic feedback integration, using specific verbs and resource. It distinguishes from sibling tools by explicitly targeting vibrate-related queries and instructing to use this tool first for such topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE THIS TOOL FIRST' and 'Call this BEFORE making any implementation plans', providing clear when-to-use guidance. It lists many related keywords (vibrate, vibration, haptic feedback) and implies alternatives for other topics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns a QR code URL for scanning with the app, but does not detail side effects like creating a pending authorization record or any state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences. Each sentence earns its place: purpose, use cases, return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers the essential: what it does, when to use, and what it returns. It could mention prerequisites (e.g., app must exist) but is adequate for a start tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% trivial. The description adds value by explaining the return (authorization URL/QR code) which gives context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Start' and the specific resource 'OAuth 2.0 Device Code Flow' with the outcome 'get authorization URL'. It distinguishes from the sibling tool 'complete_oauth_authorization' by indicating this is the initiation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists three explicit use cases: explicit authorization, login/account switch, and token expiry. It provides clear context for when to use, though it does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the action (upload), accepted inputs (file path or base64), and outcome (get a URL). It does not mention authentication, rate limits, or side effects, but for a simple upload tool this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. All information is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description is mostly complete. It explains the input choices and the return (URL), though it could specify the URL format or any additional return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explicitly noting that filePath and base64Data are alternatives, and connecting the tool's purpose to the parameters (icon, banner, screenshots).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: upload an image to TapTap server and get a URL. It specifies image types (icon, banner, screenshots) and the workflow context (before calling update_app_info), distinguishing it from sibling tools like upload_h5_game.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to upload icon, banner, or screenshots before calling update_app_info.' It does not explicitly mention when not to use or alternatives, but the context is sufficient for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: auto-fetches developer_id and app_id, returns template_code, enforces a 21 UTF-8 character limit on contents, and requires audit approval (status=1). The description does not explain error scenarios or side effects, but for a creation tool, it covers essential operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with bolded sections and front-loaded prerequisite. Every sentence adds necessary context (prerequisite, creation purpose, auto-fetch, character limit, audit requirement). No redundancy, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and lacks annotations, the description covers the input process, return (template_code), and critical constraints. It does not detail error handling or the audit process, but for a creation tool with clear steps, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value: explains auto-fill for optional IDs, notes that remark is internal and not shown to users, provides an example for contents, and emphasizes the strict character limit. This exceeds mere schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new share template on TapTap server for minigame sharing feature.' It specifies the resource (share template) and action (create), and distinguishes from sibling tools like list_share_templates or get_share_template_info by emphasizing creation and the resulting template_code used in client-side API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite: 'An app MUST be selected first' and provides step-by-step guidance on verifying selection and guiding the user. It also notes important constraints (audit approval, character limit). However, it does not explicitly mention when not to use the tool or compare to alternatives, which would elevate the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries the burden. It lists the metrics returned, which adds some behavioral context, but it does not disclose whether the operation is read-only, what happens if no app is selected (error?), any rate limits, or authorization requirements. It is adequate but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loads the prerequisite in bold. Every sentence provides value. It is slightly wordy in the prerequisite workflow, but overall efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 simple optional params, no output schema), the description covers purpose, usage context, prerequisite workflow, and return metrics. It is largely complete but lacks behavioral transparency details like error handling or safety guarantees.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for start_date and end_date. The description adds that these are optional and affect 'daily trend data', which enriches the meaning. It does not repeat schema details but provides context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves store overview metrics for the currently selected app, listing specific metrics (page views, downloads, reserves, etc.) and optional date range. The verb 'get' and resource 'store overview' are specific, and the description distinguishes from siblings by requiring a selected app and referencing related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (app must be selected) and provides a detailed workflow: call get_current_app_info first, and if no app is selected, guide user through list_developers_and_apps, show list, ask user, call select_app. This is exemplary guidance for when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions returning 'relevant documentation snippets and suggestions' but does not disclose behavioral traits like read-only nature, auth requirements, or rate limits. Adequate for a search tool but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with bullet-point style, no wasted words. Front-loaded with clear purpose, then use cases, then return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required parameter, no output schema), the description adequately covers its functionality, use cases, and return type. No additional information needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a minimal description ('Search keyword (REQUIRED)'). The tool description adds value by providing concrete examples (e.g., 'showShareboard', 'onShareMessage') and usage context, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Share API documentation by keyword, with specific verb and resource ('Search Share API documentation'). It distinguishes from siblings by mentioning share API 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists three usage scenarios (user asks about share API, need specific docs, looking for code examples). While not specifying when not to use or naming alternatives, the guidelines are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the caching side effect ('will cache the selection for all modules') and the critical user confirmation constraint. It does not mention auth or rate limits, but the caching and confirmation guidance are sufficient for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a few sentences covering purpose, important note, and use cases. It is front-loaded with the core action and avoids fluff, though slightly repetitive in listing use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description adequately covers purpose, usage guidance, behavioral impact (caching), and when not to call. It could mention return value or errors, but the core context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond what the schema already provides for developer_id and app_id. The baseline of 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Select a specific developer and app to use for subsequent operations' with a specific verb and resource. It distinguishes itself from sibling tools by mentioning caching across modules and listing use cases like switching accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions are provided: 'Only call this tool AFTER the user has explicitly confirmed which app they want to use. DO NOT call this tool automatically without user confirmation.' It also gives when to use (general selection, switching accounts, after listing) and an alternative for H5 upload.
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?
No annotations provided, so description carries full burden. It discloses auto-fetching of developer_id and app_id, and mentions return value. However, it does not mention potential side effects, error cases, or required permissions, which would elevate it to 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a prerequisite note. Every sentence adds value: prerequisite check, action, auto-fetch behavior, return value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, description covers purpose, prerequisite, key behaviors, and return value. Lacks error handling or limitations, but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds context about auto-fetching developer_id and app_id, but does not elaborate on parameter options beyond what schema provides. No additional semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new leaderboard on TapTap server' with a specific verb and resource. It distinguishes from siblings like list_leaderboards, publish_leaderboard, and get_leaderboard_integration_guide by focusing on creation and auto-fetching 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite that an app must be selected and provides step-by-step guidance to call get_current_app_info, list_developers_and_apps, and select_app if needed. Also clarifies that it returns leaderboard_id for client-side APIs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does not disclose any behavioral traits like side effects or auth needs, but being a read-only workflow retrieval tool with no prerequisites, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, use of emphasis (bold, emoji), and bullet points for workflow steps. Some repetition in the critical note could be trimmed, but overall it is effective and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and no output schema, the description fully explains what the tool does, when to use it, and what the workflow covers. It is contextually complete for an AI agent to decide to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds no parameter information. With 100% schema coverage and no params, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete ads integration workflow and explicitly marks it as the first step for any ads-related request. It distinguishes from siblings like get_ad_integration_guide and check_ads_status by being the mandatory initial call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('call this BEFORE making any implementation plans or writing any ad code') and that it has no prerequisites. The critical note emphasizes it MUST be followed for any ads request, providing unambiguous usage guidance.
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?
Although no annotations are provided, the description discloses the guide's contents (timer-based sync pattern, change detection). Since the tool is a simple 'get' operation, it is assumed safe and read-only. The description adds useful behavioral context beyond what structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and immediately provide usage guidance. Every word adds value, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is nearly complete. It details the guide's content and usage context. It could optionally mention the output format, but it's not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter schema is trivially covered. The description adds no parameter details, but none are needed. The baseline score of 4 is appropriate as the description does not detract from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a synchronization strategy guide for specific control types (joystick/WASD, click-based movement). It uses a specific verb ('Get') and identifies the resource, distinguishing it from sibling guide tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when implementing position synchronization or continuous input handling.' While it doesn't mention alternatives or when not to use, the context is clear and sufficient for the AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool alters leaderboard visibility (publish or whitelist-only) and includes critical behavioral instructions (do not auto-select). It does not mention potential side effects like irreversibility or permission requirements, but the provided context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each adding essential information: prerequisite, purpose, and a safety warning. It uses bold for emphasis and front-loads the requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, the description provides complete context: what it does, prerequisites, how to resolve ambiguous IDs, and parameter meaning. It lacks only return value info, which 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds behavioral context (e.g., 'publish=true means public') but does not extend beyond schema definitions. The value is in the prerequisite and warning, which indirectly clarify usage of 'id' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes a leaderboard or sets it to whitelist-only mode. It uses a specific verb ('Publish') and resource ('leaderboard'), but does not explicitly distinguish from sibling tools like 'create_leaderboard' or 'list_leaderboards'. However, the action is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: 'An app MUST be selected first' and directs to 'get_current_app_info' if not. It also advises calling 'list_leaderboards' to clarify the ID and instructs to ask the user rather than auto-selecting. This is exemplary guidance for when and how to use the 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?
Discloses polling behavior and side effect (saving token), which is sufficient given no annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded [Auth] tag. Every sentence provides value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a zero-parameter polling tool: purpose, usage context, and behavior are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (complete OAuth authorization after QR scan), context (user confirms in browser), and differentiates from sibling tool start_oauth_authorization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call this tool (after user confirms authorization in browser), but does not mention when not to use it or alternatives, though alternatives are unnecessary.
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?
No annotations are provided, so the description carries full burden. It describes the tool's return value (guide + usage) and features of the debug logger. It mentions file copying as an AI action, not tool side effect. However, it does not explicitly state that the tool is read-only or non-destructive, which would be ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header, trigger list, features, and return info. It is concise but includes only essential details. Slightly longer than necessary due to multilingual strings, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides sufficient context: triggers, features, return value, and recommended use cases. It could clarify whether the tool itself copies files or just recommends it, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered. The description does not need to add parameter semantics. Following the rule for 0 parameters, baseline score is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an on-screen debug logger, with explicit trigger phrases in multiple languages. It is distinct from all sibling tools, which focus on ads, environment, multiplayer, etc. 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit list of user requests that should trigger this tool, covering multiple languages and use cases. It also specifies ideal contexts (H5 games, mobile testing, non-technical users). No explicit when-not-to-use, but the triggers are comprehensive.
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?
No annotations provided, so description carries full burden. It highlights that no SDK installation is needed (tap is global object) and that it returns a workflow. It implies a read-only, non-destructive operation, which is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (3 sentences) and front-loaded. The use of emoji and capitals may be slightly excessive, but it effectively emphasizes key points. Could be marginally more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states 'returns complete step-by-step workflow,' which is adequate for a guide retrieval tool. It provides enough context for the agent to understand the tool's purpose and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds value by explaining the content (step-by-step workflow) and usage priority. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a 'complete step-by-step workflow' for leaderboard integration, using a specific verb ('get') and resource. It distinguishes from sibling tools like 'get_ad_integration_guide' by focusing on leaderboard setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit directives: 'READ THIS FIRST' and 'Call this BEFORE making any implementation plans.' This tells the agent exactly when to use this tool, providing strong contextual guidance.
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?
No annotations are provided, so the description bears full burden. It transparently describes that the tool is a guide providing instructions, not an action tool. It discloses the nature of the content (how to get player ID, check identity, handle field names). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with an emoji and a concise list of topics. It is front-loaded with the core purpose and has no wasted words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a guide with no parameters and no output schema, the description is complete. It explains what topics are covered and when to use it. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is trivially 100%. The description does not need to add parameter information. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a usage guide for getting player ID, listing specific topics like retrieving local player ID from connect(), checking identity, and handling field name differences. It distinguishes itself from sibling tools which are mostly other guides or technical actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when implementing player identification logic or debugging player-related issues.' This provides clear context, though it does not mention when not to use or alternatives. Given sibling tools are different guides, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the read-only behavior (getting info), output fields (status, contents, remark, audit_reason), and prerequisite. It does not contradict any annotations (none present). Lacks explicit statement that it does not modify data, but it's strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded prerequisites, important notes, and bullet-pointed use cases. It is slightly verbose but every sentence adds value. Front-loading of prerequisites helps agent prioritize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists key return fields (status, contents, remark, audit_reason) and provides context on when to use each aspect. It also covers the prerequisite and relationship with sibling tools, making it complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for 3 parameters. Description adds meaningful context: template_code is required and used as templateId in client API; app_id and developer_id are optional and auto-filled. This provides value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get detailed information') and resource ('specific share template by template_code'), and distinguishes from sibling tools like list_share_templates by focusing on a single template's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite (app must be selected, referencing get_current_app_info), provides clear when-to-use scenarios (check audit status, get template_code details, view audit reason, verify approval), and advises when to use sibling tool list_share_templates first if template_code is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses auto-fetching of IDs, status codes, and directs modifications to an external site. While it does not explain error behavior on missing app or rate limits, it provides sufficient transparency for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers for prerequisites, important notes, and a clear call-to-action for user confirmation. Every sentence adds value, and the format is front-loaded with critical usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should cover key output fields. It mentions status codes but does not describe other return fields (e.g., template name, ID, creation date). This leaves the agent uncertain about what data the response contains, making it partially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds value by explaining auto-filling of developer_id and app_id from context, which is not in the schema. This supplements parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists all share templates for the currently selected app, differentiating it from single-template retrieval (get_share_template_info) and creation (create_share_template). The verb 'List' and resource 'share templates' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (app must be selected), a mandatory pre-call to get_current_app_info, and a step-by-step process if no app is selected. It also warns against automatic selection when multiple templates exist, directing user interaction. This is exemplary guidance.
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?
No annotations are provided, so the description carries the full burden. It clearly lists the internal steps: verifying the game project directory, reading app info from cache, and returning confirmation info. It does not mention auth requirements or rate limits, but it is transparent enough for a preparatory step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, but it is somewhat verbose, particularly in the prerequisite explanation. However, every sentence adds value, and the structure aids clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions that it returns 'confirmation info for user to review', but does not detail what that includes. However, it covers the workflow, prerequisites, and next steps adequately for a preparatory tool among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema. For genre, it explains how to determine the genre if not specified, including analysis of game files. For gamePath, it clarifies the relative path requirement and provides example correct and wrong paths.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is Step 1 of the H5 game upload workflow, used when the user wants to publish/upload/deploy H5 games. It distinguishes itself from sibling tools like upload_h5_game and others by specifying its role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool, the prerequisite of having an app selected, and provides a clear step-by-step process for handling the case when no app is selected. It also mentions the next tool to call (upload_h5_game) after gathering info.
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?
No annotations provided, so the description fully discloses behavior: lists core methods (sendData, onDataReceived, etc.), features (rate limiting, offline fallback), and file size. This exceeds expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with emoji and bullet points, making it scannable. It is longer than necessary but every sentence adds value—purpose, methods, features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description fully covers the tool's purpose, content of the returned template, and features. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so baseline is 4. The description does not need to add parameter info but effectively explains what the tool returns (the template).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Get complete MultiplayerManager.js template (350+ lines)', clearly identifying the verb (Get), resource (template), and scope. It distinguishes from sibling tools like 'get_multiplayer_guide' and 'generate_multiplayer_code' by emphasizing it's a ready-to-use template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Copy-paste ready. Use for ANY game type', providing clear context for when to use. However, it does not explicitly mention when not to use or compare with alternatives like 'generate_multiplayer_code'.
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?
No annotations are provided, so the description carries the full burden. It correctly implies a read-only operation via the name and context, but does not explicitly state safety or output details. However, it adds useful behavioral context about supporting sort, pagination, collapsed reviews, and platform filter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the critical prerequisite, every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow context and parameter intent. However, since there is no output schema, a brief note about the return format would improve completeness, but the current description is still adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by summarizing the parameter groups (sort, pagination, collapsed, platform filter) and tying them to the workflow, which is helpful beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'reviews for the currently selected app', distinguishing it from sibling tools like 'reply_current_app_review' or 'like_current_app_review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite 'An app MUST be selected first' and the recommended context 'Use this before like/reply actions so the user can inspect the review list and confirm the target review_id', providing clear when-to-use guidance.
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 discloses default parameter values, file save locations, and the forced read-only behavior when moment_id is provided. However, since no annotations are present (e.g., readOnlyHint, destructiveHint), the description carries full burden and could still mention potential side effects like rate limits, but it adequately covers the main behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (prerequisite, default behavior, calling policy) and includes front-loaded summary. Although it is somewhat verbose, every section adds essential context and earns its place, making it well-organized and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, important prerequisites, and no output schema), the description covers all necessary aspects: prerequisites, default behaviors, parameter interactions, and agent policies. It could provide more detail about the output format or specific error handling, but it is sufficiently complete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have 100% schema description coverage, and the description adds significant context beyond the schema: it explains moment_id accepts both numeric IDs and full URLs, clarifies that status is ignored when fetch_and_mark_processed=true, and provides default values and usage policies for fetch_and_mark_processed and download_assets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: pulling debug feedback records, downloading artifacts, and generating AI-ready debug context files. It distinguishes itself from the numerous sibling tools (e.g., check_ads_status, get_current_app_info) by focusing on debug feedback operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive usage guidelines are provided: a prerequisite (app must be selected), a specific calling sequence involving get_current_app_info, list_developers_and_apps, and select_app, default behaviors, and a detailed calling policy for agents regarding the fetch_and_mark_processed parameter when handling moment_id or read-only requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns client config snippets and agent steps, does not modify files, and implies a safe read operation. It could have mentioned prerequisites, but overall it provides good behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is front-loaded with purpose and usage. Every sentence adds value. It could be slightly more structured, but it is efficient and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a guide with two parameters, both documented in schema), the description is complete. It states the return type (snippets and steps) and explicitly says it does not modify files. No output schema is needed, and no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the default behaviors (current package without tag for package_tag, and rnd default for target_environment) beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a setup guide explaining how to switch environments, using specific verbs and resources. It distinguishes itself from sibling tools by being the only guide about environment switching, and it explicitly lists triggering user phrases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies when to use the tool: when the user asks to switch environment, use RND, test in RND, configure TAPTAP_MCP_ENV, or asks about RND credentials. It also mentions what it does not do (modify files), providing clear usage boundaries.
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?
Describes what it checks and implies read-only behavior. No annotations, but description gives good insight. Could be more explicit about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description fully covers what the tool does and provides a clear alternative for related questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Description adds meaning by listing the configuration items checked, which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks environment configuration and authentication status with specific items listed. Distinguishes from sibling by mentioning get_environment_switch_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to verify config) and when not (for switching environments, call get_environment_switch_guide).
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?
No annotations provided, but description fully discloses the tool's output: workflow, file system operations, cloud archive operations, error codes, best practices, code examples. Read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and a usage section. Every sentence adds value, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No parameters, no output schema, no annotations, but description fully covers what the tool provides and when to use it. Complete for a guide tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline is 4. Description adds meaning by explaining the tool's purpose beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a 'Cloud Save integration workflow guide' for TapTap Minigame and H5 games. Verb 'Get' and specific resource distinguish it from sibling guide tools like get_ad_integration_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use: 'Use this tool when user asks about...' with four specific scenarios, providing clear guidance vs. alternatives.
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?
Since no annotations are provided, the description fully covers behavioral aspects: it queries server, updates local cache, returns status codes, and warns about potential server-side issues. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured with headings and bullet points. It is front-loaded with step and prerequisite. Some redundancy could be trimmed, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (status, space_id, guidance URL) and provides context on how to proceed based on statuses, including edge cases. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, so baseline is 4. The description adds no parameter information, but none is needed. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as checking ads SDK activation status and caching ad space ID, part of a workflow (Step 2). It distinguishes from sibling tools by specifying its role in the Ads Workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to call (first time, user refresh), when not to call (do not auto-poll), and a prerequisite (must have app selected, with alternative tool named). Also gives behavior for different status codes.
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?
With no annotations, the description fully discloses that this is a static reference table, not an action. It details content (mapping of calls to events and recipients) and warns about the difficulty of showing this in code, ensuring the agent understands it's informational.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured with a heading, bullet points, and clear sections. It is front-loaded with a critical warning. Some redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema reference tool, the description is thorough. It explains purpose, content, use cases, and gives concrete examples. No gaps remain for the agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds no parameter info because none are needed. Schema coverage is 100% trivially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows the API-to-Event relationship table, specifying which call triggers which event and who receives it. It distinguishes this from sibling tools by emphasizing it as a reference for implementing event handlers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use when: Implementing multiplayer logic, debugging why no event triggered?' and provides key relationship examples, giving clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It explains the prerequisite and the return content (a comprehensive snapshot). The tool is read-only by nature (get), but it does not explicitly state that it has no side effects. Still, the behavioral context is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first is a critical prerequisite note, the second lists the return contents. No unnecessary words, and front-loads the most important usage condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the types of information in the snapshot (e.g., app card info, stats, rating summary, trend, version status, visibility). It also covers the prerequisite for using the tool. This is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description's job is trivial. However, the description adds value by explaining what the snapshot includes, which is more than the schema provides. Baseline for 0 params is 4, but the extra context justifies a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets a store snapshot for the currently selected app, listing specific included data (app card info, stats, rating summary, 30-day trend, version status, visibility). This distinguishes it from siblings like get_current_app_info or get_current_app_review_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisites are provided: an app must be selected first, and the user is guided to call get_current_app_info and, if needed, a sequence of steps including list_developers_and_apps and select_app. This tells the agent exactly when and how to use the tool.
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?
No annotations provided, so description carries full burden. It explains pagination behavior (paged preview, total counts, offset/limit) and includes a critical instruction about user confirmation. It fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with a bold critical instruction. Every sentence adds value, and it is front-loaded with key actions. Could be slightly trimmed but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format (paged preview, total counts) and how to paginate. It covers all necessary context for a list tool, including user interaction guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds meaning by explaining that limit controls the preview size and offset skips entries, with context about paged responses, beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists developers and apps/games for the current user, distinguishing it from sibling tools by explicitly mentioning to use prepare_h5_upload for H5 game upload. It provides specific verb and resource 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (initial exploration, switching apps, general app management) and when not to use (H5 upload, directing to prepare_h5_upload). It also gives a critical instruction to show preview to user and ask for confirmation, aiding correct invocation.
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?
No annotations provided, so description carries full burden. It discloses risk grading behavior (server applies risk, returns draft for MEDIUM/HIGH, requires confirmation) and that the tool sends as official app identity. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold headings for prerequisites and critical notes. Concise yet covers all essential points without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema. Description explains risk grading and confirmation flow, which is complete for a reply tool with potential drafts. Misses return type details but covers critical behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning: explains confirm_high_risk should only be set after explicit approval, and contents is the official reply. This provides context beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reply to a specific review as the official app identity.' This distinguishes it from sibling tools like 'like_current_app_review' and 'get_current_app_reviews', specifying the verb 'reply' and the resource 'review'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites: 'An app MUST be selected first.' and critical guidance: 'Always make sure the user has reviewed and approved the reply content before calling this tool.' Also explains risk grading and when to set confirm_high_risk.
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?
Even without annotations, the description discloses key behaviors: it reads cached space_id, returns code with callback pattern, and provides onReward() interface. No contradictions or hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (prerequisites, generated content, critical notes). Every sentence adds value, and the most important info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: prerequisites, output content, pattern constraints, and warning not to search the web. No missing details given the tool's simplicity (no parameters, no output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description does not need to add parameter info, but it implicitly explains the input is the cached space_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get complete ads integration code guide with actual ad space ID.' It identifies itself as Step 3 of Ads Workflow, distinguishing it from sibling tools like check_ads_status or get_ads_integration_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists two prerequisites that must be met before calling, with specific error handling if they are not met. It also instructs 'DO NOT search the web,' providing clear usage boundaries.
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:

[![instant-games-open-mcp MCP server](https://glama.ai/mcp/servers/taptap/instant-games-open-mcp/badges/card.svg)](https://glama.ai/mcp/servers/taptap/instant-games-open-mcp)

Score Badge

Copy to your README.md:

[![instant-games-open-mcp MCP server](https://glama.ai/mcp/servers/taptap/instant-games-open-mcp/badges/score.svg)](https://glama.ai/mcp/servers/taptap/instant-games-open-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/taptap/instant-games-open-mcp'

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