smart-search

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific search domains (e.g., GitHub, StackOverflow, Aliyun docs, WeChat docs). The descriptions explicitly differentiate each by platform/content type, leaving no ambiguity about which tool to use for which search target.
Naming Consistency5/5
All tools follow a perfect verb_noun pattern with 'ai_search_' prefix followed by the target platform/domain (e.g., ai_search_github, ai_search_stackoverflow). This consistent naming makes it easy to predict and identify tools across the set.
Tool Count4/5
With 14 tools, the count is slightly high but reasonable for a comprehensive search server covering multiple platforms. Each tool adds value by targeting a distinct search domain, though some could potentially be consolidated (e.g., multiple cloud docs tools).
Completeness3/5
The server provides broad coverage across many search domains but has notable gaps in functionality. All tools only return URLs requiring external fetching, lacking direct search execution or result parsing. This creates workflow dependencies and limits standalone utility for the stated 'smart-search' purpose.
Average 3.5/5 across 14 of 14 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 status not available
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns documentation search URLs rather than actual content, and instructs to use WebFetch for real results, which is valuable behavioral context. However, it doesn't mention rate limits, authentication needs, or what happens with invalid queries/frameworks.
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 brief with two sentences that each serve distinct purposes: stating the tool's function and providing important usage instructions. The emoji and formatting are slightly decorative but don't detract significantly from clarity.
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 no annotations, no output schema, and 0% schema description coverage for a 2-parameter tool, the description is incomplete. While it explains the URL-returning behavior, it lacks crucial information about parameter usage, expected outputs beyond URLs, and error handling for a search tool with many sibling alternatives.
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?
With 0% schema description coverage and 2 parameters (query, framework), the description provides no information about parameter meanings, formats, or constraints. The mention of frameworks like React/Vue/Node.js hints at possible values for the 'framework' parameter but doesn't explain its purpose or relationship to 'query'.
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 searches official documentation for common frameworks and tools like React, Vue, and Node.js, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from its many siblings (e.g., ai_search_web, ai_search_stackoverflow) beyond mentioning 'official documentation' versus other sources.
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 for searching official framework/tool documentation, but doesn't provide explicit guidance on when to use this tool versus alternatives like ai_search_web or ai_search_stackoverflow. The mention that Claude Code should use WebFetch for the returned URLs provides some context but not clear selection criteria.
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 provided, the description carries the full burden. It discloses that the tool returns search URLs rather than actual content, and that a separate WebFetch tool is needed to get results. However, it doesn't mention important behavioral aspects like rate limits, authentication needs, error handling, or what format the URLs are returned in. The description adds some value but leaves significant gaps for a tool with 3 parameters and no output schema.
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. The first sentence clearly states the purpose with emoji and engine list. The second provides important implementation guidance. Both sentences earn their place, though the structure could be slightly improved by front-loading the most critical information more explicitly.
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 3 parameters with 0% schema coverage, no annotations, no output schema, and many sibling tools, the description is incomplete. It doesn't explain parameter usage, return format, error conditions, or differentiation from specialized search siblings. While it provides the crucial insight about URL returns requiring WebFetch, this alone is insufficient for a tool of this complexity and context.
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?
With 0% schema description coverage and 3 parameters (query, engine, count), the description provides no information about any parameters. It doesn't explain what the 'engine' parameter accepts (presumably one of the listed search engines), what 'count' controls (number of results?), or any formatting requirements for the 'query'. The description fails to compensate for the complete lack of schema 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 clearly states the tool performs '通用网络搜索' (general web search) and lists specific search engines (Google/Bing/百度/搜狗), which provides a specific verb+resource. However, it doesn't explicitly differentiate from its many sibling tools that appear to be specialized searches (docs, API references, specific platforms), leaving some ambiguity about when to choose this general tool versus the specialized ones.
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 through the instruction that Claude Code should use WebFetch to access returned URLs, providing some context about how results are obtained. However, there's no explicit guidance on when to use this tool versus its many specialized sibling tools (like ai_search_docs, ai_search_github, etc.), nor any mention of alternatives or exclusions.
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 full burden of behavioral disclosure. It helpfully explains that the tool returns search URLs rather than direct results, and that Claude Code should use WebFetch to access them. This clarifies the tool's workflow and output behavior. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions.
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. The first sentence clearly states the purpose, and the second provides important behavioral context about the URL output and WebFetch requirement. There's minimal wasted text, though the emoji and formatting could be considered slightly decorative.
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 complexity (2 undocumented parameters, no annotations, no output schema), the description is incomplete. While it explains the tool's purpose and output workflow well, it fails to address the parameter meanings or provide any information about the search results format. For a tool with undocumented parameters and no structured output information, more context is needed.
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?
The input schema has 2 parameters (api_name, platform) with 0% description coverage, meaning neither parameter is documented in the schema. The description provides no information about what these parameters mean, what values they accept, or how they affect the search. This leaves the parameters completely unexplained despite the schema coverage gap.
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: 'API参考搜索 - 快速查找API文档和使用示例' (API reference search - quickly find API documentation and usage examples). It specifies the verb ('搜索' - search) and resource ('API文档和使用示例' - API documentation and usage examples). However, it doesn't explicitly differentiate from sibling tools like 'ai_search_docs' or 'ai_search_web', which appear to be similar search tools.
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 provides some implied usage guidance: it mentions that the tool returns search URLs that should be accessed with WebFetch, suggesting this is a preliminary step rather than a direct search. However, it doesn't explicitly state when to use this tool versus the many sibling search tools (e.g., ai_search_docs, ai_search_web, ai_search_stackoverflow), nor does it provide clear alternatives or exclusions.
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 provided, the description carries the full burden. It discloses that the tool returns URLs rather than direct content and requires WebFetch for actual results, which is valuable behavioral context. However, it doesn't mention rate limits, authentication needs, error conditions, or what happens with the optional 'product' parameter.
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 with just two sentences, both carrying essential information. The first establishes purpose, the second provides critical behavioral guidance. No wasted words, and the important WebFetch requirement is front-loaded with the 【重要】marker.
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 search tool with 2 parameters (one undocumented), no annotations, and no output schema, the description provides adequate basic purpose and a crucial behavioral note about URL returns. However, it lacks details about parameter usage, result format expectations, and doesn't fully compensate for the missing structured documentation.
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 mentions 'query' implicitly through the search context but doesn't explain either parameter's purpose, format, or constraints. The optional 'product' parameter is completely undocumented in both schema and description, leaving significant gaps.
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 searches Alibaba Cloud documentation and APIs ('搜索阿里云产品文档和API'), providing a specific verb and resource. It distinguishes from siblings by specifying the Alibaba Cloud domain, though it doesn't explicitly contrast with other search tools like 'ai_search_tencent_docs' or 'ai_search_docs'.
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 provides clear context for when to use this tool: for searching Alibaba Cloud documentation. It includes an important note about requiring WebFetch to access results, which is helpful guidance. However, it doesn't explicitly state when NOT to use it or name alternatives among the many sibling search tools.
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 provided, the description carries the full burden of behavioral disclosure. It reveals a key behavioral trait: the tool returns a search URL rather than the actual search results, and specifies that Claude Code should use WebFetch to access that URL. This is valuable context beyond what the input schema provides. However, it doesn't mention other behavioral aspects like rate limits, authentication needs, or error conditions.
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 well-structured. The first sentence states the core purpose, and the second sentence provides crucial behavioral guidance. Both sentences earn their place, with no wasted words. The emoji and formatting (【重要】) help with visual organization without being verbose.
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 URL return), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It helpfully explains the URL return behavior and WebFetch requirement, but doesn't cover parameter semantics, error handling, or result format. The description adds value but leaves significant gaps for a tool with no structured documentation support.
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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. While the description mentions '搜索' (search), it doesn't explain the 'query' parameter's semantics, format, or constraints. The description adds no meaningful information about the parameter beyond what's implied by the tool name and general search context.
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 CNBlogs technical blogs). It specifies the verb ('搜索' - search) and resource ('博客园技术博客' - CNBlogs technical blogs), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'ai_search_csdn' or 'ai_search_juejin' beyond mentioning the specific platform.
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 provides clear context for when to use this tool: for searching CNBlogs technical blogs. The second sentence offers guidance on what to do with the output (use WebFetch tool to access the URL). However, it doesn't explicitly state when NOT to use this tool or mention alternatives among the many sibling search tools.
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 full burden. It discloses key behavioral traits: the tool returns CSDN search URLs rather than actual content, and requires follow-up with WebFetch tool to get results. This is valuable context beyond what the input schema provides about the tool's operational behavior.
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 efficiently structured with an emoji icon, clear title, and two focused sentences. The first states the purpose, the second provides critical implementation guidance. Every element earns its place with no wasted words.
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 URL return pattern), no annotations, no output schema, and 0% schema description coverage, the description is partially complete. It explains the URL return behavior well but lacks parameter documentation and doesn't describe what the returned URLs contain or how to interpret them.
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?
With 0% schema description coverage for 2 parameters (query and type), the description provides no information about parameter meanings, formats, or usage. The schema alone shows query is required and type is optional, but the description adds no semantic context about what these parameters represent or how they affect the search.
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 searches CSDN for technical blogs and Q&A, providing a specific verb ('搜索') and resource ('CSDN技术博客和问答'). It distinguishes from siblings by specifying the CSDN platform, though it doesn't explicitly contrast with other search tools like ai_search_github or ai_search_stackoverflow.
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 searching CSDN content, but doesn't provide explicit guidance on when to use this tool versus alternatives like ai_search_github or ai_search_stackoverflow. The second sentence provides important implementation guidance but not comparative usage context.
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 full burden. It discloses key behavioral traits: it returns a URL (not direct results) and requires a follow-up WebFetch call to get actual content. This clarifies the tool's limited scope and workflow dependency, though it doesn't mention rate limits, authentication needs, or error handling.
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 efficiently structured with an emoji icon, clear title-like line, and a focused 'important' note. Both sentences earn their place: the first states the purpose, the second explains critical behavioral constraints. No wasted words or redundancy.
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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It adequately covers the tool's purpose and key behavioral limitation (URL return), but misses parameter explanations, error cases, and output details. For a search tool with undocumented parameters, this leaves significant gaps.
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 provides no information about the 'query' (required) or 'tags' parameters—not explaining their purpose, format, or examples. The description fails to add meaning beyond the bare schema, leaving parameters semantically undocumented.
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 searches SegmentFault for technical Q&A and articles, specifying both the action (search) and resource (SegmentFault content). It distinguishes itself from siblings by targeting SegmentFault specifically, though it doesn't explicitly contrast with other search tools like ai_search_stackoverflow or ai_search_csdn.
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 for searching SegmentFault content, but provides no explicit guidance on when to choose this tool over sibling search tools (e.g., ai_search_stackoverflow for English content or ai_search_csdn for Chinese blogs). The 'important' note about using WebFetch for results is procedural rather than contextual 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?
With no annotations provided, the description carries full burden. It discloses the critical behavioral trait that the tool returns a StackOverflow search URL rather than actual search results, and explicitly instructs Claude Code to use WebFetch to access that URL. This is valuable context beyond what the input schema provides.
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 with only two sentences, both of which earn their place. The first sentence states the purpose, and the second provides critical behavioral information about URL returns and WebFetch usage.
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 search tool with 3 parameters (0% schema coverage) and no output schema, the description provides adequate purpose and behavioral context but leaves parameters completely undocumented. The description covers the essential 'what it does' and 'what it returns' but doesn't address parameter usage.
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?
The description provides no information about any of the three parameters (query, tags, sort), and schema description coverage is 0%. The description doesn't compensate for this gap by explaining what these parameters mean or how they affect the search.
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 searches StackOverflow for technical problems and solutions, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like ai_search_github or ai_search_web beyond mentioning StackOverflow specifically.
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 context by specifying 'technical problems and solutions' and mentions that Claude Code should use WebFetch to access the returned URL. However, it doesn't provide explicit guidance on when to choose this tool versus other search siblings like ai_search_github or ai_search_docs.
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 full burden and does well by disclosing key behavioral traits: it returns URLs rather than content directly, and requires a separate WebFetch tool to get actual results. This clarifies the tool's role as a search gateway with a two-step process, which is valuable context beyond basic functionality.
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 with just two sentences that each earn their place: the first states the core functionality, the second provides crucial behavioral guidance about the URL return and WebFetch requirement. No wasted words, front-loaded with essential information.
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 gateway with 2 parameters), no annotations, no output schema, and 0% schema coverage, the description provides adequate but incomplete context. It explains the behavioral workflow well but leaves parameters undocumented and doesn't describe the URL format or any limitations. For a search tool with siblings, more differentiation would be helpful.
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?
With 0% schema description coverage for 2 parameters (query and product), the description provides no information about what these parameters mean, their format, or how they affect the search. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving both parameters semantically undefined.
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 searches Tencent Cloud product documentation and APIs with a specific verb ('搜索' meaning search) and resource ('腾讯云产品文档和API'). It distinguishes from siblings by specifying the Tencent Cloud focus, though it doesn't explicitly contrast with other search tools like ai_search_aliyun_docs or ai_search_web.
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 provides implied usage context by mentioning it returns URLs that should be accessed with WebFetch tool, suggesting this is a search gateway rather than direct content retrieval. However, it doesn't explicitly state when to use this vs. other search tools like ai_search_aliyun_docs or ai_search_api_reference, nor does it provide exclusion criteria.
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 full burden. It discloses key behavioral traits: the tool returns search URLs rather than actual content, and Claude Code should use WebFetch to access those URLs. This is valuable context about the tool's output format and required follow-up actions, though it doesn't cover rate limits, authentication needs, or error handling.
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 efficient with two sentences: one stating the purpose and scope, and another providing crucial behavioral information. Every element earns its place, and the important implementation note is appropriately highlighted.
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 search tool with no annotations, no output schema, and 2 undocumented parameters, the description provides adequate purpose and behavioral context but leaves significant gaps. It explains what the tool does and how to use its output, but doesn't address parameter meanings, result formats, or error conditions that would be needed for complete understanding.
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?
With 0% schema description coverage for 2 parameters, the description provides no information about what 'query' or 'platform' parameters mean, their formats, or valid values. The description doesn't compensate for the complete lack of parameter documentation in the schema.
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 searches WeChat developer documentation for mini-programs, public accounts, and open platform docs. It specifies the resource (WeChat docs) and verb (search), but doesn't explicitly differentiate from sibling tools like ai_search_tencent_docs or ai_search_docs beyond mentioning WeChat specifically.
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 context by specifying WeChat documentation search, but doesn't provide explicit guidance on when to use this tool versus alternatives like ai_search_tencent_docs or ai_search_docs. The important note about using WebFetch for actual results provides implementation guidance rather than selection 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?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: that the tool returns GitHub search URLs rather than direct results, and that Claude Code should use WebFetch to access those URLs. This is valuable context about the tool's output format and required follow-up actions. However, it doesn't mention rate limits, authentication needs, or error conditions.
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 with just two sentences, both of which earn their place. The first establishes purpose, the second provides critical behavioral guidance. The emoji adds visual distinction without being distracting. The structure is front-loaded with the core functionality.
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 4-parameter tool with 0% schema coverage and no output schema, the description is incomplete. While it provides excellent guidance about the tool's output format and required follow-up actions, it completely neglects parameter semantics. The behavioral transparency is good but doesn't cover all aspects needed for a search tool with multiple parameters.
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. The description provides no information about any of the 4 parameters (query, type, language, sort). It doesn't explain what these parameters mean, what values they accept, or how they affect the search. This leaves significant gaps in understanding how to use the tool effectively.
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 searches GitHub repositories, code, issues, and users, which is a specific verb+resource combination. It distinguishes from sibling tools by specifying GitHub as the target platform. However, it doesn't fully differentiate from all siblings since many are also search tools for different platforms.
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 provides explicit guidance about when to use this tool: for searching GitHub content. It also provides important usage context by stating that the tool returns GitHub search URLs that should be accessed with WebFetch. However, it doesn't specify when NOT to use it or explicitly name alternatives among the many sibling search tools.
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 provided, the description carries full burden. It discloses the key behavioral trait that the tool returns URLs rather than actual search results, which is crucial information. However, it doesn't mention rate limits, authentication requirements, pagination behavior, or error handling that would be helpful for a search 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?
The description is extremely concise with only two sentences, both of which earn their place. The first establishes purpose, the second provides critical usage guidance. The emoji and formatting (【重要】) help with visual structure without adding unnecessary content.
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 2 parameters), no annotations, no output schema, and 0% schema coverage, the description is incomplete. While it covers the crucial behavioral aspect (returns URLs), it lacks parameter documentation and doesn't explain what the output looks like beyond 'URLs'. The WebFetch guidance helps but doesn't fully compensate for missing documentation.
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?
With 0% schema description coverage and 2 parameters (query and sort), the description provides no information about parameter semantics. It doesn't explain what the query parameter expects, what the sort parameter does, or what sorting options are available. The description fails to compensate for the complete lack of schema 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 clearly states the tool searches for articles on the Juejin technical community platform ('搜索掘金技术社区文章'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like ai_search_csdn or ai_search_segmentfault that also search Chinese tech communities, missing full sibling differentiation.
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 provides explicit usage guidance with the 【重要】 section stating '此工具会返回掘金搜索URL，Claude Code应该使用WebFetch工具访问该URL以获取真实搜索结果' - this clearly indicates when to use this tool (to get search URLs) and what alternative tool to use next (WebFetch for actual results), creating a complete workflow context.
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 full burden. It discloses key behavioral traits: the tool returns URLs rather than direct search results, and requires a secondary tool (WebFetch) to get actual content. This is valuable context about the tool's output format and workflow requirements that isn't obvious from the schema alone.
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 essential information. The first sentence states the purpose, the second provides critical usage guidance. Every sentence earns its place, with no wasted words or redundant information.
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 search tool with no annotations and no output schema, the description provides good workflow guidance but lacks parameter details. It explains what the tool does and how to use its output, but doesn't cover what the parameters mean or what the return format looks like beyond 'NPM search URL'.
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 provides no information about the 'query' or 'size' parameters beyond what the schema indicates (string and number types). The description doesn't explain what the query should contain, what 'size' controls, or any parameter constraints or examples.
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 searches for NPM packages and related documentation ('搜索NPM包和相关文档'), providing a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools like ai_search_github or ai_search_web, which likely search different platforms.
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 provides explicit usage guidance: it states the tool returns NPM search URLs and instructs Claude Code to use WebFetch to access the actual results. This clearly indicates when to use this tool (for NPM searches) and what to do with its output, distinguishing it from direct web search tools.
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 full burden. It discloses the critical behavioral trait that this tool returns URLs rather than direct search results, and that Claude Code must use WebFetch to access those URLs. This is valuable context about the tool's output format and required follow-up actions, though it doesn't cover rate limits, authentication needs, or error handling.
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 perfectly concise with just two sentences. The first establishes purpose, the second provides critical behavioral guidance. Every word earns its place, and the important warning is appropriately emphasized with 【重要】markers.
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 no annotations, 0% schema coverage, no output schema, and 2 parameters, the description is incomplete. It covers the tool's purpose and output behavior well but completely neglects parameter documentation. For a search tool with query and type parameters, users need to know what 'type' controls (e.g., news vs. projects vs. blogs).
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 fails to do so. It mentions no parameters at all, leaving both 'query' and 'type' completely undocumented. The description adds zero semantic information about what these parameters mean or how to use them.
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 searches for '开源中国技术资讯和项目' (Open Source China technical information and projects), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like ai_search_github or ai_search_csdn beyond the platform name, missing direct sibling comparison.
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 provides explicit usage guidance with the 【重要】note stating this tool returns URLs that require WebFetch to access real results. This clearly indicates when to use this tool (for Open Source China searches) and what to do with its output, though it doesn't mention when NOT to use it versus alternatives.
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:

[![1777316659826691 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659826691/badges/card.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659826691)

Score Badge

Copy to your README.md:

[![1777316659826691 MCP server](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659826691/badges/score.svg)](https://glama.ai/mcp/servers/xiaobenyang-com/1777316659826691)

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/xiaobenyang-com/1777316659826691'

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