MyWebSearch
Server Quality Checklist
Latest release: v1.0.11
- Disambiguation4/5
Most tools have clear, distinct purposes: search for general web search, fetchWebContent for arbitrary URLs, and site-specific fetchers for CSDN/Juejin/GitHub READMEs. There is some potential confusion between fetchWebContent and the specialized fetch tools for the same URLs, but the descriptions make the intended use fairly clear.
Naming Consistency4/5The naming pattern is mostly consistent, with four fetch* tools, plus search, resolveLibraryId, and queryDocs. All names use lowercase camelCase and a verb-first style, though search is less descriptive than searchWeb and the three non-fetch verbs break the dominant fetch pattern.
Tool Count5/5Seven tools is well-scoped for a web search and content retrieval server. Each tool serves a legitimate purpose without the set feeling bloated or overly minimal.
Completeness5/5The server covers the core domain well: general web search, generic page fetching, specialized article/README extraction, and a dedicated official-docs lookup flow. No obvious dead ends or critical missing operations are apparent for the stated purpose.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 81 commits in the last 12 weeks
- Last stable release on
- 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.
This server has been verified by its author.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the public URL scope and Markdown/web page support. It does not disclose extraction behavior, the effect of readability/raw, or whether output is transformed. This is adequate given annotations, but the additional behavioral context is thin.
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, front-loaded sentence with no filler. Every word contributes to the core purpose, and it is appropriately sized for a tool whose annotations cover safety. It is concise without losing necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a six-parameter tool with no output schema and several closely related sibling tools. The one-sentence description omits paging via startIndex, the purpose of readability/raw, the response format, and when to choose specialized fetchers. Annotations only cover safety, not operational completeness, so the definition leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (raw and startIndex have descriptions). The description only adds meaning to the url parameter by specifying 'public HTTP(S)'. It does not compensate for the undocumented maxChars, readability, includeLinks, or the overall behavior of raw. The tool description fails to help an agent understand five of the six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch'), resource ('content from a public HTTP(S) URL'), and supported content types (Markdown files and normal web pages). It is readily distinguishable from specialized siblings such as fetchGithubReadme or fetchCsdnArticle, but it does not explicitly name them, so it falls short of a 5.
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?
The description gives no guidance on when to use this tool versus the specialized fetch tools (fetchCsdnArticle, fetchGithubReadme, fetchJuejinArticle) or alternatives like search/queryDocs. There are no conditions, exclusions, or selection criteria. The mention of supported formats only implies scope, not when to prefer this tool.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only profile is established. The description adds the notion of 'full article content' but discloses nothing about potential anti-scraping blocks, page variation, or response behavior, which would have raised the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is slightly thin on context, which keeps it from a 5, but it is appropriately sized for a one-parameter tool.
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?
For a simple one-parameter read-only tool, the description is minimally adequate: annotations cover the safety profile and the schema covers the parameter. However, with no output schema, it does not describe the return format, failure modes, or content limitations, which an agent might need to handle results correctly.
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?
There is a single url parameter with 0% schema description coverage, so the description carries some weight. The phrase 'csdn post URL' clarifies the expected parameter meaning beyond the schema's generic 'uri' format, but it adds little else about format, validation, or accepted URL variants.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Fetch) and resource (full article content from a csdn post URL), making the tool's function clear. However, it does not explicitly differentiate itself from siblings like fetchJuejinArticle or fetchWebContent beyond the platform name, so it stops short of a 5.
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?
There is no explicit guidance on when to use this tool vs. alternatives such as fetchWebContent or fetchJuejinArticle. The CSDN-specific wording implies its context, but no exclusions, prerequisites, or routing logic are provided.
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, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no extra behavioral context beyond the obvious fetching action, but doesn't contradict annotations.
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 sentence, extremely concise, and front-loaded with the action and resource. It earns its place without being verbose.
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?
Given the tool is simple (one parameter, no output schema), the description covers the core purpose. However, it lacks guidance on what the returned content format is (e.g., raw markdown) or how it handles non-existent READMEs, which could be important for an agent.
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 0%, so the description must compensate. It mentions 'GitHub repository URL', which aligns with the single 'url' parameter, but doesn't add details like URL format or accepted patterns. With only one parameter, the description provides minimal but sufficient guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches README content from a GitHub repository URL, using the specific verb 'Fetch' and a clear resource ('README content from a GitHub repository URL'). It is distinct from siblings like fetchWebContent, though it doesn't explicitly differentiate itself.
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?
The description implies the tool is for GitHub repository URLs but doesn't specify when to use it over fetchWebContent or search. It gives some context (GitHub README) but lacks explicit exclusions or alternative routing.
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, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds 'full article content' as a slight behavioral qualifier, suggesting it returns the whole article rather than a snippet, but it does not disclose output format, failure behavior, or handling of invalid URLs.
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 sentence with no filler. Every word contributes: verb, resource, and source format. It is front-loaded and immediately tells the agent what the tool does.
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?
For a simple one-parameter tool with safety annotations, the description covers what it does and the target URL type. However, there is no output schema, and the description does not clarify whether the returned content is markdown, HTML, or plain text, leaving some ambiguity about the return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic uri string with 0% description coverage. The description meaningfully narrows this by specifying the URL must be a Juejin post URL, which is valuable context the schema lacks. For a single parameter, this is sufficient compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Fetch' + resource 'full article content' + target 'Juejin post URL'. It is unambiguous about the operation and platform, and the platform reference implicitly separates it from siblings like fetchCsdnArticle and fetchGithubReadme. It does not explicitly differentiate itself from the broader fetchWebContent tool but still makes the scope clear.
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?
The description establishes a clear context: use this when targeting a Juejin post URL. It does not explicitly state when not to use it nor name alternatives, leaving the agent to infer the distinction from sibling tool names and the platform mention.
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?
Annotations already cover read-only/idempotent behavior. The description adds meaningful behavioral context: results are up-to-date, version-pinnable, and obtained without a proxy. It does not describe return format or pagination, but those are minor for a read-only docs lookup 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and each sentence carries useful information: what it does and how to use it. No filler or redundancy.
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 3-parameter read-only tool with rich annotations and full schema coverage, the description covers purpose, usage workflow, and result expectations. It lacks an explicit return-value shape and edge-case behavior, but the overall picture is adequate.
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%, and the schema already provides examples for libraryId, including version suffixes. The tool description repeats those examples rather than adding new semantic detail for query or limit, so it does not go beyond the schema baseline.
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 ('Get') and resource ('official docs and code snippets for a Context7 library ID'), with concrete examples. It also distinguishes this tool from web-fetch and search siblings by framing it as 'official documentation lookups' and naming resolveLibraryId as its companion.
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 explicitly advises using this tool with resolveLibraryId for official documentation lookups and gives a clear benefit ('direct, reliable, no proxy needed'). It does not explicitly state when to prefer alternatives like search or fetchWebContent, so exclusions are missing, but the context is clear.
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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds operational context beyond annotations: proxy-independent behavior and reliability relative to web search. These behavioral traits help the agent decide under network constraints.
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?
Two tight sentences: the first states purpose with an example, the second gives usage priority and comparison. There is no filler, and the key directives ('PREFERRED', 'FIRST') are front-loaded.
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 simple lookup tool, the description covers when to use it, what it returns (a Context7 library ID with an example format), and how to chain it with queryDocs. With no output schema, the gap around empty results or error behavior is minor but not fully addressed.
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 input schema covers 100% of parameters with clear descriptions, so the baseline applies. The description adds a useful output example and implies the query-reranking behavior, but does not materially enhance parameter understanding beyond the schema.
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 and resource — 'resolve a library/package name to a Context7 library ID' — and provides a concrete example ('/vercel/next.js'). It clearly differentiates the tool from queryDocs and web search by positioning it as the resolution step before queryDocs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use the tool ('when the task needs official library/framework documentation'), in what order ('then queryDocs'), and why it beats alternatives ('more reliable than web search and works without a proxy'). This is direct, actionable 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?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: no API key required, searchMode semantics for server default versus forced modes, and a reliability caveat about proxy usage. This meaningfully enriches what the agent knows before calling.
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 three tightly packed sentences with no filler. The primary action is front-loaded, followed by mode semantics and then routing guidance. Every sentence earns its place.
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 web search tool with five parameters and no output schema, the description covers the main decision points: when to search, when to use alternatives, how to scope queries, and how searchMode behaves. Minor gaps remain around result format and error behavior, but the description is largely complete for correct invocation.
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 only 20%, so the description must compensate. It does add meaning for searchMode and query, including the site: operator pattern, but it does not clarify limit defaults, engines normalization/aliases, or minResults behavior beyond what the schema already states. Partial compensation only.
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 and resource: 'Search the web across multiple engines.' It immediately clarifies a key differentiator, 'no API key required,' and distinguishes itself from sibling documentation tools by directing official docs to resolveLibraryId + queryDocs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when NOT to use this tool: for official library/framework documentation, prefer resolveLibraryId + queryDocs because they are more reliable and work without a proxy. It also gives concrete query guidance via the site: operator, making usage conditions actionable.
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/wtznicy/my-websearch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server