wechat-reader-mcp

by xiguawang

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes: reading from a URL vs. reading from a tab, listing tabs, and setup are clear. However, wechat_open_article and wechat_get_status both return status information without full extraction, which could cause confusion in selection.
Naming Consistency5/5
All tool names follow a consistent wechat_ + verb + noun pattern (e.g., wechat_read_article, wechat_list_tabs, wechat_get_status). Even wechat_setup is a common single-word exception that fits the scheme and doesn't disrupt predictability.
Tool Count5/5
Six tools is well within the ideal 3-15 range. Each tool serves a clear purpose in the article-reading workflow (setup, list tabs, open, read, status), and none are redundant.
Completeness5/5
The tool set covers the core lifecycle for reading WeChat articles through a browser bridge: setup, tab discovery, opening URLs, reading from URL or tab, and status checks. No critical operations are missing for the stated scope.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
The description implies a read-only operation with the verb 'Read,' but the annotation readOnlyHint=false states the tool is NOT read-only. This is a direct contradiction, and no further context is provided to clarify actual 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 one concise sentence that clearly states the default and optional behavior without unnecessary detail. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits clarification of what 'attachable' means and conflicts with the tool name ('current tab' vs. 'first attachable'). However, the schema covers parameters and an output schema exists, so the description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all nine parameters described in the input schema. The description only references tab_id, adding no new semantics beyond the schema's existing documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Read' with the resource 'WeChat tab' and clarifies the default behavior (first attachable) and the alternative (specific tab by tab_id). It clearly distinguishes this from sibling tools like 'wechat_read_article' (reads an article) and 'wechat_list_tabs' (lists tabs).
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 a usage pattern: use no tab_id for the first attachable tab, or provide tab_id for a specific tab. However, it does not explicitly state when to choose this tool over siblings or mention that tab_id can be obtained from wechat_list_tabs.
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?
Annotations provide no safety hints (all false), so the description must disclose behavioral traits. It only mentions reading and returning data, without revealing side effects such as launching a browser, handling captchas, or waiting for manual verification. Key schema parameters like 'strategy', 'channel', and 'wait_for_manual_verify' imply complex behavior that is left undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and expected result. No wasted words; it is appropriately front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters with rich schema descriptions and an output schema, so the description doesn't need to explain returns. However, it is minimal and doesn't mention the captcha-wrapper support or browser launch/attach strategies, which are important for an agent to invoke it correctly in varied scenarios. It is minimally viable but lacks depth.
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 every parameter documented (e.g., url, cdp_url, channel, timeout). The description adds no parameter-specific meaning beyond what the schema already provides, which is acceptable given the baseline for full 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 tool reads a WeChat article URL via a local browser bridge and returns structured data or status. It uses a specific verb ('read') and resource ('WeChat article URL'), distinguishing it from siblings like wechat_open_article and wechat_read_current_tab.
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 (when you have a WeChat article URL to read) but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention exclusions or preferred scenarios, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, idempotent, or destructive, providing a baseline. The description adds that it returns 'structured page status' and emphasizes the lack of full extraction, but it does not disclose side effects like browser launch, tab management, or manual verification waits that are visible in the schema. With annotations present, this is moderate added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the primary action and key differentiator. There is no redundant information, and every phrase contributes value.
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 tool with 9 parameters and a complex browser-related workflow, the description is minimal. The presence of an output schema and annotations helps, but it does not guide parameter selection or explain the tool's role relative to siblings, making it complete only at a basic level.
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 provides 100% description coverage for all 9 parameters, so the description does not need to explain parameter details. The tool description adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a WeChat article URL') and the result ('return structured page status'), while the phrase 'without requiring full extraction' explicitly distinguishes it from the sibling tool wechat_read_article. This is a specific verb+resource+scope formulation.
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 phrase 'without requiring full extraction' implies a use case (checking status without full content) but does not explicitly name alternatives or state when not to use this tool. The guidance is present only implicitly, not as direct usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description does not contradict. The description adds minimal extra context (e.g., 'local browser bridge'), but no additional behavioral traits like failure modes or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It precisely communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only diagnostic tool with zero parameters, an output schema, and comprehensive annotations, the description is sufficiently complete. It clearly states what is returned without needing to explain return values because the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so there is no need for parameter explanation. The baseline for zero-parameter tools is 4, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns local browser bridge diagnostics and setup guidance', using a specific verb and resource. It distinguishes from siblings like wechat_get_status or wechat_read_article by focusing on bridge setup rather than article/tab operations.
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 explicit guidance on when to use this tool versus alternatives like wechat_get_status, nor does it mention prerequisites or exclusions. Usage is only implied by the tool's purpose, which is insufficient per the rubric.
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?
The description adds a behavioral nuance ('without requiring a full successful read'), but annotations provide no safety profile (readOnlyHint=false, destructiveHint=false). It does not disclose potential side effects like browser launching, profile usage, or manual verification waits, leaving the agent to infer safety from the 'inspect' wording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and key differentiator without any filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 self-documenting parameters and an output schema, the description need not cover every detail. It clearly states the tool's purpose and key operational nuance. However, it omits guidance on browser strategy, profile selection, or verification behavior, which are relevant given the parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by connecting 'article URL' and 'current tab' to the url/tab_id parameters, but it does not elaborate on optionality, defaults, or parameter interactions.
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 ('Inspect') and resource ('WeChat article URL or the current WeChat tab'), and distinguishes from sibling read tools by noting it works 'without requiring a full successful read'. This clearly separates it from wechat_read_article and wechat_read_current_tab.
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 gives clear context: it is a lightweight status inspection that does not need a full read. However, it does not explicitly name alternatives or exclusion criteria beyond the implied 'full successful read' contrast, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by mentioning 'attachable browser tabs' and the default filter behavior. Annotations already indicate read-only and idempotent operations, so the description enriches rather than repeats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and default behavior with no wasted words. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with optional parameters and an output schema present, which documents return values. The description covers the key behavior (listing tabs, default filter) without needing to elaborate further. Annotations provide safety context, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with descriptions for both cdp_url and wechat_only. The description adds narrative context by explaining the default filter behavior, but the schema already carries the semantic weight, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List attachable browser tabs' with a specific verb and resource, and mentions the default WeChat filter. This distinguishes it from sibling tools like wechat_read_article and wechat_open_article, which perform different operations.
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 implies usage context by stating it lists attachable tabs filtered to WeChat by default, making it clear when to use it for discovering available tabs. It does not explicitly name alternatives or exclusions, but the sibling tools are distinct enough that usage is clear.
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:

[![wechat-reader MCP server](https://glama.ai/mcp/servers/xiguawang/wechat-reader/badges/card.svg)](https://glama.ai/mcp/servers/xiguawang/wechat-reader)

Score Badge

Copy to your README.md:

[![wechat-reader MCP server](https://glama.ai/mcp/servers/xiguawang/wechat-reader/badges/score.svg)](https://glama.ai/mcp/servers/xiguawang/wechat-reader)

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/xiguawang/wechat-reader'

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