Web Research Assistant

by elad12390

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct research task (e.g., web_search vs. api_docs vs. compare_tech), with clear descriptions that prevent overlap. Even similar tools like crawl_url and stealth_scrape are differentiated by use cases.
Naming Consistency4/5
Names mostly follow a verb_noun or noun_noun pattern with underscores, but there are minor inconsistencies (e.g., 'github_repo' vs. 'check_service_status'). Overall readable and predictable.
Tool Count5/5
14 tools are well-scoped for a web research assistant, covering searching, fetching, extracting, and analyzing without being overwhelming or too few.
Completeness4/5
Covers core research workflows (search, fetch, extract, compare, check status, find packages/images/errors). Minor gaps like direct social media scraping are acceptable for the stated purpose.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on December 3, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, calling requirements, rate limits, or response structure. The agent receives no additional context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of completeness. It is front-loaded with the key action, but the brevity leads to omissions in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters (2 required), an enum, and an output schema, the description provides no context on how to use parameters, what the output contains, or how the tool behaves. This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no information about the parameters. The schema provides types and defaults but the description does not explain the meaning of 'reasoning', 'registry', or 'max_releases', leaving the agent to infer usage.
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 verb 'Get' and resource 'changelog and release notes for a package', indicating the tool's purpose. However, it does not explicitly distinguish it from sibling tools like 'package_info' or 'package_search', though the specialization is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, if a user wants general package information, they might mistakenly use this tool instead of 'package_info'. The description should mention that this tool is specifically for changelogs or release notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It fails to mention whether the tool is read-only, requires authentication, has rate limits, or how it obtains status information. The output schema exists but the description adds no behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, achieving conciseness. However, it could be restructured to include more detail about parameters or behavior without becoming verbose. It is appropriately front-loaded but lacks depth.
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 the presence of an output schema and the simplicity of the tool (2 required string params), the description is too brief. It does not provide enough context for an agent to understand how to fill parameters or what to expect, especially since parameter semantics are absent. The description should elaborate on what constitutes a 'service' and how to interpret the reasoning input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions are present. The tool description does not explain what 'service' (e.g., service name, URL) or 'reasoning' (e.g., purpose of check) represent, leaving the agent to guess the semantic meaning of these required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking if an API service or platform is experiencing issues. It uses a specific verb ('check') and resource ('API service or platform'), and it distinguishes itself from sibling tools like web_search, api_docs, etc., which focus on different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or when not to use it. The description simply states what it does without contextualizing usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the basic fetch-and-convert action. It does not mention authentication requirements, error behavior, rate limits, or any side effects. The presence of an output schema is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose.
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 the tool has 4 parameters, an output schema, and no annotations, the description is insufficient. It explains neither the parameters nor the output format, and lacks any usage context or error handling information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not describe any of the four parameters (url, reasoning, max_chars, country), leaving their purpose unclear. The description adds no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a URL and returns page text as markdown for quoting or analysis. This is a specific verb-resource combination and distinguishes it from siblings like web_search (which likely returns search results) and stealth_scrape (which might have a different method).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The mention of 'for quoting or analysis' implies use cases, but there is no comparison to siblings like stealth_scrape or web_search, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the source (SearXNG) and freshness, but omits behavioral details such as rate limits, pagination, or return format. The output schema exists, but the description does not explain what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is arguably too concise; it could include more detail without becoming verbose. Still, for a short description, it earns a high score for efficiency.
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 the tool has 4 parameters (2 required), no annotations, and an output schema, the description is insufficient. It lacks context about when to use this over other search tools, parameter meanings, and what the output contains. The existence of an output schema does not excuse the lack of behavioral context in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanations for any of the 4 parameters. The purpose of 'reasoning', valid categories, and max_results limit are left undocumented. The description adds no value beyond the schema's parameter names and types.
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 action (gather fresh web search results) and resource (web, via SearXNG). The name 'web_search' matches the description. However, it does not differentiate from sibling search tools like 'search_images' or 'package_search', so it lacks explicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this first' gives a weak usage hint about sequencing, but no explicit when-not-to-use or alternative tools are mentioned. Given the siblings, more guidance would help an agent decide between this and other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states 'search for packages' without mentioning side effects, authentication, rate limits, or result behavior. No details on pagination or filtering beyond the 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?
Concise, with front-loaded purpose and examples. Every sentence adds value. Could be slightly more efficient, but no fluff.
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 4 parameters, 2 required, an enum, and an output schema, the description is incomplete. It lacks parameter details, output format, and behavioral context. The tool is complex enough to require more guidance than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not explain any parameter meaning (query, reasoning, registry, max_results). Examples hint at usage but do not clarify semantics, types, or constraints. For a 4-parameter tool with 0% coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'search' and resource 'packages', with specific context of discovering libraries by functionality. Examples reinforce purpose and differentiate from sibling tool 'package_info' which requires known package name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'find packages that solve a specific problem' and 'when you know what you need but not the package name'. Lacks explicit when-not-to-use or alternatives, but the examples and phrasing offer clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output fields (version, downloads, etc.) but does not disclose additional behavioral traits such as read-only nature, error handling, or rate limits. Since no annotations exist, the description carries the full burden and this is a moderate gap.
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 concise with four sentences and three helpful examples, front-loading the purpose and key details without unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, output fields, and registry options adequately for a lookup tool. Missing details on error conditions or package not found, but overall complete given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage; the description partly compensates through examples showing parameter usage. However, the 'reasoning' parameter is required but its purpose remains ambiguous despite 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 it looks up package information from specific registries and lists returned fields. It distinguishes from sibling 'package_search' by focusing on detailed info for a specific package rather than searching.
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?
Provides a usage scenario ('evaluate libraries before adding them to your project') but does not explicitly mention when not to use or suggest alternatives like 'package_search' for searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only lists return values but fails to disclose behavioral traits such as rate limits, authentication requirements, error handling, or side effects. The fetch operation is implied read-only but not stated.
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 concise with three lines, front-loads the purpose, and includes useful examples. Every sentence adds value with no 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?
The description adequately covers the tool's purpose and returns, but missing parameter details (especially 'include_commits') and behavioral context limit completeness. An output schema exists, which reduces need for return value explanation, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not add explicit parameter semantics. Examples hint at repo format (owner/name or URL) but do not formally explain. The 'include_commits' parameter is not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Fetch GitHub repository information and health metrics') and lists the specific data returned (stars, forks, issues, etc.). It clearly distinguishes the tool's purpose among siblings like package_info or web_search.
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 a clear use case ('Use this to evaluate open source projects before using them'), which implies context. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses filtering capabilities and default values, but does not clarify if the operation is read-only or if there are any side effects. Since no annotations are provided, the description carries the full burden. It lacks details on response structure (though output schema exists) and potential limitations.
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 well-structured with a clear purpose, bullet points for options, and usage examples. It is somewhat verbose but informative. The most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers content_type and time_range but omits explanation for the 'reasoning' parameter, which is required and may be unclear. Additionally, it does not describe the return value or how the tool handles edge cases, despite having an output schema. Given the presence of 5 parameters and moderate complexity, it is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the semantics of content_type and time_range parameters with enumerations and defaults, which adds value beyond the schema. However, it does not explain the 'reasoning' parameter (required) or 'max_results', leaving ambiguity. With 0% schema description coverage, more compensation is expected, but partial coverage is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for code examples, tutorials, and technical articles.' The verb 'search' and resource 'examples' are specific. It distinguishes itself from sibling tools like web_search and search_images by focusing on code and learning resources.
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 the tool: 'Perfect for learning new APIs, finding usage patterns, or discovering how others solve specific technical problems.' It also explains the two filtering dimensions. However, it does not explicitly mention when not to use it or direct users to alternative 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, the description must disclose behavioral traits. It mentions images are royalty-free and safe to use, but lacks details on limitations, rate limits, or authentication. Adequate but not comprehensive.
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 concise, uses bullet points for clarity, and front-loads the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description sufficiently covers source, usage, and image types. It is fairly complete for a search tool, though it omits details on output structure (mitigated by output schema).
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 should compensate by explaining all parameters. It explains image_type and orientation via examples but does not clarify the 'reasoning' parameter, leaving a key required parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for high-quality stock images using Pixabay, specifying the resource (images) and source. It differentiates from sibling tools like web_search by focusing on image search.
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 examples and lists image types, helping users decide when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, 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?
It discloses that the tool automatically detects language/framework, extracts key info, and ranks results by votes and relevance. With no annotations provided, these details are valuable, though it doesn't clarify interaction with optional language/framework parameters or rate limits.
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 moderately concise with bullet points and examples, but could be slightly more streamlined. It front-loads the key action and uses examples effectively.
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 (5 params, 2 required, output schema), the description covers the main purpose and behavior but lacks explanation for the reasoning parameter and how optional parameters override auto-detection. Output schema existence reduces need for return value details, but there are still gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Examples illustrate use of language, framework, and reasoning, but the description does not explicitly define the purpose of the reasoning parameter, and language/framework are mentioned as auto-detected without clarifying that they are optional overrides. Schema coverage is 0%, so more explicit parameter descriptions would help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds solutions for error messages and stack traces from Stack Overflow and GitHub, with automatic detection and ranking. This distinguishes it from siblings like web_search or package_search which are more general.
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 'Perfect for' section lists specific use cases (debugging production errors, understanding cryptic messages, etc.), implicitly guiding when to use. However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the dynamic discovery process (common URL patterns, search fallback, crawling) and notes no hardcoded URLs. With no annotations, this adds valuable behavioral context, though details like rate limits or auth are absent.
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 well-structured with front-loaded purpose, followed by comparison, strategy, and concise examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the key aspects: purpose, strategy, and examples. The presence of an output schema reduces the need to detail return values, making this sufficiently complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description and examples illustrate the role of 'api_name' and 'topic' and mention default for 'max_results'. But it does not fully explain the 'reasoning' parameter, and schema coverage is 0%, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching and fetching official API documentation, distinguishing it from generic web searches or scraping. It explicitly contrasts with OpenAPI specs, emphasizing its value for human-written 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 a documented discovery strategy and examples, guiding when to use the tool (e.g., for any API's official docs). However, it lacks explicit when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It mentions automated information gathering and structured output, but lacks details on read-only behavior, rate limits, or reliability of auto-detection. It does not contradict any annotations, so no contradiction.
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 concise, well-structured with a purpose statement, category list, and clear examples. Every sentence adds value without redundancy, making it easy for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 5 parameters, the description covers the essential aspects: purpose, categories, and usage examples. It omits explanation of 'max_results_per_tech', but since an output schema exists, return values are not required. Overall, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains the 'category' parameter with an enum list and provides examples showing usage of 'technologies', 'reasoning', 'aspects'. However, 'max_results_per_tech' is not described, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares multiple technologies with specific verb 'Compare' and resource 'technologies, frameworks, or libraries'. It lists categories and examples, differentiating it from sibling tools that perform other tasks like crawling or searching.
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 categories and examples demonstrating when to use the tool. It does not explicitly state when not to use it or alternatives, but the sibling tools are functionally distinct, making misuse unlikely.
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?
Without annotations, description explains extract types and behavior via examples and bullet points. It does not cover authorization, rate limits, or error handling, but the behavioral core is well explained.
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?
Description is well-structured with clear sections, bullet points for extract types, and multiple examples. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, description appropriately focuses on input behavior. Covers main use cases but omits potential limitations like page size or dynamic content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description compensates by explaining extract_type enums, selectors usage with examples, and implicitly covers url and reasoning. However, max_items is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Extract structured data from web pages' and specifies five extract types (table, list, fields, json-ld, auto), making the verb and resource specific. It differentiates from siblings like crawl_url and web_search by focusing on structured extraction from HTML.
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?
Description notes efficiency advantage over parsing full page text and provides examples, implying use for structured extraction. However, lacks explicit when-not-to-use instructions or comparison to alternatives.
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?
No annotations provided, but the description explains it uses StealthyFetcher with Patchright, is slower than crawl_url, requires browser binaries setup, and can handle Cloudflare and JS rendering. However, it does not disclose error handling if binaries are missing or any rate limits.
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?
Well-structured with a clear opening, setup note, usage list, and examples. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose, context, and usage scenarios, but omits details on some parameters (reasoning, max_chars, headless, country) and potential error states. Output schema exists, so return values are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description explains wait_selector and solve_cloudflare implicitly via examples and text. However, it does not document reasoning, max_chars, headless, or country, leaving significant gaps beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scrapes a URL using a stealth browser to bypass anti-bot protections, and distinguishes from sibling tool crawl_url by noting it is slower but works on protected sites.
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?
Provides explicit when-to-use conditions (e.g., crawl_url returns Cloudflare challenge, site blocks automated requests, JS rendering needed) and includes two concrete examples, aiding the agent in correct selection.
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:

[![web-research-assistant MCP server](https://glama.ai/mcp/servers/elad12390/web-research-assistant/badges/card.svg)](https://glama.ai/mcp/servers/elad12390/web-research-assistant)

Score Badge

Copy to your README.md:

[![web-research-assistant MCP server](https://glama.ai/mcp/servers/elad12390/web-research-assistant/badges/score.svg)](https://glama.ai/mcp/servers/elad12390/web-research-assistant)

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/elad12390/web-research-assistant'

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