This server provides token-efficient web browsing, scraping, and crawling tools for AI agents. It fetches content as clean markdown or JSON via CSS selectors, and only launches a real browser when JavaScript rendering is required.
Tools:
web_scrape: Fetch a URL and return clean markdown or structured JSON using CSS selectors; optionally force browser rendering with forceBrowser.
web_check: Verify text or CSS selector presence/absence, or exact text match; returns pass/fail plus a short evidence snippet.
web_diff: Monitor a page or subtree for changes; returns changed: true/false plus a snippet, useful for cheap polling.
web_interact: Execute browser actions (click, fill, select, press, waitFor) and return an accessibility snapshot or optional screenshot; supports persistent sessions via sessionId.
web_session_close: Delete persisted session data (cookies, storage) for a session.
web_crawl: BFS-crawl from a seed URL with configurable depth/page limits, path include/exclude patterns, and same-host option; returns titles, links, and excerpts while caching full markdown.
web_crawl_get_page: Retrieve full cached markdown for a page visited during a crawl.
Other features:
Economical operation via tiered fetching, markdown output, schema extraction, and boolean verification.
SSRF protection blocks requests to private/reserved IP ranges.
Respects robots.txt and per-host rate limiting by default, overridable per call.
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., "@mcp-web-agent Scrape https://example.com and return the main article as markdown."
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.
A token-economical web browsing, scraping, and crawling suite delivered as a standard MCP server. Any MCP-capable agent (Claude, Cursor, Cline, etc.) can use it as ordinary tools with no bespoke integration.
Strategy | Saving |
Tiered fetching — static HTTP first, browser only when HTML is thin | Skips Chromium entirely for the majority of pages |
Markdown output, not raw HTML — noise/nav/ads stripped server-side | 300 KB page → ~8 KB of clean markdown |
Schema extraction — field → CSS selector returns only the values you asked for | No markdown conversion, no LLM reasoning |
Boolean verification — |
|
ARIA snapshot over screenshot — | Image tokens only when you explicitly ask |
Persistent browser pool — one Chromium process per server lifetime | ~1-2 s launch cost paid once, not per call |
robots.txt + rate limiting — per-host queues and rule caching | Polite crawling without throttling your agent |
Related MCP server: krwl3r
Tool | What it does | Browser needed? |
| Fetch a URL → clean markdown or schema-based JSON | Only if JS-rendered |
| Assert text/element present or absent → | Only if JS-rendered |
| Has this page changed since last check? → | Only if JS-rendered |
| Click / fill / select / press / waitFor sequence → ARIA snapshot | Always |
| Delete persisted cookies for a | No |
| BFS crawl from a seed URL → titles, links, excerpts, cached markdown | Only if JS-rendered |
| Retrieve full markdown cached by a prior | No |
npm install -g webmesh-mcp
# or use directly with npx (no global install needed):
npx webmesh-mcpwebmesh-mcp uses playwright-core
and does not bundle a browser. You have three options:
A) Install Playwright's managed Chromium (simplest):
npx playwright install chromiumB) Use your system Chrome / Edge — set executablePath in your MCP config (see below).
C) Connect to a running browser — Playwright supports CDP attach; pass --cdp-endpoint
flags in args if you want to hook into an already-running instance.
Static pages (most blogs, docs, GitHub, npm, etc.) never trigger the browser path at all.
Add to your MCP config (e.g. ~/.claude/claude_desktop_config.json, .cursor/mcp.json, etc.):
{
"mcpServers": {
"web-agent": {
"command": "npx",
"args": ["webmesh-mcp"]
}
}
}Or, if you prefer to run from source:
{
"mcpServers": {
"web-agent": {
"command": "npx",
"args": ["tsx", "/absolute/path/to/webmesh-mcp/src/index.ts"]
}
}
}This repository ships with a pre-configured Agent Skill in skills/web-agent/SKILL.md.
It provides AI coding assistants (Claude Code, Antigravity, Cursor, Windsurf, Gemini CLI, etc.) with a complete decision tree, trigger keywords, and parameter guidance for using webmesh-mcp tools token-efficiently.
Copy or symlink the skills/ folder into your AI assistant's skills directory:
Claude / Antigravity / Gemini CLI: Place in .agents/skills/web-agent/SKILL.md or ~/.gemini/config/skills/web-agent/SKILL.md
Cursor: Copy contents to .cursor/rules/web-agent.mdc
Windsurf: Copy contents to .windsurfrules
web_scrapeParameter | Type | Default | Description |
|
| — | Page to fetch |
|
|
| Output format |
|
| — |
|
|
| — | Scope extraction to a CSS subtree |
|
|
| Skip static tier, always use Chromium |
|
|
| Bypass |
web_checkParameter | Type | Default | Description |
|
| — | Page to check |
| enum | — |
|
|
| — | Text or CSS selector |
|
| — | Scope text search to subtree |
|
|
| |
|
|
|
web_diffParameter | Type | Default | Description |
|
| — | Page to monitor |
|
| — | Scope watch to subtree (e.g. |
|
|
| |
|
|
|
Returns changed: null on the first call (nothing to compare against),
true/false on subsequent calls.
web_interactParameter | Type | Default | Description |
|
| — | Starting URL |
|
| — | Sequence of browser actions |
|
| — | Scope returned ARIA snapshot |
|
|
| Return base64 PNG (costs image tokens) |
|
| — | Persist cookies/storage across calls |
|
|
|
Action shape:
{ type: "click" | "fill" | "select" | "press" | "waitFor", selector?: string, value?: string, timeoutMs?: number }web_session_closeParameter | Type | Description |
|
| Session to delete |
web_crawlParameter | Type | Default | Description |
|
| — | Seed URL |
|
|
| Max link depth (0 = seed only) |
|
|
| Hard cap on pages visited |
|
|
| Restrict to same hostname |
|
| — | Pathname globs URLs must match, e.g. |
|
| — | Pathname globs URLs must NOT match |
|
|
| Output verbosity |
|
|
|
Full markdown for every visited page is cached in SQLite for web_crawl_get_page.
web_crawl_get_pageParameter | Type | Description |
|
| Previously crawled URL |
Variable | Default | Description |
|
| Root directory for cache DB and session files |
Both the SQLite watch/crawl cache (cache/watch.sqlite) and session state files
(sessions/) live under MCP_WEB_AGENT_DATA_DIR. Override it to control where
runtime data is stored.
All outbound fetches — static HTTP, browser navigation, intermediate HTTP redirects, and crawl link-following — are strictly validated against an SSRF blocklist before network connections are established.
Protocol Restriction: Rejects all non-HTTP/HTTPS schemes.
Loopback Addresses: 127.x.x.x, IPv6 ::1, localhost, IPv6 unspecified :: / 0:0:0:0:0:0:0:0.
Private RFC-1918 & Unique Local IPv6: 10.x, 172.16–31.x, 192.168.x, fc00::/7, fd00::/7.
Link-Local & Cloud Metadata: 169.254.x.x (AWS/GCP/Azure IMDS), fe80::/10.
Special & Reserved Ranges: Multicast (224.x), Site-Local (fec0::/10), Documentation (2001:db8::/32), and IPv4-mapped IPv6 formats (::ffff:x.x.x.x).
HTTP Redirect Hardening: Static fetch enforces manual redirect validation loops up to 5 hops, checking ssrfGuard.assertPublicUrl() on every intermediate Location header before following.
Browser Route Interception: Chromium contexts attach route interceptors (page.route("**/*")) to block subresource requests or redirects targeting private IP space.
For a detailed technical architecture and end-to-end data flow specification, see Architecture.md.
index.ts (MCP server, stdio transport)
├── tools/scrape.ts — web_scrape
├── tools/check.ts — web_check
├── tools/diff.ts — web_diff
├── tools/interact.ts — web_interact
├── tools/crawl.ts — web_crawl
├── tools/crawlGetPage.ts — web_crawl_get_page
├── tieredFetch.ts — static HTTP → browser escalation (manual redirect validation)
├── browserPool.ts — singleton Chromium process + route interceptor (playwright-core)
├── ssrfGuard.ts — SSRF protection (blocks private/reserved IPv4 & IPv6 addresses)
├── extract.ts — HTML → clean markdown / plain text / schema JSON
├── hostGate.ts — robots.txt parser (regex escaped) + per-host rate-limiting queue
├── sessions.ts — disk-backed storageState persistence
├── cache.ts — SQLite: watch hashes + crawled page markdown
└── constants.ts — shared USER_AGENT, DATA_DIRgit clone https://github.com/creatorpiyush/webmesh-mcp
cd webmesh-mcp
npm install
npx playwright install chromium # optional, for browser-tier testing
npm run dev # run MCP server in dev mode (tsx, no compile step)
npm run demo -- https://example.com
npm test # run the full integration test suite
npm run typecheck # tsc --noEmit, no output files
npm run format # format code with prettier
npm run build # compile to dist/MIT — see LICENSE.
Verify something about a page (text present/absent, element present/absent, exact text match) without returning the whole page — just a pass/fail and a short evidence snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| value | Yes | text to search for, or CSS selector for the selector_* assertions | |
| selector | No | scope the text search to this subtree | |
| assertion | Yes | ||
| forceBrowser | No | ||
| ignoreRobots | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the transparency burden. It discloses the core return behavior (pass/fail and evidence snippet) and that the whole page is not returned, which is useful. But it does not mention potential side effects, network behavior, permissions, or the purpose of forceBrowser and ignoreRobots, leaving significant behavioral gaps.
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, information-dense sentence that leads with the verb 'Verify' and includes the key differentiator (not returning the whole page, pass/fail, evidence snippet). There is no wasted text.
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?
With no output schema and no annotations, the description must cover usage, behavior, and parameters. It explains the output format and assertion categories, but lacks guidance on when to use over siblings, nuances of selector and boolean flags, and failure behavior. It is minimally adequate for a 6-parameter tool but not complete.
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 only 33%, and the description partially compensates by grouping assertion types (text present/absent, element present/absent, exact text match), adding meaning to the assertion enum. However, it does not explain the selector scoping, forceBrowser, or ignoreRobots, so it only partially covers the parameter space.
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 what the tool does: verify page properties such as text presence, element presence, and exact text match. It distinguishes itself from siblings by explicitly noting it returns just a pass/fail and an evidence snippet rather than the whole page, aligning with scraping tools in the sibling set.
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 implies its use for verification checks rather than content retrieval with the phrase 'without returning the whole page.' However, it does not explicitly name alternative tools or state when not to use it, making the guidance clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a BFS crawl starting at startUrl up to maxDepth/maxPages. Returns page titles, link structures, and excerpts, while caching full markdown for web_crawl_get_page.
| Name | Required | Description | Default |
|---|---|---|---|
| maxDepth | No | max link depth to traverse (0 = startUrl only) | |
| maxPages | No | max total pages to visit | |
| startUrl | Yes | ||
| contentDepth | No | summary | |
| ignoreRobots | No | ||
| sameHostOnly | No | restrict crawl to pages on the same hostname | |
| excludePatterns | No | pathname glob patterns URLs must NOT match | |
| includePatterns | No | pathname glob patterns URLs must match, e.g. '/docs/*' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the BFS algorithm, depth/page limits, return types, and the caching side effect. However, it omits important behaviors such as whether robots.txt is respected by default (relevant to ignoreRobots) and does not mention error handling or output structure.
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 front-load the main action and return information without redundancy. Every phrase contributes to understanding the tool's function and its relationship to web_crawl_get_page.
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 tool with 8 parameters, no annotations, and no output schema, the description is under-specified. It gives a high-level overview but omits key details such as the exact return format, robots.txt policy, and parameter behaviors for contentDepth and ignoreRobots, making it insufficient for reliable autonomous 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 63%, but the description only partially compensates for undocumented parameters. It clarifies startUrl as the seed, but contentDepth and ignoreRobots are not explained anywhere, leaving the agent to guess their semantics. The description adds little meaning beyond the schema fields.
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 identifies the tool as a BFS crawler starting from a seed URL with depth/page limits, returning titles, link structures, and excerpts. It also mentions caching full markdown for web_crawl_get_page, which distinguishes it from sibling tools like web_scrape and web_check.
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 intended use is implied by the BFS crawl description and the caching note for web_crawl_get_page, suggesting a two-step workflow. However, it does not explicitly compare against alternatives or state when not to use this tool, so the guidance is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch cached page content discovered during a web_crawl call.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a read operation but does not disclose session prerequisites, error behavior, or cache persistence. No contradiction, but it leaves significant behavioral ambiguity 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 one concise sentence with no redundant words, and the title adds useful context. However, it is slightly under-specified, lacking parameter-level guidance that could be structured without bloat.
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?
The tool is simple, but the description omits crucial context: whether a web_crawl must be active, what happens if the URL is not cached, and the exact return format. Without annotations or an output schema, the description is inadequate for safe and 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?
The schema has no description for the 'url' parameter (0% coverage), and the description does not explicitly explain that the URL must refer to a previously crawled page. It offers only a vague implication via 'discovered during a web_crawl call,' which is insufficient to fully understand parameter semantics.
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 uses the specific verb 'Fetch' and resource 'cached page content discovered during a web_crawl call,' clearly distinguishing this from siblings like web_scrape (live scraping). The title reinforces the purpose: retrieving markdown for a previously crawled page.
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 implies usage after a web_crawl to retrieve cached content, but it does not explicitly mention when to avoid this tool or offer alternatives. The context is reasonably clear but relies on inference from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a page (or a subtree of it) has changed since the last check. Returns changed=true/false and a short snippet — not the full content — so repeated monitoring stays cheap.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| selector | No | scope the watch to this subtree, e.g. '.price' | |
| forceBrowser | No | ||
| ignoreRobots | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses a key behavioral trait: it returns only a short snippet, not full content, for cost efficiency. It also implies statefulness by referencing 'the last check.' However, it does not explain what constitutes a change, how state is stored, or behaviors around forceBrowser or ignoreRobots parameters, leaving meaningful gaps.
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 two sentences, directly stating purpose, return behavior, and the cost rationale. Every clause adds value, with no redundancy or filler. It is front-loaded with the core function and efficiently communicates the essential 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?
The tool has 4 parameters, no output schema, and no annotations. The description covers the return type (changed boolean and snippet) but omits meaningful detail about how state is tracked, what parameters like forceBrowser and ignoreRobots do, and the structure of the snippet. Given the tool's complexity, the description leaves too many operational aspects unexplained.
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 only 25% (only 'selector' has a description). The tool description adds meaning to the selector param by referencing 'subtree,' but it provides no explanation for url, forceBrowser, or ignoreRobots. With low coverage, the description fails to compensate for the undocumented parameters, leaving their semantics unclear.
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's function: checking whether a page or subtree has changed since the last check. It uses a specific verb ('Check') and resource ('page or subtree'), and the return type (changed=true/false) further clarifies the purpose. However, it does not explicitly differentiate itself from sibling tools like web_check or web_scrape.
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 phrase 'so repeated monitoring stays cheap' implies this tool is intended for repeated/watchful usage, offering a mild usage guideline. It does not explicitly state when to use this tool over alternatives, nor provide exclusions or when-not-to-use scenarios. The usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a sequence of actions (click, fill, select, press, waitFor) on a live page — for testing flows or reaching content behind interaction. Returns a text accessibility snapshot by default; pass screenshot=true only when you actually need to see pixels.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| actions | Yes | ||
| sessionId | No | persist cookies/localStorage under this session identifier across calls | |
| screenshot | No | ||
| ignoreRobots | No | ||
| resultSelector | No | scope the returned snapshot to this subtree |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the default return type ('text accessibility snapshot') and provides guidance on the screenshot parameter ('only when you actually need to see pixels'). However, it does not mention potential side effects, execution behavior, error handling, or session persistence, leaving some ambiguity for a tool that performs live page interactions.
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 exactly two sentences, front-loaded with the primary purpose and method, followed by crucial output and performance guidance. Every word earns its place; no fluff or redundancy.
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 no output schema and 6 parameters, the description covers the core purpose and default output, but omits details on action sequence semantics, session handling, ignoreRobots, and potential failure modes. It is sufficient for basic understanding but lacks the depth needed for fully complex interaction scenarios.
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 only 33%, so the description must compensate. It names the allowed action types (click, fill, select, press, waitFor) and explains the screenshot default, which adds useful semantics. Yet it does not describe the structure of action objects, the url parameter, ignoreRobots, or other key fields beyond what the schema already provides. The partial compensation justifies a mid-range score.
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 a specific verb and resource: 'Run a sequence of actions... on a live page.' It also distinguishes itself from siblings by mentioning 'reaching content behind interaction' and returning a 'text accessibility snapshot,' making it clear this tool is for interaction rather than simple scraping or crawling.
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 gives clear context for when to use the tool: 'for testing flows or reaching content behind interaction.' It implies it should be used when page interaction is required, as opposed to static scraping. However, it does not explicitly name alternatives or specify when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and return clean content — markdown by default, or specific fields via a CSS-selector schema. Tries a plain HTTP fetch first and only launches a browser if the page needs JS to render.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| format | No | markdown | |
| schema | No | field name -> CSS selector, required when format=json | |
| selector | No | scope markdown extraction to this CSS selector subtree | |
| forceBrowser | No | skip the static-fetch tier for pages known to require JS | |
| ignoreRobots | No | ignore robots.txt restriction rules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output format (markdown vs. schema fields) and the smart fetch strategy ('Tries a plain HTTP fetch first and only launches a browser if the page needs JS to render'). It does not mention robots.txt enforcement or timeout behavior, but the core behavior is well disclosed.
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 two sentences, front-loaded with the main action ('Fetch a URL and return clean content'), and every clause adds meaningful behavior. No fluff or redundancy; it is an exemplary concise description.
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 tool with 6 parameters, no output schema, and no annotations, the description covers the essential context: primary use, output formats, and the JS-rendering fallback. It omits details like default robots.txt behavior and error handling, but it is sufficiently complete for an experienced agent to invoke the tool correctly in most scraping scenarios.
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 67%, so the description should add some semantic value. It does clarify the 'format' parameter by saying 'markdown by default' and introduces the 'CSS-selector schema' concept. However, it does not describe 'selector', 'forceBrowser', or 'ignoreRobots', though those do have schema descriptions. Overall, it adds moderate value 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 the tool's function: 'Fetch a URL and return clean content', with a specific output mode (markdown or CSS-selector schema). It distinguishes itself from siblings by focusing on single-page scraping, but it does not explicitly name alternative tools like web_crawl_get_page, so it falls just 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for fetching and cleaning a webpage's content), but it offers no explicit comparison to alternatives, no exclusions (e.g., when to use web_crawl instead), and no mention of prerequisites or limitations. The usage context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete persisted cookies and storageState for a given sessionId.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | the session identifier to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool deletes persisted cookies and storageState, which is a specific destructive side effect. However, it does not mention reversibility, permission requirements, or behavior when the session does not exist, leaving some gaps given the absence of annotations.
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?
A single sentence that is front-loaded with the verb 'Delete' and precisely states the action and target. Every word contributes.
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 tool with one parameter and no output schema, the description covers the core functionality and the parameter. It lacks usage context and error behavior, but it is sufficient for basic selection and 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?
The input schema fully documents the sessionId parameter with a clear description, and the tool description reinforces its role by saying 'for a given sessionId.' No additional semantic value is added 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 uses a specific verb ('Delete') and specifies the exact resources affected ('persisted cookies and storageState') for a given sessionId. This clearly distinguishes it from siblings like web_scrape or web_interact, which perform different actions.
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 does not explicitly state when to use this tool versus alternatives, though the title and action imply 'when you are done with a session.' No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes: scraping, crawling, interaction, checking, diffing, and session management are clearly separate. However, web_scrape and web_crawl_get_page both return page content (one on-demand, one cached), and web_check vs web_diff both verify page state, creating slight overlap.
All tools share a 'web_' prefix, but the structure varies: mostly verb (web_scrape, web_check, web_interact, web_crawl), but web_session_close is noun-verb and web_crawl_get_page is verb-noun-noun. The pattern is readable but not entirely consistent.
Seven tools is well within the ideal range for a web agent server. Each tool serves a distinct function without redundancy, and the count feels appropriate for the domain of scraping, crawling, interaction, and monitoring.
The set covers core web operations: fetch, crawl, interact, check, diff, and session cleanup. Minor gaps include no explicit session creation tool (though implied by web_interact) and no dedicated screenshot tool (though web_interact supports screenshots). These are workable gaps, not critical failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scrape, crawl and search the web for AI agents via MCP.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.…
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/creatorpiyush/webmesh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server