Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xiangguangyu-mcp-skills Analyze my personality with MBTI deep analysis"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
252 AI skills exposed as 12 MCP tools (10 featured + discover_skills + get_skill_detail). From MBTI analysis to contract review, from quantitative trading to Skill forging with CUILU. Works with Claude Desktop, Cursor, VS Code, and any MCP client.
# Try any skill instantly — no auth, no signup
curl http://124.222.26.218:3000/api/skill/mbti-deep-analysis
curl http://124.222.26.218:3000/api/skill/zhuojian
curl http://124.222.26.218:3000/api/skill/bianzhen
curl http://124.222.26.218:3000/api/skill/cuiluFree tier: 10 calls per skill per day, no registration needed.
Related MCP server: MBIT-Test
{
"mcpServers": {
"xiangguangyu": {
"command": "npx",
"args": ["-y", "xiangguangyu-mcp-skills@latest"]
}
}
}claude mcp add xiangguangyu -- npx -y xiangguangyu-mcp-skills@latest{
"mcpServers": {
"xiangguangyu": {
"url": "http://124.222.26.218:3000/sse"
}
}
}# | Tool | Skill | Price | Description |
1 |
| — | Free | Browse all 252 skills, filter by category |
2 |
| MBTI Deep Analysis | ¥0.10 | 28-question MBTI personality assessment with cognitive function stack |
3 |
| 辩真 (Bianzhen) | ¥0.50 | Multi-model adversarial fact-checking with source tracing |
4 |
| Ad Copywriter | ¥0.10 | Professional ad copy generation |
5 |
| 灼见 (Zhuojian) | ¥0.50 | 5-layer deep analysis: surface → structure → logic → essence → prediction |
6 |
| 淬炉 (CUILU) | ¥0.50 | Skill forging engine with dual QC gate |
7 |
| Weekly Report | ¥0.10 | Quick weekly report generator |
8 |
| Taobao Listing | ¥0.10 | E-commerce product copywriting |
9 |
| Contract Guardian | ¥0.10 | AI contract review: risk clauses, key terms, expiry tracking |
10 |
| Game Audio | ¥0.10 | 游戏音频设计：音效/配乐/环境音方案 |
11 |
| 试金石 (SHIJIN) | ¥0.50 | Skill质量试金石，一键检测上架标准 |
12 |
| — | Free | Get full details of any of the 252 skills |
discover_skills (position #1) — Lists all 252 skills with name, description, price, and featured badge. Supports keyword filtering.
get_skill_detail — Returns full SKILL.md content for any skill by slug.
Full catalog accessible via
discover_skillstool or API endpoint. Below are the core categories.
Slug | Name | Price | Description |
| XHS Copywriting | ¥0.10 | 小红书风格笔记文案，含5个备选标题 |
| XHS Niche Finder | ¥0.10 | 小红书账号定位与赛道选择 |
| XHS Fan Grower | ¥0.10 | 小红书涨粉策略与行动计划 |
| XHS Topic Generator | ¥0.10 | 30天小红书选题计划 |
| XHS Data Reader | ¥0.10 | 小红书数据分析与优化建议 |
| Video Clip Assistant | ¥0.10 | 视频自动剪辑助手 |
| Video Editor | ¥0.10 | ffmpeg视频编辑操作 |
| Short Drama Writer | ¥0.10 | 短剧剧本创作 |
| Script to Storyboard | ¥0.10 | 剧本转分镜脚本表格 |
| Programmatic SEO | ¥0.10 | 批量SEO页面生成 |
Slug | Name | Price | Description |
| Bug Fixing | ¥0.10 | 智能Bug修复助手 (Python/Java/JS) |
| PR Reviewer | ¥0.10 | GitHub PR代码审查 |
| API Dev | ¥0.10 | REST/GraphQL API开发 |
| Cody | ¥0.10 | 代码Review助手 |
| Runtime Debugging | ¥0.10 | 运行时调试工具 |
| Systematic Debugging | ¥0.10 | 系统化调试方法论 |
| GitHub | ¥0.10 | GitHub CLI交互 |
| Error Analysis | ¥0.10 | 错题分析助手 |
Slug | Name | Price | Description |
| PPT Outline | ¥0.10 | PPT结构化大纲生成 |
| MCK PPT Design | ¥0.10 | 专业商务PPT设计规范 |
| Meeting Notes | ¥0.10 | 会议纪要整理器 |
| Weekly Report ⭐ | ¥0.10 | 周报快写器 |
| Data Export Pipeline | ¥0.10 | 数据采集→清洗→导出管道 |
| Reading Mindmap | ¥0.10 | 读书笔记思维导图 |
Slug | Name | Price | Description |
| Taobao Listing ⭐ | ¥0.10 | 淘宝商品文案 |
| E-commerce Product Selector | ¥0.10 | 电商爆款产品筛选分析 |
| Product Description Generator | ¥0.10 | SEO优化产品描述 |
| Ad Copywriter ⭐ | ¥0.10 | 广告文案生成器 |
| Dingjia Pro | ¥0.10 | 定价不亏计算器进阶版 |
Slug | Name | Price | Description |
| MBTI Deep Analysis ⭐ | ¥0.10 | 28题MBTI深度分析报告 |
| Tarot Reading | ¥0.10 | 78张塔罗牌正逆位解读 |
| Zodiac Daily | ¥0.10 | 每日星座运势解读 |
| Story Master | ¥0.10 | 剧情生成管道流 |
Slug | Name | Price | Description |
| Classroom Lesson Pack | ¥0.10 | 教案/互动题/作业生成 |
| Academic Citation Manager | ¥0.10 | 参考文献规范引用 |
| Knowledge Split | ¥0.10 | 知识点拆解器 |
| Reading Mindmap | ¥0.10 | 结构化读书笔记 |
Slug | Name | Price | Description |
| GovWriter Pro | ¥0.10 | 政府公文创作专家 (GB/T 9704-2012) |
| Official Doc | ¥0.10 | 公文生成器（标准格式） |
| Short Drama Writer | ¥0.10 | 短剧剧本创作 |
| Script to Storyboard | ¥0.10 | 剧本转分镜表格 |
Slug | Name | Price | Description |
| Joinquant | ¥0.10 | 聚宽量化交易平台 |
| InvestLog AI | ¥0.10 | 美股实时数据研究工具 |
| Dingjia Pro | ¥0.10 | 定价不亏计算器 |
Slug | Name | Price | Description |
| Browser Cookbook | ¥0.10 | 浏览器自动化代码片段库 |
| Auth Session Manager | ¥0.10 | Cookie/Token/Session持久化 |
| Web Scraper Builder | ¥0.10 | Puppeteer/Playwright抓取脚本 |
| Form Auto Filler | ¥0.10 | 表单自动填充方案 |
Slug | Name | Price | Description |
| Contract Guardian ⭐ | ¥0.10 | AI合同审查：风险条款/关键信息/到期追踪 |
| Legal Advisor | ¥0.10 | 法律模板生成（劳动/消费/租赁/交通） |
Slug | Name | Price | Description |
| Humanize Core | ¥0.10 | 识别并改写AI典型句式 |
| Humanize Article | ¥0.10 | 长文章深度去AI味处理 |
| Humanize Academic | ¥0.10 | 学术文本真实化改写 |
Slug | Name | Price | Description |
| Pytest Blueprint | ¥0.10 | pytest测试框架蓝图 |
| E2E Playwright | ¥0.10 | Playwright端到端测试 |
| Test Coverage Analyzer | ¥0.10 | 测试覆盖率分析 |
Slug | Name | Price | Description |
| Personal Health Manager | ¥0.10 | 个人健康管理与健康助手 |
Slug | Name | Price | Description |
| Nano PDF | ¥0.10 | 自然语言编辑PDF |
Slug | Name | Price | Description |
| Launch Strategy | ¥0.10 | 产品发布策略规划 |
Slug | Name | Price | Description |
| 淬炉 (CUILU) ⭐ | ¥0.50 | Skill锻造与双重质检引擎 |
| 灼见 (Zhuojian) ⭐ | ¥0.50 | 穿透本质的深度分析工具 |
| 辩真 (Bianzhen) ⭐ | ¥0.50 | 多模型对抗验证/事实核查 |
Variable | Default | Description |
|
| Skill API base URL |
|
| Transport mode: |
|
| SSE server port |
git clone https://github.com/Chromatic0618/alipay-mcp-server.git
cd alipay-mcp-server
npm install
npm run build
node dist/index.js # stdio mode
npm run start:sse # SSE mode on port 3100Free: 10 calls per skill per day (no auth needed)
Standard skills: ¥0.10 per call (248 skills)
Premium skills: ¥0.50 per call (灼见/辩真/淬炉/试金石 — 4 skills)
Payment via Alipay AI Pay (HTTP 402 protocol)
PRs welcome! To add a new skill:
Add to src/skills-data.ts with price field
Create skills/<slug>/SKILL.md
Submit a PR
💬 Discussions — Ideas, questions, feedback
🐛 Issues — Bug reports
⭐ Star this repo if you find it useful!
Chromatic0618 / 相光域
MIT
List all 252 available AI skills with name, description, price, and featured status. Use this to browse the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional keyword filter (e.g. 'finance', 'legal', 'writing') |
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.
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.
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.
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.
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.
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.
Get full details/SKILL.md of any of the 252 skills by slug. Use discover_skills first to find slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Skill slug (e.g. 'mbti', 'zhuojian') |
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.
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.
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.
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.
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.
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.
[Ad Copywriter] 广告文案生成器 (¥0.10/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Bianzhen] 多模型对抗验证助手（跨平台版） (¥0.50/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Contract Guardian] 合同卫士 — AI合同审查助手，识别风险条款、提取关键信息、追踪到期日 (¥0.10/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Cuilu] 淬炉——Skill锻造与双重质检引擎。边锻造边质检，每个Skill出厂前必须通过辩真事实核查与灼见深度穿透双重门禁。 (¥0.50/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Game Audio] 游戏音频设计——音效/配乐/环境音方案与资源制作 (¥0.10/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[mbti-deep-analysis] 通过28题引导式问卷判定MBTI四维度类型，生成包含16型人格解读、认知功能栈、职业倾向与成长建议的深度分析报告 (¥0.10/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Shijin] 试金石｜SHIJIN——Skill质量试金石，一键检测Skill是否达到上架标准 (¥0.50/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Taobao Listing] 淘宝商品文案 (¥0.10/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Weekly Report] 周报快写器 (¥0.10/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
[Zhuojian] 灼见｜ZHUOJIAN——穿透事物本质的深度分析工具，拒绝表面叙事，用证据链给出最接近真相的判断 (¥0.50/call)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户输入内容 / user input for this skill |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.2.1discover_skillsget_skill_detailskill_ad-copywriterskill_bianzhenskill_contract-guardianskill_cuiluskill_game-audioskill_mbti-deep-analysisskill_shijinskill_taobao-listingskill_weekly-reportskill_zhuojianEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for building and testing AI agents with multi-model experimentation and insights.
An MCP Server that provides identity verification and anti-fraud tools for AI agents via deepidv.
MCP server for meme generation, template search, caption rendering, and AI meme creation.
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
