Provides search (web and news) and webpage crawling capabilities via DuckDuckGo, with readable text extraction.
Drives an anti-detect Firefox (Camoufox) browser for automating interactions with bot-protected websites, including navigation, clicking, form filling, and screenshotting.
Provides access to GitHub repositories: fetching files, analyzing repo structure, searching code, and managing issues (requires token for some actions).
Enables read-only SPARQL queries against Wikidata for structured entity data.
Offers search and full-article retrieval from Wikipedia.
Allows fetching video transcripts (various formats), metadata, and searching within transcripts via YouTube's public endpoints.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@web-explorer search web for latest news on AI"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
External web tools for any MCP client. Search the web, crawl pages, drive an anti-detect Firefox browser past bot walls, and pull structured data from Wikipedia, Wikidata, GitHub, and YouTube.
Two things worth stating up front:
Free APIs only. No paid services, no metered quotas. It uses DuckDuckGo,
Wikipedia, Wikidata, the public GitHub API, and YouTube's own caption
endpoints. The only credential any tool reads is a GitHub token, which is free
and which only github uses (for code search and issue actions; plain file
and repo reads work without one). See Credentials below.
Runs off your own IP. Every request goes out from the machine running the server, straight to the source. No proxy, no relay, no third-party scraping service in the middle reselling your traffic.
Tool | What it does |
| DuckDuckGo search and direct page crawl with readable-text extraction. News search too. |
| Anti-detect Firefox (Camoufox) for bot-protected sites (Cloudflare, Datadome, verification walls). Persistent profile keeps cookies and solved challenges across restarts. Optional install, see below. |
| Wikipedia search and full-article fetch. |
| Wikidata SPARQL queries for structured entity data (people, places, orgs, relationships). |
| Fetch files, analyze repo structure, search code, and read or manage issues via the public GitHub API. Code search and issue actions need a free |
| Transcripts and metadata for any video. youtube-transcript-api first, yt-dlp fallback. Any URL shape or bare video id. |
Every tool takes an action argument, except wikidata_query which takes a
SPARQL query. Call list_tools from your client for the exact schema of every
action and parameter. What each action does:
websearch - web results as title, url, and snippet. news=true switches to the
DuckDuckGo news endpoint (adds date and source per result); timelimit filters
to d, w, or m.
crawl - fetch one URL and extract readable article text (trafilatura, with a
BeautifulSoup fallback), including PDFs. summary=true (default) returns a
short version, summary=false the fuller text.
Results are cached for 20 minutes. If a page is behind bot protection, crawl
points you at fx.
fx (optional install)A real Camoufox (hardened Firefox) session for sites that block plain fetches.
read - navigate, wait out JS challenges, extract clean text, auto-close. The
common one-shot case.
Step-by-step automation: navigate, click, fill, type, press,
scroll, wait, extract (raw HTML), text (body text), evaluate (run
JavaScript), screenshot (element or full_page), cookies / add_cookies,
and close.
status - report the current session.
Options include visible (show the window), stealth (humanized cursor), and
load_images. The profile persists to disk; see the note under Safety.
wikisearch - article titles matching a query.
page - full article text for a title.
Cached for one hour.
wikidata_queryRun a read-only SPARQL query against Wikidata for structured entity data. Limits: 5000 character query, 15 second timeout, 1000 results. Update operations (INSERT, DELETE, DROP, and so on) are rejected.
githubfetch - raw file content. analyze - repo metadata, languages, file count.
search - code search (requires a token).
Issues: get_issue, list_issues, create_issue, comment_issue,
update_issue. The write actions require a token. See Credentials.
Cached for 10 minutes.
youtubetranscript - captions only. metadata - title, channel, duration,
description, chapters. info - both at once (the common case).
list_languages - available caption tracks. search - find a phrase within a
transcript, returning timestamped matches with t= deep links.
Transcript format can be text (default), timestamped, srt, vtt, or
json. Long transcripts auto-paginate with segment_offset and max_segments.
harvest=Trueweb, fx, github, and youtube accept harvest=True. Instead of returning
a large page or transcript into your context window, the content is written to
harvested/<harvest_dest>/ as clean markdown and only the file path plus a short
summary come back. Point HARVEST_ROOT at a different directory if you want.
Related MCP server: evo-scry
Python 3.10 or newer.
Install as a package to get a web-explorer command on your PATH:
pipx install git+https://github.com/cutlerbenjamin1-cmd/web-explorerFrom a local checkout: pip install . Or just install the dependencies and run server.py directly:
pip install -r requirements.txtThat covers the server and the five free-API tools (web, wiki,
wikidata_query, github, youtube).
fx browserThe anti-detect browser is a heavier dependency, so it is opt-in. The server and
the other tools work fine without it; fx just returns a clear "not installed"
message until you add it.
pip install -r requirements-fx.txt # or: pip install "web-explorer[fx]"
python -m camoufox fetchpython -m camoufox fetch is a one-time download of a patched Firefox build
(about 150 MB). camoufox also pulls in playwright and browserforge.
Speaks MCP over stdio. If you installed the package, point your client at the web-explorer command:
{
"mcpServers": {
"web-explorer": {
"command": "web-explorer"
}
}
}Otherwise point python at server.py with an absolute path:
{
"mcpServers": {
"web-explorer": {
"command": "python",
"args": ["/absolute/path/to/web-explorer/server.py"]
}
}
}To serve this over MCP streamable HTTP instead of stdio, use
mcp-http-bridge: run it
from this directory and point your client at the bridge. Keep the bridge's tool
filter tight if you expose it beyond localhost, since fx can drive a real
browser.
Untrusted-content banner. Everything these tools return is data from outside your machine. Each response is tagged as external and untrusted so an agent does not treat page content as instructions.
SSRF protection. web(crawl) refuses private and loopback address ranges,
so a crawled URL cannot be pointed back at your internal network.
Polite rate limiting. Per-tool cooldowns space out requests so you do not hammer a host from your own IP and trip a 429.
The fx profile is real browser state. fx keeps a persistent Firefox
profile at data/fx_profile/. Anything you do in it sticks: if you sign into a
site through fx, that session and its cookies are written to disk there in the
clear, exactly like a normal browser profile. That is what lets logins and
solved Cloudflare challenges survive a restart. The folder is gitignored so it
will not be committed, but treat it like a password store: do not share or copy
it, and delete data/fx_profile/ to wipe every saved session.
Only the github tool reads a credential, and it is an ordinary free GitHub
personal access token.
Without a token: github file fetch and repo analyze work, subject to
GitHub's anonymous rate limit (about 60 requests per hour).
With a token: that limit rises to 5000 per hour, and github code search plus
the issue actions (create, comment, update) become available. They return a
clear "token required" error otherwise.
Set it in the environment before launching the server:
set GITHUB_TOKEN=ghp_your_token_here # Windows
export GITHUB_TOKEN=ghp_your_token_here # macOS / LinuxNo other tool needs an account or key. DuckDuckGo, Wikipedia, Wikidata, and YouTube are all used unauthenticated.
Every variable below is optional.
Variable | Effect |
| GitHub auth. See Credentials above. |
| Directory for |
| Browser name (for example |
| Browser profile path for the cookies above. |
| Local source IP to bind outbound YouTube requests to. |
| Set to |
| Hard cap on a single tool response. Default: 15000. |
| Max GitHub file size fetched. Default: about 2MB. |
| Max HTML or text size for |
| Max PDF size for |
MIT. See LICENSE.
Anti-detect Firefox browser. Use when web(crawl) fails due to bot protection (Cloudflare, Datadome, Reddit verification). Persistent profile at data/fx_profile/: cookies, localStorage, and solved Cloudflare challenges survive MCP reboots. Fast defaults: images blocked, humanize off, domcontentloaded wait. Prefer 'read' for one-shot extraction — auto-waits for JS challenges (networkidle), runs trafilatura, auto-closes. Supports harvest=True to save content to disk instead of loading into context. Use 'navigate' + explicit actions for multi-step workflows (logged-in flows, form fills, clicks); call 'close' when done. Actions: navigate, read, click, fill, type, screenshot, extract, text, wait, press, scroll, evaluate, cookies, add_cookies, close, status.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X scroll amount | |
| y | No | Y scroll amount | |
| key | No | Key for press action (Enter, Tab, etc.) | |
| url | No | URL for navigate/read action | |
| text | No | Text for fill/type actions | |
| state | No | Wait state for wait action | |
| action | Yes | Browser action to perform | |
| script | No | JavaScript for evaluate action | |
| cookies | No | Cookies for add_cookies action | |
| harvest | No | For read action: save raw HTML to harvested/<harvest_dest>/ (converted to markdown by harvester). Saves context tokens. | |
| stealth | No | Enable humanized cursor movement (up to 1.5s/action). Only affects new sessions. Default: false. | |
| summary | No | For read action: trafilatura summary mode (fast, ~5KB cap). False = full extraction (~15KB). Default: true. | |
| timeout | No | Action timeout in seconds (default: 300) | |
| visible | No | Show browser window. Only affects new sessions. Default: false. | |
| selector | No | CSS selector for element actions | |
| full_page | No | Full page screenshot (default: false) | |
| wait_until | No | Navigation wait condition. Default: domcontentloaded. read action upgrades to networkidle unless explicitly overridden. | |
| close_after | No | For read action: auto-close session after extraction. Default: true. | |
| load_images | No | Allow images to load. Needed for screenshots with visuals. Only affects new sessions. Default: false. | |
| harvest_dest | No | For read action: subfolder under harvested/ (e.g., 'fx/'). Required when harvest=true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses persistence, default settings (images blocked, humanize off), waiting behavior (auto-waits for JS challenges), and side effects (harvest saves to disk). Without annotations, it fully carries the transparency burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately lengthy but efficient, front-loading the purpose and then detailing actions and parameters. Every sentence adds value, though it could be slightly tighter in grouping related information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 20 parameters and no output schema, the description covers major actions, defaults, and use cases well. It lacks explicit return value descriptions for some actions (e.g., screenshot, status), but overall provides sufficient completeness for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 20 parameters are described in the schema (100% coverage). The description adds meaningful context, such as explaining the roles of 'read' and 'navigate', and clarifying defaults for wait_until and stealth. This enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies as 'Anti-detect Firefox browser' with a specific use case (when web crawl fails due to bot protection). Distinguishes itself from sibling tools like 'web' by offering browser-level automation with anti-detection features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: 'Use when web(crawl) fails due to bot protection'. Differentiates between 'read' for one-shot extraction and 'navigate' for multi-step workflows, and advises when to call 'close'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub file and repo access via API. Returns {success, content/stats/results}. Use for: fetching source files, analyzing repo structure, searching code across GitHub. Actions: 'fetch' (raw file content), 'analyze' (repo stats/structure), 'search' (code search), 'create_issue' (open new issue), 'comment_issue' (add comment), 'get_issue' (read issue + comments), 'list_issues' (list repo issues), 'update_issue' (edit state/title/body/labels). Requires GITHUB_TOKEN env var for write ops and higher rate limits. 2MB response cap, 10min cache. For large files, use harvest=True to save to disk instead of loading into context.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Branch, tag, or commit SHA. Default: default branch. | |
| body | No | Issue/comment body (markdown). Used by create_issue, comment_issue, update_issue. | |
| path | No | File path within repo (e.g., 'src/main.py'). Required for fetch. | |
| repo | No | Repository name (e.g., 'claude-code') | |
| owner | No | GitHub username or org (e.g., 'anthropics') | |
| query | No | Code search query. Required for search action. | |
| state | No | Issue state: 'open' or 'closed'. Used by list_issues (filter) and update_issue. | |
| title | No | Issue title. Required for create_issue. | |
| action | Yes | 'fetch' for file content, 'analyze' for repo stats, 'search' for code search, 'create_issue'/'comment_issue'/'get_issue'/'list_issues'/'update_issue' for issue management | |
| labels | No | Labels array. Used by create_issue, update_issue, list_issues. | |
| harvest | No | Save to disk, return metadata only. Saves context tokens. | |
| harvest_dest | No | Subfolder under harvested/ (e.g., 'github/'). | |
| issue_number | No | Issue number. Required for comment_issue, get_issue, update_issue. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals the return format ('{success, content/stats/results}'), response cap (2MB), caching (10min), and the harvest option for saving to disk. It also clearly states authentication requirements for write operations, providing critical behavioral transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence stating the overall purpose and return format, followed by a list of actions and important notes on auth, limits, and caching. It is efficient and front-loaded, though slightly lengthy due to the enumeration of actions, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, 8 actions) and absence of an output schema, the description covers the essential aspects: all actions, use cases, auth requirements, response limits, caching, and the harvest feature. Minor details like pagination for list_issues are omitted, but overall it provides sufficient context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already described in the schema. The description does not add meaningful semantic detail beyond the schema; it merely lists actions and their purposes, which are already sufficiently documented. The baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'GitHub file and repo access via API', lists specific actions (fetch, analyze, search, issue management), and distinguishes itself from sibling tools like fx, web, and wiki by focusing exclusively on GitHub operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states use cases ('fetching source files, analyzing repo structure, searching code across GitHub') and lists all supported actions. It mentions that GITHUB_TOKEN is required for write operations and higher rate limits. However, it does not explicitly state when not to use the tool or provide direct comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web search and page fetching. Returns {success, results/content, url}. Use ONLY after exhausting local sources: retrieve() -> kg(neighbors) -> web. Actions: 'search' (DuckDuckGo, returns title/url/snippet), 'crawl' (fetch page content). Set news=true for DDG news endpoint (adds date/source fields). High context cost - prefer harvest=True to save content to disk instead of loading into context. Results cached 20min. For bot-protected sites, use fx tool instead.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to crawl. Required for action='crawl'. | |
| news | No | Use DDG news endpoint instead of web. Returns date/source per result. search action only. | |
| query | No | Search query. Required for action='search'. | |
| action | Yes | 'search' for DuckDuckGo query, 'crawl' to fetch a specific URL | |
| harvest | No | Save content to disk, return metadata only. Saves context tokens. | |
| summary | No | Return summary only (default: true). Set false for full page content. | |
| timelimit | No | Time filter for news: 'd' (day), 'w' (week), 'm' (month). | |
| harvest_dest | No | Subfolder under harvested/ (e.g., 'docs/'). Required if harvest=true. | |
| timeout_seconds | No | Request timeout. Default: 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses: caching (20 min), high context cost, harvest behavior, default summary, news endpoint fields, timeout default. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact paragraph with front-loaded purpose and clear logical flow: purpose, usage order, action details, news, cost mitigation, caching, alternatives. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description covers all essential aspects: what it does, how to use, parameter details, behavior, caching, context management, and alternative tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: groups actions, explains harvest as context-saving, news adds date/source, timelimit for news, harvest_dest subfolder, summary default true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Web search and page fetching' and specifies two actions (search via DuckDuckGo, crawl via URL fetch). Explicitly distinguishes from sibling tool fx for bot-protected sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage order: 'Use ONLY after exhausting local sources: retrieve() -> kg(neighbors) -> web.' Also advises using fx for bot-protected sites and suggests harvest=True to save context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wikipedia lookup. Check memory/KG for known facts first. Actions: search, page. Results cached 1hr.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| title | No | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses caching behavior ('Results cached 1hr.') and enumerates actions. No contradictions; clearly a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. Every sentence adds value: purpose, usage guideline, actions, caching. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes purpose, usage, actions, and caching. However, lacks explanation of parameter distinctions and return value (no output schema). Leaves gaps for an agent to understand fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists actions (search, page) which maps to action enum, but does not clarify when to use 'query' vs 'title' parameters. Partial help, but significant ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Wikipedia lookup' which is a specific verb+resource. Distinguishes from siblings like wikidata_query and web search. Mentions two actions (search, page), adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Instructs to check memory/KG first, indicating proper usage order. Does not explicitly name alternatives or when not to use, but provides context for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wikidata SPARQL queries. Use for structured entity data (people, places, organizations, factual relationships). 5000 char query limit, 15s timeout, 1000 max results. Consider storing results in KG for reuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SPARQL query string | |
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description is the only source for behavioral traits. It discloses limits (query length, timeout, max results) but does not state whether the tool is read-only, error handling, or response format. Partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, immediately followed by limits and reuse suggestion. No unnecessary words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided. The description fails to specify what the tool returns (e.g., JSON format, result structure), which is critical for a query tool. This missing detail reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'query' has description). The description adds context for timeout via '15s timeout' but does not explain the query parameter beyond 'SPARQL query string'. Marginal improvement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for Wikidata SPARQL queries and specifies use cases like people, places, organizations, factual relationships. It provides some differentiation from sibling tools (e.g., web, wiki, youtube) by focusing on structured data, but lacks explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes constraints (5000 char limit, 15s timeout, 1000 max results) and suggests storing results in KG for reuse, but does not explicitly state when to use this tool versus alternatives or provide negative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YouTube transcript and metadata tool. Returns captions + rich metadata for any YouTube video. Actions: 'transcript' (captions only), 'metadata' (title/channel/duration/description/chapters only), 'info' (transcript + metadata in parallel - the common case), 'list_languages' (enumerate available caption tracks), 'search' (find a phrase within a transcript, returns timestamped matches with t= deeplinks). Primary fetch: youtube-transcript-api (fast, clean). Fallback: yt-dlp with json3 subtitles + VTT roll-up dedup. Format options: text (default, lowest tokens), timestamped, srt, vtt, json. Use harvest=True to write clean markdown under harvested/youtube/ for RAG ingestion. Accepts any URL shape (watch, youtu.be, shorts, live, embed) or bare 11-char video_id. Cached 1hr. Auto-paginates long transcripts; use segment_offset to continue from where the last response ended. For long podcasts, prefer harvest=True then retrieve() instead of loading full text into context.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | YouTube URL (any shape). Either url or video_id is required. | |
| query | No | Search phrase. Required for action='search'. | |
| action | Yes | Operation to perform | |
| format | No | Transcript output format. Default: text (lowest tokens). | |
| harvest | No | Save a markdown file under harvested/<harvest_dest>/ for RAG ingestion. Saves context tokens when working with long videos. | |
| video_id | No | 11-char video ID (alternative to url). | |
| languages | No | Preferred language codes in priority order, e.g. ['en', 'en-US']. Default ['en']. | |
| force_ytdlp | No | Skip primary path, go straight to yt-dlp (useful when IP-blocked or when primary returns stale data). Default: false. | |
| harvest_dest | No | Subfolder under harvested/. Default: 'youtube/'. | |
| max_segments | No | Max segments to return. Default: auto-calculated to fit response budget. | |
| rich_metadata | No | Use yt-dlp for rich metadata (slower, full info) vs oEmbed (faster, title+channel+thumbnail only). Default: true. | |
| segment_offset | No | Start from this segment index (0-based). Use next_offset from a previous paginated response to continue. Default: 0. | |
| include_metadata | No | For info action, include metadata alongside transcript. Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: fallback mechanism (primary vs yt-dlp), caching duration (1hr), auto-pagination with segment_offset, format defaults, and harvest behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph covering many details. While all information is valuable, it could benefit from structuring (e.g., bullet points for actions) to improve scanability. It is not overly long but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, the description thoroughly explains all aspects: actions, fallback, caching, pagination, harvest, format options, and search behavior. It is complete for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3, but the description adds substantial meaning: explains action semantics in detail, clarifies default formats and languages, describes harvest and pagination mechanics, and provides usage context for each parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'YouTube transcript and metadata tool' and enumerates specific actions (transcript, metadata, info, list_languages, search) with explicit roles for each, effectively distinguishing the tool's purpose from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance for each action, including best practices like using harvest=True for long podcasts and combining it with retrieve() for context efficiency. However, lacks explicit when-not-to-use guidance relative to sibling tools, though the tool's YouTube-specific scope naturally differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0fxgithubwebwikiwikidata_queryyoutubeEach tool has a clearly distinct purpose: fx for bypassing bot protection, github for GitHub API access, web for general search and crawling, wiki for Wikipedia, wikidata_query for SPARQL queries, and youtube for YouTube transcripts and metadata. There is no ambiguity between tools.
All tool names are lowercase single words (fx, github, web, wiki, wikidata_query, youtube), which is a consistent style. However, they are nouns rather than the verb_noun pattern often seen in well-designed APIs, which slightly reduces predictability.
With 6 tools, the server covers a broad range of web exploration tasks without being overwhelming. Each tool addresses a distinct need, and the count feels appropriate for the scope.
The toolset covers major web sources (browser, search, GitHub, Wikipedia, Wikidata, YouTube). It lacks specific tools for other common resources like social media or news APIs, but for a general web explorer, the coverage is good and allows agents to handle most tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free remote MCP server for fetching public web pages through a rotating proxy pool.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cutlerbenjamin1-cmd/web-explorer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
