xiaohongshu-mcp

by JessYan0913

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clear, distinct purpose: authentication (login/check/logout), feed retrieval (search vs recommend), detail fetch, publishing, and engagement (like vs favorite). No two tools appear to do the same thing.
Naming Consistency5/5
All tools follow a consistent xhs_verb_noun pattern in snake_case, such as xhs_search_feeds, xhs_get_feed_detail, and xhs_publish_note. This makes the tool set highly predictable.
Tool Count5/5
9 tools is well within the ideal range for a client MCP server. Each tool serves a distinct and necessary function for interacting with the platform.
Completeness4/5
Core workflows are covered: authentication, search, recommend, detail, publish, like, and favorite. Notable gaps include comment creation, user follow, and note update/delete, but these are not critical for basic read/write interactions.
Average 3.9/5 across 9 of 9 tools scored.
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 status not available
This repository is licensed under ISC 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key behavior: '智能检测当前状态，已处于目标状态时自动跳过' (intelligently detects current state, skips if already in target state), indicating idempotency. However, it does not describe error conditions, return values, or permission requirements beyond the needed token, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and follows with the key behavioral nuance and prerequisites. Every clause earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple mutation tool with no output schema and no annotations. The description adequately covers what it does, the idempotency behavior, and required inputs. However, it omits return value/feedback and error handling scenarios (e.g., invalid token, non-existent feed), which are important for an agent to fully understand the outcome. Given the tool's simplicity, it is acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters. The description only repeats the requirement for feedId and xsecToken, adding no extra meaning to the 'unlike' parameter or the relationship between parameters. Since schema coverage is high, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '为笔记点赞或取消点赞' (like or unlike a note), identifying both the verb and the resource. It also adds a distinctive behavior of auto-detecting current state and skipping if already in the target state. However, it does not explicitly differentiate itself from the sibling tool 'xhs_favorite_feed', so it's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('需要笔记 ID 与 xsecToken' – requires note ID and xsecToken), which implies basic usage context. It does not provide explicit when-to-use vs alternatives or exclusions, such as 'use this for liking, use xhs_favorite_feed for favoriting'. This is adequate but lacks clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention authentication requirements (despite sibling login tools), potential rate limits, or any side effects. The description only lists return data, leaving crucial operational context unstated.
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, compact sentence that front-loads the main action and resource, then lists the return fields. It is efficient, with no redundant text or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description adequately covers purpose and return fields. However, it omits prerequisites like login and potential error scenarios, which could leave an agent unprepared despite the overall clarity.
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 sole parameter 'limit' is fully described in the schema (max count, default 10), so the description adds no extra parameter-specific meaning. Schema coverage is 100%, meaning the description does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the list of recommended notes from the Xiaohongshu homepage and enumerates the returned fields (ID, xsecToken, title, author, interaction data). This is a specific verb+resource operation that distinguishes it from siblings like xhs_search_feeds and xhs_get_feed_detail.
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 the tool is for browsing homepage recommendations but does not explicitly say when to use it over alternatives or any exclusions. The sibling context suggests it is used when a user wants recommended feeds, but no concrete guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses the idempotent behavior ('已处于目标状态时自动跳过') and the token requirement. However, it omits other behavioral aspects such as reversibility, potential side effects, and return value, which would be valuable for an agent to know.
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 sentence that leads with the primary verb and resource. It includes only essential information—the action, the smart-skip behavior, and the required inputs—with no redundant content. Excellent structure and economy of words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 scalar parameters, no output schema, no nested objects), the description covers the core purpose, behavioral nuance, and required inputs. However, since there is no output schema, it would benefit from mentioning return values or error conditions, which are currently absent. This is a minor gap, so a score of 4 is appropriate.
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 already provides descriptions for all three parameters (100% coverage), including the default for unfavorite. The description only reiterates that feedId and xsecToken are required, which is already in the schema. No additional semantic insight is provided, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '为笔记收藏或取消收藏' (favorite or unfavorite a note), identifying both the verb and the resource. It also mentions '智能检测当前状态' which distinguishes its behavior from simpler toggle tools and from the sibling like_feed. This is specific and avoids ambiguity.
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 does not explicitly state when to use this tool versus alternatives like like_feed, nor does it mention exclusions. The intended use is implied by the tool's name and description, but there is no direct comparison or 'when not to use' guidance, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output structure and downstream usability of the returned IDs, which is useful. However, it does not mention whether login is required, error behavior, sorting/pagination, or rate limits, leaving notable gaps in behavioral transparency.
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 concise sentences, front-loaded with the primary action and followed by useful output details. Every sentence earns its place, with no redundancy or fluff.
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 the tool has no output schema and no annotations, the description provides essential information about what is returned and how to use the results. However, it omits authentication requirements, pagination/ordering behavior, and potential error scenarios, so it is not fully complete for a robust agent interaction.
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%: both keyword and limit have descriptions. The description adds minimal parameter-level meaning beyond the schema (it restates keyword-based search), so a baseline of 3 is appropriate without additional enrichment.
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 '搜索小红书笔记' (search Xiaohongshu notes) with a specific verb and resource, and lists the exact returned fields (ID, xsecToken, title, author, interaction data). This clearly distinguishes it from sibling tools like xhs_get_recommend_feeds or xhs_get_feed_detail by emphasizing keyword-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (keyword search) and even explains how the returned id+xsecToken can be used with related tools. However, it does not explicitly mention alternatives or exclusions (e.g., 'use xhs_get_recommend_feeds for browsing'), but the purpose is clear enough for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states what data is returned and that both ID and token are required. However, it does not mention whether authentication is needed (relevant given sibling xhs_login), the exact limit of comments ('前若干条' is vague), or any error/rate-limit behavior.
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 concise sentence that leads with the purpose, lists the returned fields, and states the prerequisite. No wasted 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?
For a detail-fetch tool with two parameters, the description gives a good overview of the return payload and prerequisites. However, it lacks an output schema and does not specify authentication requirements or comment count boundary, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for both parameters, so the baseline is 3. The description reinforces that both are mandatory ('两者缺一不可') and points to their origin (search/recommend results), adding marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取小红书笔记详情' (get note details), and enumerates the returned data (title, body, images, author info, interaction data, comments). This distinguishes it from sibling tools like search, recommend, publish, like, and favorite.
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 specifies the required inputs for use: '需要笔记 ID 与 xsecToken（两者缺一不可，从搜索/推荐结果获取）', indicating that this tool is for fetching details after obtaining a note ID via search or recommendation. It clearly implies the context of use, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of transparency. It discloses the login requirement and input constraints (image format and count), which is useful. However, it does not mention post-publish behavior, error conditions, or side effects, leaving some gaps for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and resource, then lists requirements and prerequisites in a clear, ordered manner. Every element earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 fully documented parameters and no output schema, the description adequately covers prerequisites and key input constraints. It lacks explicit mention of success/failure feedback or error handling, but these are not critical for a straightforward publish action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description largely echoes the schema details (title max 20 characters, at least one image, local/HTTP paths, optional tags) without adding new semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('发布' – publish) and the resource ('图文笔记到小红书' – image-text note to Xiaohongshu), distinguishing it from sibling tools that handle login, search, like, and favorite operations. The verb+resource combination is specific and unambiguous.
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 the prerequisite of being logged in ('发布前需已登录') and enumerates required inputs (title, content, at least one image, optional tags). It does not explicitly name alternatives, but the publish action is clearly distinct from sibling tools, providing sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool validates the local login state and, when logged in, returns the nickname and refreshes the login state. This explicitly reveals a side effect (refreshing the login state), which is valuable. It does not mention failure behavior or edge cases, but for a simple tool this is reasonable.
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 sentence, front-loaded with the main action ('检查小红书登录状态'), followed by concise details about validation and the success response. Every phrase adds meaningful information, with no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description does not specify what happens when the login state is invalid or what the exact return value structure is. It mentions returning the nickname when logged in but omits the failure case. This leaves the agent with some ambiguity about the tool's full behavior, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameters. The baseline for no parameters is 4, and the description adds no parameter semantics because there are none to add. The tool's behavior is fully described without requiring parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('检查' = check) and a clear resource (小红书登录状态 = Xiaohongshu login status). It explicitly states the tool's function: validating locally saved login state and returning the account nickname if valid, which distinguishes it from sibling tools like xhs_login and xhs_logout.
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 makes the tool's purpose clear, implying it should be used to verify login status before other operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes the browser window, QR code, waiting for scanning, and automatic saving of login state, giving a clear picture of the interactive process. It does not cover timeouts or failure scenarios, but the core behavior is well disclosed.
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 sentence that front-loads the action ('登录小红书') and efficiently explains the entire process in a concise, structured way. Every phrase contributes meaning with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter interactive login tool, the description covers the main flow and persistence of login state. However, it does not specify the return value or whether the function blocks until scanning, which could be gaps given the absence of an output schema. Still, it's sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously). According to the baseline rule for 0 parameters, a score of 4 is appropriate; the description does not need to explain any parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: logging into Xiaohongshu by opening a browser, displaying a QR code, waiting for scanning, and saving login state. It explicitly distinguishes from siblings like xhs_check_login and xhs_logout, making the purpose unmistakable.
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 initial login and notes that login state is persisted for future use, but it does not explicitly compare with xhs_check_login or explain when not to use. There is no explicit when/when-not guidance, only implied context from the login flow.
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 disclose side effects itself. It states that local login state is cleared, implying a state-modifying action. However, it does not clarify whether a server-side session is invalidated or whether the action is reversible, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that front-loads the main action ('退出登录') and then explains the effect. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter logout tool with no output schema, the description adequately covers the action and its local effect. It omits return value expectations, but the simplicity of the tool makes this omission acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the empty schema matches this. The description adds no parameter-specific details, but there is nothing to document. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action '退出登录' (logout) and the affected resource '小红书登录态' (Xiaohongshu login state). It distinguishes itself from sibling tools like xhs_login and xhs_check_login by stating it clears the local login state.
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 purpose is immediately clear: use this tool to log out and clear local login state. While it doesn't explicitly mention alternatives or when-not-to-use, the context is unambiguous given the sibling tool names, making the intended use case obvious.
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:

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

Score Badge

Copy to your README.md:

[![xiaohongshu-mcp MCP server](https://glama.ai/mcp/servers/JessYan0913/xiaohongshu-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JessYan0913/xiaohongshu-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JessYan0913/xiaohongshu-mcp'

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