Weibo MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like comments, fans, feeds, or searches, but get_feeds and get_hot_feeds could be confused as both retrieve feeds with unclear differentiation in their descriptions. The search tools (content, topics, users) are well-distinguished by their targets.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern (e.g., get_comments, search_users), using snake_case throughout. The naming is predictable and readable, with no deviations in style or convention across the set.
Tool Count5/5
With 10 tools, the count is well-scoped for a Weibo server, covering key social media functions like user profiles, feeds, searches, and interactions. Each tool appears to earn its place without feeling excessive or insufficient for the domain.
Completeness3/5
The tool set covers read operations (get, search) well but lacks obvious write or update actions like posting, commenting, or following, which are core to social media platforms. This creates notable gaps that agents cannot perform full lifecycle management, though basic retrieval workflows are supported.
Average 2.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

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

Behavior2/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 of behavioral disclosure. It mentions that the tool 'Returns: list[dict]: List of dictionaries containing comments,' which gives some output context, but it doesn't cover critical aspects like pagination behavior (implied by the 'page' parameter), rate limits, authentication needs, or error handling. For a tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two sentences that directly state the purpose and return value. There's no unnecessary information, and it's front-loaded with the main action. However, it could be slightly improved by integrating the return information more seamlessly, but it's still efficient.
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's moderate complexity (2 parameters, no annotations, no output schema), the description is partially complete. It covers the basic purpose and return format, but lacks details on behavioral traits like pagination, error cases, or how it differs from siblings. Without an output schema, more explanation of the return structure would be helpful, but it's minimally adequate.
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%, with clear descriptions for both parameters ('feed_id' as the Weibo post identifier and 'page' for pagination). The description adds no additional parameter semantics beyond what the schema provides, such as format details or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 tool's purpose: 'Get comments for a specific Weibo post.' It specifies the verb ('Get') and resource ('comments for a Weibo post'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_feeds' or 'search_content', which might also retrieve post-related data, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_feeds' (which might retrieve posts) or 'search_content' (which might include comments), nor does it specify prerequisites or exclusions. This lack of contextual usage information leaves the agent without clear direction.
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 provided, the description carries the full burden of behavioral disclosure. It mentions the return type ('list[dict]') but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: one stating the purpose and another specifying the return type. There's no unnecessary information, and it's front-loaded with the core functionality. However, the brevity comes at the cost of completeness, as it omits important usage and behavioral details.
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 complexity of a social media data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'fan information' includes, how pagination works beyond the 'page' parameter, or any limitations like maximum 'limit' values. For a tool that likely interacts with an external API and returns structured data, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (uid, limit, page) with their purposes and defaults. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the structure of fan information or pagination details. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 tool's purpose with a specific verb ('Get') and resource ('a Weibo user's fans'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'get_followers', which might retrieve a similar type of social connection data, leaving some ambiguity about when to use one versus the other.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_followers' or 'get_profile'. It lacks context about prerequisites, such as whether the user must be public or authenticated, and doesn't mention any exclusions or specific scenarios where this tool is preferred over others in the sibling list.
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 provided, the description carries the full burden of behavioral disclosure. It only states what the tool does and the return type, missing critical details like authentication requirements, rate limits, pagination behavior, or whether this is a read-only operation (though implied by 'Get').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only two sentences, front-loading the purpose and then specifying the return type. There's no wasted text, though it could be slightly more structured by integrating usage 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication, error handling, or data format details, which are crucial for a tool that fetches user data from an external service like Weibo.
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 description coverage is 100%, so the parameters 'uid' and 'limit' are fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, resulting in the baseline score of 3.
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 verb ('Get') and resource ('a Weibo user's feeds'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_hot_feeds' or 'search_content' that also retrieve feed-related data, which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_hot_feeds' for trending content or 'search_content' for filtered searches, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return type ('list[dict]') but does not cover critical aspects like rate limits, authentication needs, error handling, or pagination behavior beyond the 'page' parameter. For a read operation with no annotation support, this leaves significant gaps in understanding how the tool behaves in practice.
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 brief and front-loaded, with the core purpose stated first. The two sentences are efficient, though the return value explanation could be integrated more seamlessly. There is no redundant information, making it appropriately sized for a simple tool.
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 lack of annotations and output schema, the description is incomplete. It covers the basic purpose and return format but omits essential context like authentication requirements, rate limits, error cases, and how pagination works with the 'limit' and 'page' parameters. For a tool with three parameters and no structured behavioral hints, this leaves the agent under-informed.
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 input schema already documents all parameters (uid, limit, page) with descriptions. The tool description adds no additional semantic context beyond what the schema provides, such as explaining relationships between parameters or usage nuances. This meets the baseline for high schema coverage but does not enhance parameter understanding.
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 tool's purpose: 'Get a Weibo user's followers.' It specifies the verb ('Get') and resource ('a Weibo user's followers'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_fans' or 'get_profile,' which might also retrieve user-related data, so it misses the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_fans' and 'get_profile' that might overlap in retrieving user data, there is no indication of context, prerequisites, or exclusions. This lack of usage instructions leaves the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool returns (a list of dictionaries) without mentioning critical behaviors like whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what 'hot feeds' specifically entail (e.g., popularity-based, time-sensitive). This leaves significant gaps for safe and effective use.
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 extremely concise and front-loaded, with the core purpose stated in the first sentence and a brief return format in the second. There is no wasted language, making it easy to parse quickly while still conveying essential information.
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 lack of annotations and output schema, the description is incomplete for a tool that likely involves network calls and data retrieval. It fails to address authentication needs, error handling, the structure of returned dictionaries, or how 'hot feeds' are defined, leaving the agent with insufficient context for reliable operation.
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%, with both parameters (uid, limit) well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'hot feeds' means in relation to the uid or how the limit interacts with feed availability. This meets the baseline for high schema coverage.
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 tool's purpose with a specific verb ('Get') and resource ('a Weibo user's hot feeds'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_feeds' or 'get_trendings', which likely retrieve different types of feeds or trending content.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_feeds' (likely general feeds), 'get_trendings' (likely trending topics), and 'search_content' (likely broader searches), the agent has no indication of when 'hot feeds' are appropriate versus other feed types or search methods.
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 provided, the description carries the full burden of behavioral disclosure. It only states what the tool does and the return type, but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. This is insufficient for a tool that likely involves API calls and user data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated in the first sentence and a brief note on the return value. There's no unnecessary information, but it could be slightly more structured (e.g., separating usage notes).
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 lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs or rate limits, and while it mentions the return type, it doesn't detail the structure of the profile information. For a tool with potential complexity in API interactions, this leaves significant 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 description coverage is 100%, so the input schema already fully documents the 'uid' parameter. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain format constraints or examples). This meets the baseline score when the schema does the heavy lifting.
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 tool's purpose with a specific verb ('Get') and resource ('a Weibo user's profile information'), making it immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'get_followers' or 'search_users', which might also retrieve user-related data, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where this is preferred over other sibling tools (e.g., 'get_followers' for follower lists or 'search_users' for finding users by criteria), nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return type ('list[dict]') but lacks details on rate limits, authentication needs, error handling, or pagination behavior beyond the 'page' parameter. For a search tool with no annotations, this is insufficient to inform the agent adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated first. The 'Returns:' section is brief but could be integrated more smoothly. There's minimal waste, though the structure is slightly fragmented with the separate 'Returns:' line.
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's moderate complexity (search with pagination), no annotations, and no output schema, the description is incomplete. It covers the basic purpose and return type but misses behavioral details like result format, error cases, or usage context. It's adequate as a minimum but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as explaining search semantics or result ordering. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
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 tool's purpose: 'Search for content on Weibo based on a keyword.' It specifies the verb ('Search'), resource ('content on Weibo'), and mechanism ('based on a keyword'). However, it doesn't explicitly differentiate from sibling tools like 'search_topics' or 'search_users', which reduces it from a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_topics' for topic-based searches or 'search_users' for user searches, nor does it specify any context or exclusions for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns a list of dictionaries with search results, which adds some value, but it doesn't cover critical aspects like rate limits, authentication needs, error handling, or pagination behavior beyond the parameters. For a search tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences that directly state the purpose and return value. There's no unnecessary information, and it's front-loaded with the main action. However, the formatting with extra whitespace slightly detracts from perfect efficiency.
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's moderate complexity (search functionality with three parameters) and no annotations or output schema, the description is minimally adequate. It covers the basic purpose and return type but lacks details on behavioral traits, usage context, and output structure. This leaves gaps that could hinder effective agent operation.
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 description coverage is 100%, meaning the input schema already fully documents the three parameters (keyword, limit, page). The description doesn't add any additional meaning or context beyond what's in the schema, such as explaining how 'keyword' relates to Weibo topics or the implications of 'limit' and 'page.' With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for topics on Weibo based on a keyword.' It specifies the verb ('Search'), resource ('topics on Weibo'), and mechanism ('based on a keyword'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_content' or 'search_users,' which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_content' or 'search_users,' nor does it specify contexts or exclusions for usage. This lack of comparative information leaves the agent without clear direction for tool selection.
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 provided, the description carries full burden for behavioral disclosure. It mentions the return type ('list[dict]') but lacks critical details like authentication requirements, rate limits, error handling, or whether this is a read-only operation. For a search tool with zero annotation coverage, this leaves significant gaps.
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 appropriately concise with two sentences that directly state the purpose and return value. It's front-loaded with the core functionality, though the return format could be integrated more smoothly rather than as a separate 'Returns:' line.
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's moderate complexity (search with pagination), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and return type but lacks details on authentication, error cases, or result structure that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (keyword, limit, page). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search for') and resource ('Weibo users') with the key constraint ('based on a keyword'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_content' or 'search_topics', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_content' or 'search_topics', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.
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 provided, the description carries the full burden of behavioral disclosure. It mentions the return type (list of dictionaries) but omits critical details like rate limits, authentication needs, data freshness, or error handling. For a tool fetching live trending data, this is a significant gap.
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 appropriately sized with two sentences: one stating the purpose and another describing the return value. It is front-loaded with the core functionality, though the return type detail could be slightly more concise.
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 lack of annotations and output schema, the description is incomplete. It does not explain the structure of returned dictionaries (e.g., keys like 'title', 'rank', 'url'), potential side effects, or how the trending data is sourced, which is essential for a tool interacting with a dynamic platform like Weibo.
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 schema already documents the single parameter 'limit' with its default and description. The tool description adds no additional parameter information beyond what the schema provides, meeting the baseline for high schema coverage.
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 specific action ('Get') and resource ('current hot search topics on Weibo'), distinguishing it from siblings like search_content or search_topics which involve searching rather than retrieving trending data. The purpose is unambiguous and specific.
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 provided on when to use this tool versus alternatives like get_hot_feeds or search_topics. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
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:

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

Score Badge

Copy to your README.md:

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

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/qinyuanpei/mcp-server-weibo'

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