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., "@mcp-server-weibo What's trending on Weibo today?"
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.
微博 MCP 服务器，通过 Model Context Protocol 为 AI 助手提供微博数据查询能力。
工具 | 说明 |
| 根据关键词搜索微博用户 |
| 获取用户资料 |
| 获取用户动态 |
| 获取用户热门动态 |
| 获取微博热搜榜 |
| 搜索微博内容 |
| 搜索微博话题 |
| 获取用户关注列表 |
| 获取用户粉丝列表 |
| 获取帖子评论 |
Related MCP server: Xee-mcp
在 MCP 客户端的配置中添加：
从 GitHub 源码安装：
{
"mcpServers": {
"weibo": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/InfernalAzazel/mcp-server-weibo.git",
"mcp-server-weibo"
],
"env": {
"COOKIE": "你的微博 cookie"
},
}
}
}本地开发：
uv pip install -e .
# 或
pip install -e .需要配置微博 Cookie 才能调用 API。在 env 中设置 COOKIE，或在项目目录下创建 .env：
COOKIE=你的微博Cookie字符串或通过命令行保存到 .env：
mcp-server-weibo --cookie "你的微博Cookie"获取 Cookie：登录 m.weibo.cn，在浏览器开发者工具中复制请求头里的 Cookie。
mcp-server-weibo
# 或
mcp-server-weibo stdiomcp-server-weibo http
# 默认端口 4200，可通过环境变量 PORT 修改
PORT=8080 mcp-server-weibo httpuv run fastmcp dev inspector src/mcp_server_weibo/server.py --ui-port 3666 --server-port 3667# 运行所有测试
uv run pytest tests/ -v
# 需要 COOKIE 的 API 测试（未配置会跳过）
uv run pytest tests/test_weibo.py -v获取指定微博帖子的评论。
返回: list[dict]: 包含评论信息的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| feed_id | Yes | 微博帖子唯一标识 | |
| page | No | 分页页码，默认 1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose read-only nature, rate limits, or pagination behavior. Only states return type.
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?
Very short (one sentence plus return type), no fluff. Could be improved with structured sections but is acceptably concise.
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 output schema present, description is partially complete but lacks details on comment structure and pagination behavior. Adequate but not thorough.
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 both feed_id and page are already described. Description adds no extra semantics beyond what 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?
Description clearly states verb '获取' and resource '指定微博帖子的评论', which distinguishes it from sibling tools like get_fans or get_feeds.
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 this tool, prerequisites (e.g., need feed_id from elsewhere), or alternatives. Description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取微博用户粉丝列表。
返回: list[dict]: 包含粉丝信息的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 微博用户唯一标识 | |
| limit | No | 返回粉丝数量上限，默认 15 | |
| page | No | 分页页码，默认 1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the return type (list of dicts with fan info) but omits whether the operation is read-only, requires authentication, or has any side effects. Minimal disclosure.
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 at two sentences, but it under-specifies important details. It is front-loaded but could be more informative without being verbose.
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 low complexity (3 params, 1 required) and presence of an output schema, the description is minimally complete. However, it lacks guidance on pagination, authentication, and differentiation from sibling tools, leaving gaps.
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 description coverage is 100%, with each parameter described. The description adds no additional semantic information beyond what is in the schema, 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?
Description clearly states it retrieves the fan list of a Weibo user, specifying the resource and verb. However, the sibling tool 'get_followers' may cause confusion as both terms are similar in the Weibo context; no differentiation is provided.
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 is given on when to use this tool versus alternatives like get_followers or get_profile. There is no context for when it should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取微博用户动态。
返回: list[dict]: 包含动态信息的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 微博用户唯一标识 | |
| limit | No | 返回动态数量上限，默认 15 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the return type but lacks details on authentication, rate limits, error handling, or pagination.
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 short and to the point, with no wasted words. It could benefit from more structure but is effective in its brevity.
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 simplicity of the tool and presence of an output schema, the description is still too sparse. It lacks context about when to use it versus siblings and any behavioral nuances.
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 the input schema already documents both parameters adequately. The description adds no extra information 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 the action (get) and resource (Weibo user feeds), making the tool's purpose obvious. However, it does not differentiate from sibling tools like get_hot_feeds or get_trendings.
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 this tool versus alternatives. The description does not mention context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取微博用户关注列表。
返回: list[dict]: 包含关注信息的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 微博用户唯一标识 | |
| limit | No | 返回关注数量上限，默认 15 | |
| page | No | 分页页码，默认 1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the return type (list[dict]) but does not mention any side effects, authentication requirements, rate limits, or the fact that it is a read-only operation. This is insufficient for a tool with 3 parameters.
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 extremely concise (two lines) without any wasted words. However, it lacks structural elements such as a clear separation of purpose and usage, and the return type annotation could be better integrated. For a simple tool, this conciseness is acceptable.
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 3 parameters, an output schema, and sibling tools, the description provides the return format and basic purpose. It does not elaborate on pagination behavior or parameter defaults, but these are covered in the schema. The description is complete enough for a straightforward list retrieval 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?
All three parameters are described in the input schema (100% coverage). The description adds no additional meaning beyond the schema; it only repeats the parameters implicitly. The return type note provides extra context but does not relate to parameter input semantics.
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 retrieves a Weibo user's following list, which is distinct from sibling tools like 'get_fans' (fans) and 'get_feeds' (content feeds). The verb '获取' (get) and resource '关注列表' (following list) make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives such as 'get_fans' or 'search_users'. The description implies it is for retrieving followings, but lacks context on prerequisites, pagination strategy, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取微博用户热门动态。
返回: list[dict]: 包含热门动态信息的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 微博用户唯一标识 | |
| limit | No | 返回动态数量上限，默认 15 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the return type (list of dicts) but omits critical details like access permissions, whether the operation is read-only, ordering of results, or any 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?
The description is very short and front-loaded, but the return format section is unnecessary clutter if an output schema exists. Still, it earns points for brevity.
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 2-parameter tool with an existing output schema, the description is minimally adequate. However, it lacks explanation of what defines 'hot' or how the results are sorted, which would enhance completeness.
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 description coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides, landing at the baseline score.
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 retrieves 'hot feeds' for a Weibo user, using a 'get' verb and specifying the resource. However, it does not explicitly differentiate from sibling tools like 'get_feeds' or 'get_trendings', which could cause confusion.
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 provides no guidance on when to use this tool versus its siblings (e.g., get_feeds, get_trendings). There are no context hints or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取微博用户资料信息。
返回: dict: 包含用户资料信息的字典
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 微博用户唯一标识 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It only states it returns a dict, but does not disclose error handling, permissions, or input validation beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line for purpose, one for return value. No wasted words, front-loaded with the action.
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 profile retrieval with output schema available, the description is minimally complete. Lacks any mention of error cases or prerequisites, but the tool is straightforward.
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. The description adds the Chinese label '微博用户唯一标识' (unique identifier) for uid, which matches the schema description, providing no additional 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 clearly states the tool retrieves Weibo user profile information, which is a specific verb-resource combination. It distinguishes from sibling tools like get_comments, get_fans, etc., which serve different purposes.
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. While siblings are different, the description does not clarify that this fetches a single user's full profile, not a list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前微博热搜话题。
返回: list[dict]: 包含热搜条目的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回热搜条目数量上限，默认 15 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose that this is a read-only operation, nor does it mention authentication, rate limits, or side effects. The tool name implies reading, but the description fails to add behavioral context.
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 purpose and a concise return type specification. No wasted words; every sentence serves a purpose.
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's simplicity and the existence of an output schema, the description is minimally complete. However, it lacks disambiguation from siblings and does not explain potential variations in results (e.g., update frequency).
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 description coverage is 100% for the single parameter 'limit'. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'get current Weibo trending topics', providing a specific verb and resource. It distinguishes from sibling tools like get_hot_feeds and search_topics by specifying 'current trends'.
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 this tool versus alternatives (e.g., get_hot_feeds, search_topics). The description does not mention prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据关键词搜索微博内容。
返回: list[dict]: 包含搜索结果的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| limit | No | 返回结果数量上限，默认 15 | |
| page | No | 分页页码，默认 1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, authentication needs, or rate limits. It only states the basic operation.
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 (two sentences) and clearly front-loaded with the action. However, it could be considered slightly under-specified.
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?
The tool has an output schema, so return values are covered. However, the description lacks details on pagination, error handling, or usage context, making it adequate but not fully complete.
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 parameters are fully documented. The description adds no extra meaning beyond what is in the schema, warranting the baseline score.
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 searches Weibo content by keyword, using a specific verb ('search') and resource ('Weibo content'). It distinguishes from sibling tools like search_topics and search_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?
The description implies usage for searching Weibo content but provides no explicit guidance on when to use this tool versus alternatives, nor 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.
根据关键词搜索微博话题。
返回: list[dict]: 包含搜索结果的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| limit | No | 返回结果数量上限，默认 15 | |
| page | No | 分页页码，默认 1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the return type as a list of dicts, but does not mention read-only behavior, rate limits, or any side effects. The search nature implies idempotency, but it is not explicitly stated.
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 short and concise, consisting of one line for purpose and one line for return type. It is front-loaded with the action. However, it could be slightly expanded without becoming verbose.
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 existence of an output schema and three parameters, the description is quite minimal. It does not explain pagination behavior, default values (though in schema), or any edge cases. For a search tool, more context about result ordering or limitations would be expected.
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 the baseline is 3. The description does not add any additional meaning to the parameters beyond what is in the schema. The parameters (keyword, limit, page) are self-explanatory but no further elaboration is given.
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 'search Weibo topics by keyword', providing a specific verb and resource. It is distinct from sibling tools like 'search_content' and 'search_users' which search different resources, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'search_content' or 'get_trendings'. There is no mention of context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据关键词搜索微博用户。
返回: list[dict]: 包含用户信息的字典列表
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| limit | No | 返回用户数量上限，默认 5 | |
| page | No | 分页页码，默认 1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions the return type (list of dicts) without explaining pagination, result limits, or behavior on no results. Lacks depth on traits like rate limits or data freshness.
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 extremely concise (two sentences) and front-loaded with the action. Every word is meaningful, with no fluff.
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's simplicity (basic search with pagination), the description is adequate but incomplete. It does not explain pagination behavior, sorting, or error handling. The presence of an output schema (not shown) reduces the need for return value details, but behavioral gaps remain.
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 description coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond the schema, earning the baseline score of 3.
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 searches Weibo users by keyword, using a specific verb and resource. It distinguishes itself from sibling tools like search_content and search_topics by targeting user entities.
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 usage for searching users but does not provide explicit guidance on when to choose this tool over alternatives like search_content or search_topics. No exclusions or context are given.
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.
v0.1.0get_commentsget_fansget_feedsget_followersget_hot_feedsget_profileget_trendingssearch_contentsearch_topicssearch_usersEach tool targets a distinct aspect of Weibo data: comments, fans, feeds, followers, hot feeds, profile, trending, and searches for content, topics, and users. No two tools have overlapping purposes.
All tools follow a consistent verb_noun pattern using snake_case: get_* for retrieval and search_* for searching. This makes the set predictable and easy to navigate.
10 tools cover the essential read operations for a Weibo server without being excessive. Each tool earns its place, providing a well-scoped interface.
The set covers core read operations: user profile, feeds, comments, followers/fans, trending, and search across multiple dimensions. Missing might be a direct 'get_post' endpoint, but feeds and search suffice. Limited to read-only, which is acceptable for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Weibo hot search, post search/details, comments/replies, users, posts, transcript.
搜索笔记、浏览首页推荐、查看笔记内容与评论，并发表你的评论。直接在工作流中与小红书内容互动，高效跟进话题。
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Search public social posts and web results from AI assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/InfernalAzazel/mcp-server-weibo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server