神岛数据统计 MCP 服务器

Server Quality Checklist

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

Latest release: v0.0.4
Disambiguation4/5
Each tool targets a distinct data entity (map info, comments, lists, stats), but getMapInfoByUserId and getMapReleaseInfoByUserId could be confused, as could getMapCommentListByUserId and getCommentList. Overall, scope is clear.
Naming Consistency4/5
All tools use the get prefix and camelCase, generally following get<Resource>By<Parameter>. Some tools like getMapStatList and getMapPlayerStatList deviate from the By pattern, but the naming is still predictable.
Tool Count3/5
19 tools is within the 16-25 heavy range; for a data retrieval server this is reasonable, though it could potentially be streamlined.
Completeness4/5
Covers user profiles, social lists, map/model data, statistics, and user interactions. Missing model details and leaderboard data, but core statistics workflows are covered.
Average 3.1/5 across 19 of 19 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only restates the schema requirement for token and userAgent, adding no information about side effects, pagination, ordering, or error handling. This does not exceed the schema's structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is not verbose or poorly structured. However, it is under-specified for the tool's complexity, which slightly reduces efficiency in conveying purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four required parameters and no output schema, yet the description offers minimal context. It does not explain the type of comments, the user scope, pagination behavior, or potential use cases relative to sibling tools, making it inadequate for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters, so the baseline is 3. The description only mentions token and user请求头, which are already documented in the schema, and adds no additional semantic value for offset or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets a comment list ('获取用户的评论列表'), which is a clear verb+resource, but it does not specify whose comments (current user vs. a specific user) and does not differentiate it from the sibling tool getMapCommentListByUserId. This ambiguity prevents a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like getMapCommentListByUserId or getLikeList. It only mentions authentication requirements, which is a prerequisite, not a 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?
With no annotations, the description must disclose behavioral traits, but it does not explain what data is returned, how 'behavior' is defined, or any operational details such as pagination or rate limits. It only repeats parameter requirements, leaving the tool's behavior opaque.
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 concise sentence, making it easy to parse. However, this brevity leaves out critical context and behavioral details, so while it is efficient, it is under-specified for the tool's complexity.
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?
There is no output schema, so the description has a responsibility to indicate what the tool returns; it does not. With five required parameters and no explanation of the result or the meaning of 'behavior', the description is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing definitions for all five parameters with examples. The description merely restates that Token, userAgent, and mapId are required, adding no new semantics beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool '获取神岛平台用户地图玩家行为' (gets user map player behavior on Shendao platform), which identifies a specific verb and resource. However, 'behavior' is vague and not distinguished from sibling tools like getMapPlayerStatList or getMapPlayerRetention, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only lists authentication requirements (Token, userAgent, mapId) without any contextual usage or exclusions, so the agent receives no decision support.
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?
Annotations are absent, so the description must disclose behavior itself. It only repeats the required credentials already present in the schema, and omits return format, error behavior, rate limits, or side effects, leaving agents uninformed for a data retrieval operation.
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 concise sentence, front-loaded with the main action. However, it omits crucial context like return values and usage scenarios, making the brevity borderline under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and five required parameters, the description should explain purpose and behavior more thoroughly. It fails to define 'retention', document return values, or clarify distinctions from sibling tools, making it incomplete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a label and date examples. The description's mention of 'Token, 用户请求头, 地图ID' adds no meaning beyond the schema, so the baseline 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 uses the verb '获取' (get) with a specific resource '神岛平台用户地图玩家留存' (Shendao platform user map player retention), clearly identifying the tool's function. It does not explicitly mention alternatives, but the unique 'retention' concept differs from siblings like getMapPlayerStatList.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only lists prerequisites (Token, user request header, map ID) and gives no guidance on when to use this tool rather than other map analytics tools. No exclusions, contexts, or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'get list' without mentioning authentication, pagination behavior, rate limits, or return format. The read-only nature is implied by the name but not elaborated, offering minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that clearly states the primary function without redundancy. The structure is efficient and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 required parameters and no output schema, the one-sentence description is insufficient. It fails to explain the relationship between contentId and contentType, note that all parameters are required, or provide any context about the response format or usage conditions. The name/description ambiguity further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 5 parameters with useful details like max limit and orderBy codes, meeting the baseline. The description adds little beyond restating the use of map ID, so it provides marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of map comments using the map ID, which is a specific verb and resource. It distinguishes from generic comment tools like getCommentList, but the tool name mentions 'ByUserId' while the description focuses on map ID, creating slight ambiguity about the intended scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as getCommentList or getMapListByUserId. The description only states what the tool does without explaining the appropriate use case, prerequisites, or exclusions.
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, the description carries full disclosure burden. It does not mention read-only nature, permissions, rate limits, or any side effects. The name suggests 'ByUserId' but the parameter is mapId, creating ambiguity that is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose without irrelevant filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description is too terse to be fully complete. It does not describe the return values, what 'details' include, or clarify the mismatch between the tool name (ByUserId) and the actual parameter (mapId), leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with mapId described as '地图ID'. The description repeats 'using map ID' without adding extra meaning about format, constraints, or behavior. This matches the baseline for full schema coverage.
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 a clear verb+resource: '获取神岛平台地图详情' (get map details) with the method '使用地图ID' (using map ID). It distinguishes the action from sibling tools like list-oriented ones, though 'details' vs. 'release info' is not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states the function without mentioning prerequisites, exclusions, or scenarios where other map-related tools would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals nothing about pagination behavior, result limits, sorting semantics, or return format, offering only a high-level 'search' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for the level of detail provided, though it omits important contextual 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?
The tool has no output schema and no annotations, so the description must compensate by explaining return values or behavioral constraints. It does not, making the description incomplete for an agent to invoke the tool with confidence.
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 parameters are fully documented. The description adds no extra meaning beyond the schema, but the schema already provides adequate parameter semantics (e.g., 'offset', 'limit', 'keyword', 'orderBy').
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 ('search and retrieve') and the resource ('map/model list on Shendao platform'), which distinguishes it from sibling tools that fetch lists by user ID. However, it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any context, exclusions, or prerequisites, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions authentication needs (Token and userAgent), but this merely repeats the schema. It does not state whether the operation is read-only, what data is returned, or any side effects. The absence of additional behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It conveys the core purpose and required inputs efficiently, though it is slightly under-specified, which is not a conciseness failure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 required parameters, no output schema, and no annotations. A single sentence of description is insufficient to understand the return format, pagination, or exact meaning of 'player statistics'. The schema partially covers parameters, but overall context is lacking for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and parameter descriptions already explain the purpose of each field (e.g., startTime with example date). The description adds no new semantic meaning beyond the schema, so the baseline 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 states it retrieves player statistics for a map on the Shendao platform ('获取神岛平台用户地图玩家统计'), which is a clear verb+resource combination. However, it does not differentiate from sibling tools like getMapStatList or getMapPlayerBehavior, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only lists required inputs ('需Token和用户请求头和地图ID') and does not explain when to use this tool versus alternatives like getMapStatList or getMapPlayerRetention. No explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states a basic 'get' operation. It does not mention whether this is a read-only operation, any required permissions, or what kind of data will be returned. The description adds no behavioral context beyond the obvious read operation implied by the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise without unnecessary words. However, it is under-specified in terms of clarity, but this dimension focuses on appropriate sizing and front-loading, which it satisfies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and lack of output schema, the description should explain the tool's role clearly. It fails to clarify the discrepancy between the tool name 'ByUserId' and the actual parameter 'contentId' (map ID). It also doesn't hint at what 'release info' includes, making the description incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the schema (limit, offset, contentId). The description only says 'use map ID', which mirrors the schema's '地图ID' description for contentId. It adds no additional meaning, so the baseline 3 is appropriate; the schema already provides full parameter semantics.
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 provides a specific verb (获取/get) and resource (地图发布信息/map release info), and it specifies the input method (使用地图ID/use map ID). This distinguishes it from sibling tools that list maps by user ID, comments, favorites, etc. However, the term '发布信息' is slightly vague, and the tool name says 'ByUserId' while the description says to use map ID, introducing ambiguity about the actual input key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or relationships to sibling tools like getMapInfoByUserId or getMapCommentListByUserId. There is no context about which scenarios call for this 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?
With no annotations, the description must disclose behavioral traits. It only restates authentication requirements already present in the schema (token, userAgent) and provides no detail on output formatting, pagination, side effects, or operational behavior. No added context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main verb and resource, and contains no filler words. It is concise, though it sacrifices detail for brevity in a way that affects other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-returning tool with no output schema and no annotations, the description is under-specified. It does not clarify what 'statistics' includes, the result structure, ordering, pagination, or any operational details needed for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all four parameters documented, so the baseline is 3. The description does not add any parameter semantics beyond the schema; it simply mentions token and userAgent, which are already described.
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 the tool retrieves a user map statistics list from the Shendao platform ('获取神岛平台用户地图统计列表'). It uses a clear verb+resource, but it does not distinguish from sibling tools like getMapPlayerStatList, leaving potential ambiguity about the exact type of statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The only additional note ('需Token和用户请求头') merely repeats schema requirements and does not address selection criteria, exclusions, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only states the basic operation. It does not mention pagination behavior, the maximum limit of 100, return format, authentication requirements, or any potential side effects, making it insufficient for a read 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 a single concise sentence, front-loaded with the key action and resource. It contains no filler and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too sparse. It does not clarify that the favorite list can contain both maps and models, how pagination works, or what the return structure is. For a list retrieval tool with four required parameters, this lack of context is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all four parameters (limit, offset, userId, contentType) documented with descriptions. The tool description adds no extra parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's favorite list on the Shendao platform using a user ID. It uses a specific verb (获取) and resource (收藏列表), and it is distinguishable from sibling tools like getMapListByUserId and getModelListByUserId which focus on user's published content rather than favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or competing sibling tools, leaving the agent without context for selecting it appropriately.
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 present, so the description carries the transparency burden. It does disclose an authentication requirement (Token and user request header), which is useful operational context. However, it does not state whether the list is for the authenticated user only, how pagination behaves, or what response shape is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource while also mentioning the key auth requirement. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves important context undefined: whose like list is returned (token owner vs any user), what the response contains, and how offset/limit pagination works. The sibling tools all use byUserId, so the absence of a userId parameter makes the target user ambiguous.
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 explains all four parameters. The description only repeats Token and userAgent and adds no semantic detail beyond the schema, such as offset/limit behavior or the meaning of 'userAgent'.
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 a get operation on a specific resource ('点赞列表' / like list) for the Shendao platform, using '获取'. It does not explicitly distinguish this from sibling list tools such as getFavoriteListByUserId or getRecentlyPlayListByUserId, but the resource name itself is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over sibling tools, nor are exclusions or prerequisites beyond the mention of Token and userAgent. The usage context is only implied by the tool name and the resource term.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'get list' with no mention of side effects, required permissions, pagination behavior, rate limits, or response format. The tool name implies a read-only operation, but this is not explicitly stated in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It contains no redundant information and is appropriately sized for a simple list operation.
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 being a simple tool, the description lacks return value information, definition of what constitutes a 'model', and any behavioral context. With no output schema and no annotations, the description is too minimal to fully inform an agent about the tool's complete behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (limit, offset, userId) with 100% coverage. The tool description adds no extra meaning beyond restating that it uses the user ID, so it meets the baseline for schema-covered parameters without adding value.
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 '使用用户ID获取神岛平台模型列表' (Get the list of models on the Shendao platform using user ID) clearly identifies the action (获取) and the resource (模型列表). It distinguishes from sibling tools like getMapListByUserId by specifying '模型' (models) rather than maps, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It merely states its function without contextual cues about scenarios, prerequisites, or exclusions. The sibling list contains similar tools, but the description doesn't clarify when this one is preferred, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description merely restates the action of fetching profile data. It lacks details on authentication, return format, error behavior, or side effects, which is minimal given the tool's read-like nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It efficiently communicates the core action, though barely, and earns full credit for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what profile fields are returned, possible errors, or how to interpret the data. The current text is too sparse for an agent to make downstream decisions based on the response.
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% for the single parameter, so the description adds little beyond echoing 'use user ID'. No additional format, constraints, or contextual meaning is provided, aligning with the baseline for fully covered schemas.
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 personal profile data for a ShenDao platform user by user ID. It uses a specific verb and resource, and distinguishes from sibling tools focused on maps, comments, lists, and social relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling get*ByUserId tools. It neither provides context for selection nor mentions exclusions or alternatives.
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 must carry the full burden of behavioral disclosure. It only states a basic get operation without mentioning pagination behavior, authentication requirements, result ordering, or error handling, which are important for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the tool's purpose. It is front-loaded and contains no unnecessary words, making it highly 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?
For a simple list tool, the description is minimally adequate, but it lacks context about the return structure, pagination behavior, or any filtering logic. The absence of an output schema and annotations means the description should provide more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description mentions only userId and does not add any extra meaning beyond the schema, such as the relationship between offset/limit and pagination.
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 (获取/get), the resource (地图列表/map list), and the qualifier (使用用户ID/by user ID). This distinguishes it from sibling tools like getMapInfoByUserId (info vs list) and getMapCommentListByUserId (comments vs list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of suitable contexts, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'get follower list' without mentioning pagination, ordering, response format, authorization needs, or error behavior. The limit/offset parameters hint at pagination, but the description does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information (action, resource, input). Zero fluff — every word earns its 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?
The tool is relatively simple with three well-described parameters and no output schema. The description is minimally complete for purpose identification, but it lacks behavioral details and usage context that would help an agent fully understand invocation requirements, especially given the absence of annotations and 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 description coverage is 100% (each parameter has a description). The description adds no additional parameter semantics beyond what the schema already provides, 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?
The description clearly states the action ('获取' / get) and the resource ('粉丝列表' / follower list) with the specific input (user ID). It is distinguishable from sibling tools like getFollowingListByUserId or getFriendListByUserId because it specifically targets followers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a user's follower list by user ID), but it does not provide explicit guidance on when to prefer this over sibling tools, nor does it mention any exclusions or prerequisites. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. However, it only restates the tool's name and does not mention pagination, default limits, error handling, authentication requirements, or any other behavioral traits. This is a significant gap for a tool that likely returns a list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that succinctly states the tool's purpose without unnecessary filler. It is appropriately sized for the tool's simplicity.
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 tool is simple, and the schema covers the parameters, but there is no output schema and no annotations. The description lacks usage guidance and expected return behavior, which might be incomplete for an agent deciding between this and similar sibling tools. It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly explaining each parameter (offset, limit, userId). The description adds no additional parameter context beyond what the schema already provides, which is acceptable given the high 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 tool retrieves a friend list by user ID, using a specific verb (获取) and resource (好友列表). It distinguishes itself from sibling tools like getFollowerListByUserId and getFollowingListByUserId by specifying 'friend list' rather than followers or following.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user's friend list is needed, but provides no explicit guidance on when to prefer this tool over similar sibling tools (e.g., getFollowerListByUserId). There are no alternatives mentioned or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (get) and does not mention read-only safety, authentication requirements, rate limits, or any side effects. While '获取' implies a read operation, the lack of explicit safety or context disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no fluff or redundancy, earning high marks for efficiency.
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 tool has no output schema and no annotations, but the description provides the essential purpose. However, it lacks details about the return format, pagination behavior, or any constraints beyond what the schema already defines. This leaves some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (userId, offset, limit) providing 100% coverage. The description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: using a user ID to fetch the recently played list from the Shendao platform. The verb '获取' (get) and resource '最近游玩列表' (recently played list) precisely define its purpose, differentiating it from siblings like getMapInfoByUserId or getFavoriteListByUserId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent play data via user ID but provides no explicit guidance on when to choose this tool over sibling tools. There are no stated exclusions or alternative recommendations, leaving the agent to infer from the name and 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?
No annotations are provided, so the description carries the full burden. The verb '获取' (get) indicates a read-only operation, and the platform context is helpful. However, it does not mention pagination behavior, auth requirements, or error conditions, though the schema's offset/limit parameters partially cover pagination. For a simple read, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. It is concise and to the point, though it could have added a bit more detail (e.g., output type) without becoming verbose. Still, it is appropriately sized for a simple tool.
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 names the platform (神岛) and specifies that the tool returns a following list, giving the agent enough context to understand the operation. Since there is no output schema, the description adequately implies the return value. Inputs are fully described in the schema. Minor gaps like the structure of the list are not critical for a simple retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all three parameters (limit, offset, userId). The description only repeats that the tool uses the user ID and adds no additional meaning beyond the schema's own descriptions, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: it retrieves the following list (关注列表) for a given user ID on the 神岛 platform using the verb 获取. This distinguishes it from sibling tools like getFollowerListByUserId, which would retrieve followers rather than followings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a user ID and need their following list. It does not explicitly mention alternatives or when not to use it, but the context of sibling tools makes the purpose fairly clear. No exclusions or comparisons are provided.
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 full burden. It discloses that Token and userAgent are required, which is a useful prerequisite, but it does not explain return format, pagination behavior, or any side effects. For a read-style list tool, this is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and requirement. No redundant wording.
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 4-param list getter with no output schema, the description covers the core purpose and auth need. It doesn't detail response structure or pagination semantics, but the schema's offset/limit imply it. A bit more context on expected return could improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage (offset, limit, token, userAgent each have Chinese descriptions), so the description adds no additional semantic value beyond what's in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource combination ('获取系统消息列表') and clearly identifies the resource (system messages on the Shendao platform), distinguishing it from sibling tools that target maps, user profiles, comments, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the required auth prerequisites (Token and user request header) but does not explicitly specify when to use this tool over alternatives or any exclusions. It implies usage for system message retrieval, but no alternatives are mentioned.
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:

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

Score Badge

Copy to your README.md:

[![statistics-mcp MCP server](https://glama.ai/mcp/servers/box3lab/statistics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/box3lab/statistics-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/box3lab/statistics-mcp'

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