xiangyi

by ROCKCHENWEI

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action and domain: consultation normalization, three separate calculation types, knowledge lookup, auditing, and run persistence. Even the three calculate_* tools are clearly separated by subject (natal chart, event hexagram, timing windows), leaving no real overlap.
Naming Consistency5/5
All tool names follow a uniform snake_case verb_noun pattern with clear verbs: prepare, calculate, search, audit, get, save, delete. The repeated calculate_* prefix is used consistently for the three computation tools, making the set predictable.
Tool Count5/5
Nine tools is a well-scoped count for a consultation-oriented server. Each tool covers a distinct phase of the workflow without redundancy or excessive granularity.
Completeness4/5
The core consultation lifecycle is covered: prepare input, calculate results, audit, and persist/retrieve/delete runs. Minor gaps exist, such as no way to list saved runs or update an existing run, but these do not block the primary workflow.
Average 3.4/5 across 9 of 9 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate those. It adds the notion that the facts are 'confirmed' and lists the chart systems involved, but it provides no additional behavioral details such as input requirements, error cases, or how the payload is interpreted.
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 with no filler and front-loads the core action. It is structurally clean, though the brevity comes at the cost of necessary parameter guidance.
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?
This is a complex tool with a fully open payload and multiple chart systems, yet the description explains none of the required inputs or constraints. The output schema exists, so return values do not need explanation, but the input side is left critically underspecified for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a single generic 'payload' object with additionalProperties allowed and no description, and schema description coverage is 0%. The description gives no information about what the payload should contain, how to specify the chart type, or what fields are required, so an agent has almost no guidance for constructing valid arguments.
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 specific verb ('calculates') and resource ('BaZi, Ziwei, or Western natal chart facts'), which is clear and distinguishes the tool's domain from siblings like calculate_event and calculate_timing. However, it does not explicitly differentiate itself from those siblings in the description itself, so it stops short of full 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?
There is no guidance on when to use this tool versus calculate_event, calculate_timing, or search_knowledge. The description implies natal chart calculations but provides no exclusions, prerequisites, or alternative routing, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context by saying the calculation is local and that the seed is recomputable, but it does not disclose what happens if both manual values and a seed are supplied, or what a valid payload must contain. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the core purpose and input basis. It earns its place, though it is slightly under-specified in terms of payload structure.
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 tool with an opaque payload schema and sibling tools that perform related calculations, the description is too thin. It explains the high-level function but misses payload structure, input alternatives, and when to prefer this tool over siblings. The output schema exists, so return format is less of a concern, but invocation still remains uncertain.
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 0% and the payload is an unrestricted object with additionalProperties. The description mentions 'manual yao values' and 'recomputable seed' as conceptual inputs but never specifies the expected keys, value formats, or how these inputs map to the payload. This leaves the agent unable to construct a valid invocation from the description alone.
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 names a specific verb ('calculate'), a resource ('local I Ching event hexagram'), and the two inputs ('manual yao values' or 'recomputable seed'). This is clear and distinguishes the tool from natal/timing calculations by the 'event' scope, though it never explicitly names a sibling.
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 choose this tool over calculate_natal, calculate_timing, or other siblings. The description implies it is for event hexagrams, but it does not state when manual yao values should be supplied versus a seed, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, and non-destructive behavior, so the description's additional burden is lower. It adds the precision-threshold constraint, though without explaining what happens when the threshold is not met or what the result looks like. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, and the core function appears before the constraint. Brevity is an asset here, though some terms like '输入精度门槛' remain undefined.
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 opaque nested payload, 0% schema coverage, and sibling tools with similar 'calculate_' prefixes, the description is not complete enough. The presence of an output schema reduces the need to describe return values, but the input structure and precision requirements are still critically underspecified.
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 0% and the sole parameter is an opaque 'payload' object with additionalProperties allowed. The description does not explain the required precision fields, value formats, or how to structure the payload beyond a vague 'input precision' mention, so it fails to compensate for the missing 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 uses a specific verb ('计算') and names the resource ('大周期、年、月时间窗'), and adds a conditional detail about day-level queries. It does not explicitly contrast itself with calculate_natal or calculate_event, so it stops short of full 5-level 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?
There is no guidance on when to choose this tool over its siblings. The only usage hint is the vague condition that day-level queries must satisfy an 'input precision threshold', but the threshold itself is not defined and no alternatives or exclusions 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope of the audit (facts, sources, timing, conflicts, safety) but not behavioral details such as return format, whether it cross-references a knowledge base, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, front-loaded with the verb and resource, then a compact list of audit dimensions. It is concise but perhaps over-compressed, making the dimensions feel like a fragment without supporting context.
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?
While the tool is simple (one payload param) and an output schema exists, the description leaves the payload semantics entirely unspecified and does not define key terms like safety boundaries or time precision. An agent would struggle to construct a correct call without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one undocumented payload object with additionalProperties=true and no description (0% coverage), and the description never explains what the payload should contain—such as the interpretation text, structured data, or output from a sibling tool. This is a major gap that the description fails to fill.
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 names a specific verb (审计/audit) on the resource 解读 (reading) and enumerates precise audit dimensions: factual references, sources, temporal precision, conflicts, and safety boundaries. This clearly distinguishes it from calculation, search, and run-management siblings.
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 when to use the tool—when an interpretation's factual integrity needs auditing—but does not explicitly state conditions, exclusions, or alternatives like search_knowledge or calculate_*. The intended context is inferable, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the description does not need to repeat deletion or idempotency. It adds value by disclosing the confirmation requirement, which is critical for a destructive operation and is not captured by annotations. No contradiction with annotations is present.
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 front-loads the primary action ('删除一个已保存咨询') and appends the confirmation condition. It avoids redundancy and is easily scannable. While brief, it is appropriately sized for the tool's simple 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?
Given that the tool is destructive, has an output schema, and has zero schema description coverage, the description is incomplete. It omits parameter semantics entirely and does not clarify what the confirm parameter does or how run_id is used. The confirmation rule is helpful, but without parameter explanations and explicit side effects beyond the annotation, the description does not provide sufficient context for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must explain the parameters. It does not mention run_id or confirm, nor their purpose or relationship to the confirmation condition. The agent is left to infer that run_id identifies the consultation and confirm gates the operation, which is a significant gap for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('删除' = delete) and a clear resource ('已保存咨询' = saved consultation), which unambiguously identifies the tool's purpose and distinguishes it from sibling tools like get_run and save_run. The confirmation condition adds a precise behavioral constraint without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: only after explicit user confirmation ('只有用户明确确认后才执行'). This provides clear context for invocation. However, it does not mention alternatives or exclusions relative to sibling tools, though no competing delete tool exists, so a 4 is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a clear behavioral rule beyond annotations: the tool must not confirm on its own, and output is meant for user confirmation. This complements the readOnlyHint and idempotentHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with two clauses; it front-loads the primary action and adds the confirm constraint with a semicolon. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations declaring read-only, idempotent, non-destructive behavior, the description covers the essential flow: normalize, return settings, do not confirm. It lacks conditions on when to use it, but that is a usage-guideline gap, not a completeness gap for calling the 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 0%, so the description must compensate. It labels the single payload parameter as 'consultation input,' which is more meaningful than the generic schema field, but it provides no structure or examples of expected payload fields.
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 specific action – normalizing consultation input – and identifies the deliverable (settings requiring user confirmation). It does not reference sibling tools like calculate_natal or search_knowledge, so differentiation is implicit rather than explicit.
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 call this tool versus siblings such as calculate_natal or save_run. The context that it is a preliminary step before confirmation is implied by the name and behavior, but never stated as a condition or alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds a useful behavioral guarantee: the result is data, not instructions, which is important context for an agent handling retrieved content. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the resource scope and result type efficiently, earning its place without unnecessary detail.
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 read-only search tool with annotations and an output schema, the description provides a viable baseline. However, it omits any parameter semantics, especially for `source_id` and `max_characters`, and it offers no situational guidance about when to prefer this tool over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no guidance about `query`, `limit`, `source_id`, or `max_characters`. The tool name implies searchability, but the description adds no parameter-level meaning and does not compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (`检索`/retrieve), a specific resource (`已导入且未隔离的本地资料`/imported local materials), and the nature of the result (`数据而非指令`/data not instructions). This is enough for an agent to distinguish it from sibling calculation and run-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: search the imported local knowledge base. It does not explicitly name alternatives or state when not to use it, but the intended context is unambiguous enough for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not idempotent; the description adds useful behavioral context by specifying that data is persisted to a local runs.db and that saving is user-initiated. It does not explain overwrite, duplication, or error behavior, but it goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the critical guardrail ('only when the user explicitly requests saving') before stating the action and target. There is no filler or repetition.
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?
Purpose and trigger are clear, but the only parameter is an opaque free-form object with additionalProperties: true and zero description. An agent would not know how to construct the payload. The presence of an output schema reduces the need to describe return values, but payload construction is an essential gap.
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 description coverage is 0%, so the description must compensate, but it does not explain the payload structure. Saying 'write a consultation' only implies the payload contains consultation data; it leaves the actual shape, required fields, and serialization format undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation: writing a consultation to local runs.db, and adds a strong condition ('only when the user explicitly requests saving'). This clearly separates save_run from siblings like get_run, delete_run, and the various calculation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance by requiring an explicit user save request, which also implies the tool should not be called automatically. It does not name alternative tools or describe when to prefer them, so it falls just short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses a specific edge-case behavior: if the database does not exist, the tool will not create it. It also restricts reads to explicitly saved consultations, adding useful precondition 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?
One compact sentence with two clauses, front-loading the main action and then adding the key no-creation behavior. There is no filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with rich annotations and an output schema, the description supplies the essential selection and safety context. The no-create guarantee and explicit-save qualifier cover important edge cases without needing to describe return values.
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 description coverage is 0%, and the description never mentions run_id, its origin, or accepted values, so it adds no meaning beyond the bare 'Run Id' label. The agent must infer that run_id identifies the saved consultation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('读取'/read) and a precise resource ('用户曾明确保存的本地咨询' – locally saved consultations), and adds a non-creation guarantee that separates it from save_run. It avoids confusion with search_knowledge by emphasizing retrieval of an explicitly saved item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys the context: use when an agent needs to retrieve a previously saved, user-confirmed local consultation, and the 'explicitly saved' qualifier excludes transient or unsaved consultations. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough.
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:

[![XIANGYI MCP server](https://glama.ai/mcp/servers/ROCKCHENWEI/XIANGYI/badges/card.svg)](https://glama.ai/mcp/servers/ROCKCHENWEI/XIANGYI)

Score Badge

Copy to your README.md:

[![XIANGYI MCP server](https://glama.ai/mcp/servers/ROCKCHENWEI/XIANGYI/badges/score.svg)](https://glama.ai/mcp/servers/ROCKCHENWEI/XIANGYI)

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/ROCKCHENWEI/XIANGYI'

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