qzone-mcp

by inzzou

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
工具总体边界清晰，按帖子、点赞、评论、访客等资源区分明确。但 qzone_like 兼容 unlike 参数与独立 qzone_unlike 功能重叠，可能在取消点赞时造成选择歧义。
Naming Consistency4/5
大多数工具遵循 qzone_<动词> 的 snake_case 命名，整体可预测。但 qzone_status 和 qzone_visitors 是名词形式，qzone_delete 也缺少明确宾语，存在少量不一致。
Tool Count5/5
12 个工具覆盖状态检查、说说读写、点赞评论和访客信息，规模适中。即使包含 prepare/confirm 两步发布和独立 unlike，也没有臃肿感，每个工具都有明确用途。
Completeness4/5
覆盖了说说读取、发布、删除以及点赞、评论、回复、访客等核心社交动作，整体闭环较完整。但缺少更新说说、独立评论列表和删除评论等能力，属于可绕过的小缺口。
Average 3.3/5 across 12 of 12 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 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.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only restates the obvious action in Chinese. It does not mention that this creates a public comment, whether authentication/session state is required, whether the action is reversible, or any rate-limit/error considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A one-sentence phrase adds no structured value beyond the tool name and fails to convey essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, the description is far too thin to support correct invocation. It gives no guidance on parameter semantics, required conditions, or result/response expectations, making it incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The roles of hostuin, fid, content, and appid are left entirely unexplained, so the agent cannot determine what values to supply or why they are required.
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 a specific action (comment) on a specific resource (a QZone status/feed). It is distinguishable from obvious siblings like like, delete, and publish, though it does not explicitly contrast with qzone_reply_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives or when not to use it. The name and description imply 'use this to comment on a post,' but no explicit selection criteria are provided relative to sibling tools like reply_comment or unlike.
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. The verb '读取' implies a read-only operation, but there is no mention of authentication needs, ownership restrictions, error behavior, or whether any side effects occur. This is minimal and not misleading, but far from transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line description is concise and front-loaded, but it is so terse that it under-specifies the tool. It lacks parameter semantics and usage context, making the brevity a deficiency rather than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter coverage, the description is far from complete. It does not explain the meaning of the required parameters, does not state what the response contains, and does not give any context about when this tool is appropriate. An agent would struggle to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters: fid, hostuin, or appid. The required identifiers are completely opaque, so an agent cannot reliably know what values to provide for fid and hostuin. The description adds no parameter-level meaning whatsoever.
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 and resource: '读取一条说说详情' means read one post's details. This distinguishes it from qzone_list_posts, which implies reading multiple posts. However, it does not explicitly differentiate it from qzone_status, which could be a similar status-related operation.
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 instead of siblings, no preconditions, and no exclusions. An agent can only infer that this tool fetches a single post, likely by fid, but no explicit context is given for choosing it over qzone_status or qzone_list_posts.
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 the action without explaining side effects, permission requirements, whether the reply is posted immediately, idempotency, or error behavior. The mutation nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words and is immediately clear in its core action. However, it is arguably too terse relative to the complexity of the tool, trusting the agent to infer too much from a minimal phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with six parameters, no annotations, no output schema, and no parameter documentation. The description provides only the basic action and leaves the agent without enough information about required identifiers, return behavior, or constraints, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no parameter explanations. Parameter names like hostuin, fid, commentid, and comment_uin are only partially self-explanatory and would be ambiguous without QQ/QZone domain knowledge. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('回复' / reply) and a specific resource ('一条说说评论' / a comment on a status), so an agent can understand the core action. It does not explicitly distinguish itself from the sibling qzone_comment, but the object being replied to is specific enough for basic purpose clarity.
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 gives no guidance on when to use this tool versus alternatives like qzone_comment, qzone_like, or qzone_delete. There are no conditions, prerequisites, or exclusions mentioned, so the agent must infer usage solely from the verb and resource.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does reveal that only the current user's own posts can be deleted, but it does not state whether deletion is permanent, what permissions are required, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The key action and scope are front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and no annotations, the description must explain parameter semantics and side effects. It only states the operation's purpose, leaving critical invocation details absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the roles of fid, appid, or created_at. An agent cannot determine which identifier selects the target post or why the defaults matter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, '删除' (delete), and names the exact resource: the current user's own 说说 (Qzone posts). This clearly distinguishes the operation from sibling tools like qzone_publish or qzone_like.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, when not to use it, or prerequisites such as needing to be the author of the post. The agent is left to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the dual like/unlike behavior and that the unlike parameter exists for backward compatibility, which is meaningful. However, it omits side effects such as idempotency, repeated calls, permission needs, or what happens when unliking an already-unliked post.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that names the core operation and includes a relevant compatibility caveat. It wastes no words, though it could be more informative without losing conciseness.
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 four parameters, no annotations, and no output schema, the description is too sparse. It fails to explain the required parameters, the relationship to the sibling qzone_unlike tool, or the expected behavior of the unlike flag. An agent has limited information to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only adds context for the unlike parameter. It does not explain the semantics of hostuin, fid, or appid beyond their schema titles. This leaves most parameters underspecified.
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 identifies a specific action — liking or unliking a Qzone post (说说). It states both supported operations and adds a backward-compatibility note about the unlike parameter. However, it does not differentiate this tool from the dedicated sibling qzone_unlike, which weakens sibling distinction.
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 explicit guidance is provided for when to use this tool versus qzone_unlike. The phrase '为兼容旧调用保留 unlike 参数' hints that unlike is supported via a legacy parameter, but it never tells an agent when to prefer one tool over the other or whether qzone_unlike is the modern entry point.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a read operation but does not explain return shape, ordering of 'recent', pagination behavior, authentication requirements, or whether any side effects occur. This leaves an agent without important expectations beyond the one-line summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the core action and resource are front-loaded. It is concise and easy to parse, though it may be too terse to carry the behavioral and parameter information an agent would benefit from.
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?
With no output schema and no annotations, the description itself must provide enough context, but it only states that recent visitors are read. Missing response format, pagination semantics, and any session or permission context make it incomplete for a robust agent decision, even though the tool can be invoked with defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the 'page' or 'count' parameters beyond what their names and defaults already imply. It doesn't explain how pagination works, what each value controls, or what ranges are valid.
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 ('读取') and a clear resource ('当前 QQ 空间最近访客'), uniquely identifying a visitor-retrieval operation. This is distinct from sibling tools focused on posts, publishing, likes, comments, and deletion, so an agent can tell them apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The read intent is implied by the verb, but the description doesn't say when an agent should choose this over sibling QZone tools.
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 the action, but does not mention side effects, whether it is idempotent, what happens if the moment is not currently liked, or any permission/authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. It is extremely concise, though its brevity comes at the cost of missing important behavioral and parameter 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?
For a tool with three parameters, no annotations, and no output schema, this minimal description is not sufficient for confident invocation. Essential context about the parameter roles and expected behavior is missing, so an agent would likely need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It does not clarify the meaning of hostuin, fid, or appid beyond the opaque schema, and it adds essentially no value for param understanding.
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 verb (unlike) and the resource (a QZone moment). It is directly distinguishable from the sibling qzone_like, making the tool's purpose unambiguous.
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 intended use is implied by the verb '取消点赞' — it is used when the agent needs to remove a like from a moment. However, it does not explicitly mention when not to use it, nor does it reference the sibling qzone_like as the alternative for adding a like.
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 present, so the description carries full burden. It explains the hostuin behavior (friend feed vs. individual space) but omits any mention of pagination (limit/cursor), ordering, authentication, or rate limits. It does not contradict any annotation.
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?
Two concise sentences with zero fluff. The purpose is front-loaded, and the key parameter behavior is stated in the second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 3 parameters and no output schema, it covers the core behavior but misses essential details about limit/cursor semantics and what the response contains. An agent might make incorrect assumptions about pagination and result shape, so completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains hostuin explicitly but says nothing about limit (number of posts) or cursor (pagination token). These are left to inference, leaving 2 of 3 parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb '读取' (read) and resource 'QQ空间动态' (QQ Space posts), with explicit distinction between friend feed (hostuin=0) and a specific user's space. This differentiates it from siblings like qzone_get_post and qzone_status, which likely target single posts or statuses.
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?
Provides clear context on when to use each hostuin mode (0 for friend feed, otherwise a specific QQ). It implies this is the tool for listing posts rather than publishing or liking, but does not explicitly name alternatives or state exclusions (e.g., 'use qzone_get_post for a single post').
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 available, the description carries the burden and discloses key behavior: it does not actually post a status and it returns a short-lived confirmation token. It stops short of explaining token expiration handling or auth, but these are secondary for a prepare operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler: it front-loads the non-destructive nature, states the returned token, and names the next tool call. Everything is relevant and compact.
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 two-parameter preparation tool with no output schema, the description covers the essential workflow and return token. It could mention token lifetime more specifically, but it is otherwise sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no parameter-level meaning. The schema names 'content' and 'images' are self-explanatory, but the description does not clarify requirements like image count, format, or the optional/nullable default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it generates a publish preview rather than posting, and it names qzone_confirm_publish as the follow-up. This makes the tool's role unambiguous and distinguishes it from qzone_publish.
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 defines the tool as a preview-only preparation step and instructs the agent to call qzone_confirm_publish for confirmation. It does not enumerate all excluded siblings, but the workflow is clear enough for correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this action performs a real publish (not a dry run) and that the token is single-use and invalidated after one use, which is the key behavioral caveat. It stops short of explaining failure modes for an invalid/expired token.
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 action and adds the critical single-use caveat. There is no filler or duplicated 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 one-parameter tool, the description covers the action, the token source, and token lifetime. It does not describe the expected return value or error behavior, but no output schema exists and the core invocation contract is adequately specified.
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?
Schema coverage is 0%, but the description compensates by explaining that the token comes from qzone_prepare_publish and becomes invalid after a single use. This gives the only parameter, confirmation_token, meaningful semantics beyond the plain string type in 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 states the exact action: use the token returned by qzone_prepare_publish to execute a real publish (执行一次真实发布). This clearly distinguishes it from the preparation step and from other Qzone operations.
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?
It explicitly names qzone_prepare_publish as the source of the confirmation token, so the expected precondition is clear. However, it does not explicitly contrast this tool with qzone_publish or state when to prefer this two-step flow over direct publishing, so alternative routing is left to inference.
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 behavioral disclosure burden. It explicitly states it '不会返回 Cookie/CSRF' (will not return Cookie/CSRF), which is a meaningful security-related behavior beyond the schema. The verb '检查' implies a read-only operation, though it doesn't explicitly guarantee no side effects; overall this is good transparency for a zero-parameter status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense Chinese sentence that front-loads the core purpose and appends the most consequential limitation (no Cookie/CSRF return). Every element earns its place, with no redundancy or filler.
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 zero parameters and no output schema, the description adequately covers what the tool checks and what it deliberately hides for security. It doesn't describe the exact return format, but for a simple status probe the missing return details are minor and the explicit exclusions add important context.
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?
There are no parameters in the schema, so schema coverage is trivially 100% and the baseline is 4. The description adds no parameter-specific meaning, but none is needed since the tool takes zero arguments.
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 identifies exact resources: QZone daemon, NapCat login credentials, and binding status. It clearly distinguishes itself from siblings like qzone_publish or qzone_delete, which are mutation tools, by framing this as a status inspection tool.
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 usage as a diagnostic/status check before or alongside other QZone operations, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. The sibling list helps, but the description itself offers no direct routing guidance.
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 burden of behavioral disclosure. It does convey that publication is immediate and non-confirmatory, but it does not mention side effects, irreversibility, authentication requirements, or failure behavior. This is useful but partial coverage.
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?
Two short sentences carry the essential action, image parameter semantics, and alternative tool guidance. No filler or redundancy is present.
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 two-parameter mutation tool, the description covers direct usage, image path details, and the key alternative. The lack of return-value or error details is a minor gap given there is no output schema, but the core call is sufficiently specified.
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 schema has 0% description coverage, so the description compensates by clarifying that images accepts multiple local absolute paths, which is meaningful beyond the schema's array-of-strings type. The required content parameter is not elaborated, but its purpose is already clear from its name and the tool's action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: '直接发布 QQ 空间说说' (directly publish a Qzone status), which is specific and not a tautology. It also implicitly differentiates from the sibling qzone_prepare_publish by emphasizing it is the direct publish path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use qzone_prepare_publish instead if confirmation before publishing is needed, and the word '直接' signals this tool is for immediate publication. This gives an agent a clear when-to-use versus alternative decision.
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

qzone-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![qzone-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/inzzou/qzone-mcp/badges/card.svg)](https://glama.ai/mcp/servers/inzzou/qzone-mcp)

Score Badge

Copy to your README.md:

[![qzone-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/inzzou/qzone-mcp/badges/score.svg)](https://glama.ai/mcp/servers/inzzou/qzone-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/inzzou/qzone-mcp'

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