wechat-mp-search
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
weixin_search and weixin_search_all both search Sogou WeChat articles, but their descriptions clearly distinguish single-page vs aggregated multi-page results. get_weixin_article_content is a separate retrieval step with no overlap.
Naming Consistency3/5The weixin_search and weixin_search_all names share a consistent prefix and action style, but get_weixin_article_content breaks the pattern by leading with get_ and placing article before content. The naming is still readable, just not uniformly structured.
Tool Count5/5Three tools is appropriately scoped for a focused WeChat article search-and-read server. Each tool has a distinct role: one-page search, multi-page search, and content retrieval.
Completeness5/5For the stated purpose of searching WeChat public account articles and reading article text, the surface is complete. Search covers both quick single-page and full paginated needs, and content fetching provides the end-to-end workflow.
Average 3.8/5 across 3 of 3 tools scored.
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 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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait: on failure it returns a message starting with '获取文章内容失败:' instead of raising an error, and it returns plain text. However, it omits other potentially relevant behaviors such as authentication requirements or rate limits, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary purpose and then adds the essential failure-behavior note. There is no wasted wording or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward fetch-content tool, the description covers the core action, the output type (plain text), and the failure mode. The lack of an output schema is mitigated by mentioning '纯文本'. Minor gaps like referer usage are already covered by the schema's parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 does not add any parameter-level semantics beyond the schema, but it doesn't need to because the schema already documents both parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('抓取' / fetch) and a specific resource ('微信公众号文章正文纯文本' / WeChat article body plain text). This clearly distinguishes it from the sibling search tools (weixin_search, weixin_search_all), which find articles rather than retrieve their 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/5Does 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 the sibling search tools. The description only explains what the tool does and its failure behavior, leaving the agent to infer usage context from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool searches Sogou WeChat and returns one page, which is a useful behavioral trait. However, it omits operational details such as possible anti-bot/captcha behavior, per-page result count, and whether the return value is raw HTML or parsed results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence that leads with the action and platform, then states the single-page return behavior. It contains no filler and does not duplicate schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two well-documented parameters and no nested objects, invocation is simple. However, there is no output schema and the description only says '返回单页结果', leaving the return format and contents unspecified, which is a notable gap for downstream planning, especially with the sibling get_weixin_article_content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes both parameters with 100% coverage: 'query' is '搜索关键词' and 'page' is 1-based with a default of 1. The description adds no parameter-specific detail, but the schema already carries that burden, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a specific action ('搜索'), a target ('微信公众号文章'), and a named platform ('搜狗微信搜索/weixin.sogou.com'). The phrase '返回单页结果' distinguishes this tool from the sibling weixin_search_all, so an agent can identify it 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description's '返回单页结果' gives clear contextual scope: this tool is for retrieving a single page of search results. It does not explicitly say to use weixin_search_all for all pages, so it lacks an explicit alternative, but the context is clear enough for selection.
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 of behavioral disclosure. It explains that the tool automatically turns pages, aggregates results, and stops under three named conditions (empty page, anti-crawler interception, page limit). This is useful context beyond simply saying 'search'. It doesn't cover auth requirements or return format, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the main action and resource, then provides the termination logic. Every part contributes essential information, with no redundant filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description covers the key functional behavior and edge cases (stopping conditions) well. It does not describe the return format or error handling for anti-crawler interception, but the parameter schema is fully covered and the invocation logic is clear. Minor gap: it doesn't explain what 'aggregated results' look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 no new meaning to the parameters beyond what the schema already provides: the 'query' is a keyword and 'max_pages' is a page count with a default and hard limit. The tool description's mention of 'page limit' aligns with but does not exceed the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('自动翻页搜索' - automatically paginate search) and clearly identifies the resource ('微信公众号文章') and action ('聚合结果' - aggregate results). It also lists explicit termination conditions (empty page, anti-crawler interception, page limit), which distinguishes it from the likely single-page sibling 'weixin_search' and the content-fetching sibling 'get_weixin_article_content'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent can infer this tool is for multi-page search aggregation because it explicitly mentions pagination and aggregation. However, the description does not either explicitly say when to use this vs. the sibling 'weixin_search' or state any exclusions. No alternatives are named.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/iTraceur/dsh-wechat-mp-search'
If you have feedback or need assistance with the MCP directory API, please join our Discord server