xiangguangyu-mcp-skills

Server Quality Checklist

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

Latest release: v2.2.1
Disambiguation5/5
Each tool has a clearly distinct purpose: discover_skills lists all skills, get_skill_detail retrieves details by slug, and the 10 skill_ tools each target a specific, unique skill (e.g., ad copywriting, contract review, MBTI analysis). No two tools appear to overlap in functionality.
Naming Consistency4/5
The two discovery tools follow a verb_noun pattern (discover_skills, get_skill_detail), while the 10 individual skills are consistently prefixed with 'skill_'. This minor inconsistency is manageable as the prefixes signal different roles, but it could be unified.
Tool Count5/5
12 tools is a well-scoped number for a skills server. It offers discovery (2 tools) plus a curated set of 10 specific skills, avoiding bloat while providing enough variety. The count fits within the ideal 3–15 range.
Completeness3/5
The tool surface covers browsing (discover_skills, get_skill_detail) and using a subset of skills (10 individual tools), but it lacks search/filter for the full 252-skill catalog and does not allow executing skills outside the 10 pre-selected ones. This gap may limit agents that need a skill not in the list.
Average 2.9/5 across 12 of 12 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 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?
No annotations exist and the description fails to disclose any behavioral traits such as read-only, destructive actions, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (one line) but lacks any structure or substantive content. Under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is incomplete for a tool with no output schema, no annotations, and only one parameter. It fails to explain what the tool does, returns, or how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'query' with a generic description 'user input for this skill'. Schema coverage is 100% but the description adds no additional meaning beyond the schema itself.
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 provides a translated title 'Multi-model adversarial verification assistant (cross-platform version)' but lacks a verb and clear resource. It does not state what action the tool performs, only a domain hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or why to use this tool versus sibling tools like 'skill_cuilu' or 'skill_ad-copywriter'. No usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits (e.g., side effects, permissions, rate limits). The agent has no information about what the tool does besides generating copy.
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?
Overly brief to the point of being under-specified. The single line includes the tool name, a Chinese phrase, and cost, which does not effectively convey purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is woefully incomplete. It doesn't specify what input to provide or what output to expect, leaving the agent with minimal guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'query' described as 'user input'. The description adds no extra meaning or usage hints beyond the schema, failing to compensate for lack of detail.
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 mentions 'Taobao Listing' and 'product copywriting' but does not clearly state the tool's function. It's vague and doesn't differentiate from sibling tools like 'skill_ad-copywriter'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. The description is merely a label with price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks any behavioral disclosure: no mention of side effects, permissions, rate limits, or what happens when invoked. Completely opaque.
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?
Extremely short (one line) but sacrifices clarity. Under-specification rather than effective conciseness. No structure or front-loading of critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter skill with no output schema and no annotations, the description must provide complete context. It fails entirely; agent cannot know what the skill does or what query to provide.
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 a single 'query' parameter described as 'user input for this skill'. Description adds no further meaning beyond the schema.
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?
Description is a label-like string with cost info, but no clear verb or resource. Does not specify what the tool does (e.g., generate, summarize, create). Distinguishes poorly from sibling skill tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or when not to use. No mention of alternatives among sibling skills. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the domain and cost, without explaining what happens when called (e.g., generates text, returns audio files), required permissions, or side effects. This is critically insufficient for an agent to predict outcomes.
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, dense line in Chinese and English, conveying topic and cost efficiently. It is front-loaded with the key identifier '[Game Audio]'. However, a slightly more structured presentation (e.g., separating purpose from cost) could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creative skill with no output schema, the description should explain what the tool produces (text? audio files? design plans?) and how to interact with it. It provides none of this context, leaving the agent without enough information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (one 'query' field). The description adds no additional meaning beyond the schema's 'user input for this skill'; it does not specify expected format, language, or examples. Baseline 3 applies since schema coverage is high, but the description adds no value.
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 indicates it is a skill for game audio design, including sound effects, music, and ambient sounds. It specifies the domain and type of output, distinguishing it from sibling tools. However, it lacks an explicit verb specifying the tool's action (e.g., 'generates' or 'creates'), so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, limitations, or context for invocation. The only extra information is the cost per call, which does not help an agent decide when to select 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?
No annotations are provided, and the description only mentions cost (¥0.10/call). It does not disclose behavioral traits like whether it modifies external state, requires authentication, or has rate limits. The cost note adds 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?
The description is very concise, consisting of a single line. It includes a title, purpose, and cost, but is not structured beyond that. It earns its place by being succinct.
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 input schema and lack of output schema, the description is too sparse. It does not explain expected input format, output nature, or provide examples. More detail is needed for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'query'. The description adds bilingual labels but minimal extra meaning beyond the schema's own description. 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 clearly indicates this tool generates ad copy (广告文案生成器), which is a specific verb+resource. It is distinct from sibling tools like skill_bianzhen or skill_contract-guardian, but lacks specificity on platforms or languages.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives like other skill tools, nor any prerequisites or exclusions.
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 must carry the burden. It discloses the cost (¥0.50/call) and methodology (evidence chains), but does not clarify if the tool is read-only or destructive, nor does it describe any side effects or limitations.
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, compact line that includes purpose, methodology, and pricing. It is front-loaded and efficient, though the structure could be clearer (e.g., separate sentences).
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, the description should explain what the tool returns, but it does not. It also lacks detail on how to craft effective queries. For a single-parameter tool, the description is too abstract to fully guide the agent.
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 'query', which is described as 'user input for this skill'. The tool description adds no further detail about how to formulate the query, so it meets the baseline but offers no extra value.
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 identifies it as a deep analysis tool ('深度分析工具') that goes beneath surface narratives to find truth using evidence chains. This communicates the core function well, but it does not differentiate from sibling analysis tools like skill_bianzhen.
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 or not use this tool, nor any mention of alternatives. The description only states its analytic philosophy, leaving the agent without decision criteria.
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 mentions process steps (forging while inspecting, two quality gates) and cost (¥0.50/call), which adds transparency. However, it lacks details on side effects, permissions, or reversibility.
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 one sentence plus cost note. It front-loads the tool name and key idea. However, the metaphorical language adds ambiguity, slightly reducing clarity for a bilingual audience.
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 one parameter and no output schema, the description is adequate but incomplete. It explains what the tool does but not what the output looks like, how the dual inspection works in practice, or typical use cases. More context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter 'query' and schema description coverage 100%, the schema already explains the parameter. The description adds no additional meaning beyond restating 'user input for this skill.'
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 is a 'Skill forging and dual quality inspection engine' with specific verbs (forge, inspect) and resource (Skill). It distinguishes from sibling tools by mentioning dual gates (fact-checking and deep insight), but the metaphor '淬炉' may be unclear to some users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not specify prerequisites, when not to use, or compare to sibling tools. The context of being a meta-skill for other skills is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions cost and number of questions but lacks details on data handling, limitations, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with key information (purpose, method, cost). Efficient but could benefit from structure (e.g., separating description from cost).
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?
With no output schema, the description explains the report content (16 types, cognitive functions, etc.), which is sufficient for a simple tool. However, lacks behavioral and safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds that query is user input, matching the schema. No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an MBTI deep analysis tool that determines four dimensions and generates a report. It is specific but does not differentiate from siblings, which are not MBTI-related.
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?
Usage is implied for MBTI personality analysis, but there are no explicit when-to-use or when-not-to-use guidelines, nor alternatives mentioned.
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 mentions the cost (¥0.50/call), which is helpful, but fails to describe whether the tool is read-only, whether it modifies state, what returns are expected, or authentication requirements. This is insufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the tool's purpose, branding, and cost. It is concise and front-loaded, with no redundant information. Slightly more detail could be added without harming 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?
Given the tool has one parameter, no output schema, and no annotations, the description should explain what the tool returns and how to interpret results. It does not, leaving the agent guessing about the output format and behavior. Not complete enough 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?
Schema coverage is 100%, and the parameter 'query' has a basic description. The tool description adds no additional meaning beyond what the schema provides (e.g., what format the query should be in). 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 tool's purpose: 'Skill质量试金石，一键检测Skill是否达到上架标准' (quality touchstone to check if a skill meets listing standards). It uses specific verbs and identifies the resource, and the sibling tools (e.g., discover_skills, get_skill_detail) are sufficiently distinguished.
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 use for testing skill quality for listing, but provides no explicit guidance on when to use vs. alternatives (e.g., when to prefer this over discover_skills or get_skill_detail). No exclusions or context are mentioned.
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 discloses core functions and cost per call, but lacks details on limitations (e.g., input format expectations, result structure, error handling) that could help an agent anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a single sentence listing key functions and pricing. No wasted words, but could benefit from structured sections for readability.
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 clarify return format. It lists functions but not how results are presented. Adequate for a simple skill, but lacking detail on the 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 coverage is 100% with one parameter 'query' described as 'user input for this skill'. Description adds no extra meaning beyond the schema, so 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?
Description clearly states the tool is an AI contract review assistant (合同审查助手) and lists specific functions: identify risk clauses, extract key info, track expiry dates. This distinguishes it from sibling skills which focus on other domains (e.g., ad-copywriter, game-audio).
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?
Usage is implied: use for contract review. No explicit when-to-use or when-not-to-use guidance, and no comparison to sibling skills despite being in a list of specialized skills.
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 must stand alone. It implies a read operation but omits details like pagination behavior, result limits, or whether the catalog is exhaustive. The mention of '252' is helpful but lacks clarity on dynamic updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and result, and contains no unnecessary words. It is efficient and easy to parse.
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 the return fields (name, description, price, featured status) and the total count, which is helpful. It lacks only a note on possible filtering behavior and output format (e.g., array). This is sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description of the optional 'category' filter. The tool description does not add any extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all 252 available AI skills with specific fields (name, description, price, featured status), using a strong verb and resource identification. It distinguishes itself from sibling tools that focus on individual skills.
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 gives a brief usage hint ('Use this to browse the full catalog') but does not explicitly mention when not to use it or provide alternatives among the many sibling tools like get_skill_detail for detailed views.
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; description does not mention side effects, authorization, rate limits, or return format. Minimal behavioral disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no extraneous information. Efficient and direct.
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?
Lacks details about what 'full details' includes; no output schema or annotation to supplement. For a detail endpoint, more context is needed.
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. Description adds slug examples but no deeper parameter semantics 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?
Clearly states 'Get full details/SKILL.md' with specific resource and action, and distinguishes from sibling discover_skills by mentioning slug lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use discover_skills first to find slugs, providing clear when-to-use and prerequisite context.
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:

[![alipay-mcp-server MCP server](https://glama.ai/mcp/servers/XYG-LUNA/alipay-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/XYG-LUNA/alipay-mcp-server)

Score Badge

Copy to your README.md:

[![alipay-mcp-server MCP server](https://glama.ai/mcp/servers/XYG-LUNA/alipay-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/XYG-LUNA/alipay-mcp-server)

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/XYG-LUNA/alipay-mcp-server'

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