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., "@url-context-mcp fetch https://example.com 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.
An MCP (Model Context Protocol) server that fetches web pages and extracts clean, AI-usable context from them. Runs over stdio transport.
It's designed for AI agents that need to:
Read a web page as clean markdown (no boilerplate, no nav/footer noise)
Discover links on a page (with filters) before deciding what to fetch next
Search pages for specific text/code without reading the whole thing
Do all of the above in a single call
Tool | What it does |
| Fetch a URL → readable article as markdown (or |
| Get all links from a URL or raw HTML. Optional regex |
| Regex search a URL's content; returns matches with surrounding context. |
| One-shot combo: returns content and links and search matches in a single call. The most token-efficient way to understand + navigate a page. |
| Fetch an image by URL (absolute or relative to a base page) and return it as base64 image content the model can see. Resolves relative URLs from page extraction (e.g. |
All tools accept either a url (server fetches it) or raw html (you provide the markup), so they're composable with other fetchers too.
Related MCP server: mult-fetch-mcp-server
{
"mcpServers": {
"url-context": {
"command": "npx",
"args": ["-y", "url-context-mcp"]
}
}
}That's it. npx -y downloads and runs the server on first use; no separate install step needed. Requires Node.js 18+.
Readability-first: defaults to Mozilla Readability extraction so the agent gets the article, not the chrome. Reduces tokens and irrelevance.
One-call combo: fetch_and_search returns content + links + matches together — fewer round trips when an agent wants to "understand this page and find X on it".
Link discovery before prefetch: extract_links lets an agent survey a page's destinations and pick the right one to fetch, instead of guessing or fetching everything.
Regex search with context: agents can locate an error string, an API endpoint, a version number, etc. on a page with bounded context windows.
No browser, no head: pure HTTP + jsdom. Fast, sandboxed, works anywhere Node runs. No Playwright/Chromium dependency bloat.
Sane defaults + truncation: maxChars, limit, maxMatches keep responses bounded so context windows don't blow up.
npm install
node index.js # run the stdio server
npm pack # build the publishable tarballfetch_image: optional compression. Oversized images can now be
shrunk to fit within maxSizeKB instead of being rejected. Set
compress=true (default false) and the image is resized to
compressMaxWidth×compressMaxHeight (defaults 1024×768, aspect
preserved) and re-encoded as JPEG (or PNG when the source has an alpha
channel or is animated), lowering compressQuality (1–100, default 75)
in steps of 10 until under the limit. Supports tuning via
compressQuality, compressMaxWidth, compressMaxHeight.
fetch_image: hardened DoS guards. The response body is streamed
with a hard byte cap (applied regardless of compress), so chunked/
lying-header/infinite bodies can't OOM the server. Image decoding runs
with failOn: "error", an explicit limitInputPixels (≈26 MP) and
rejects via a pre-decode dimension check, blocking decompression bombs.
The compression encode loop is bounded by iteration count (6) and a
15 s deadline.
Server version bumps to 1.3; user-agent string updated accordingly.
New tool: fetch_image. Resolves an image URL (absolute, or relative
to a baseUrl) and returns it as an MCP image content block (base64
with a mimeType derived from the response Content-Type header, falling
back to the URL extension). Lets the model actually see images found in
pages marked up in markdown. Optional maxSizeKB (default 512 KB) protects
the context window from oversized payloads. MIME fallback map covers
png/jpg/jpeg/gif/webp/svg/bmp/avif/ico.
Server version bumps to 1.2; user-agent string updated accordingly.
Preserve dropped headings in extracted content. Mozilla Readability
strips the page <h1>/title from its content on minimal pages
(e.g. example.com: the # Example Domain heading was never returned by
fetch_url, and search_content therefore couldn't find "Example
Domain"). We now detect headings present in the raw body but missing from
Readability's cleaned HTML and re-prepend them, so the page title is
always part of the returned markdown/text and is searchable.
search_content raw-HTML fallback. When a search of the converted
(markdown/text) content finds zero matches and raw HTML is available,
the tool re-runs the search against the stripped raw text as a safety net.
The result flag notes when the fallback path was used ((raw-HTML fallback) in the header).
Misc: user-agent string bumped to 1.1.
MIT
Extract all hyperlinks from a URL (or raw HTML). Returns array of {href, text, title, section, isExternal, hash, type} grouped to dedupe. Great for discovering pages/anchors before fetching them.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to fetch and parse. Required unless 'html' is provided. | |
| html | No | Raw HTML to parse instead of fetching. If given, 'url' is used only as base for resolving relative links. | |
| limit | No | Max links to return. | |
| filter | No | Regex pattern; only links whose href or text match are returned. | |
| baseUrl | No | Base URL for resolving relative links when using 'html'. Defaults to 'url'. | |
| sameDomainOnly | No | Only return links on the same domain as the base URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (array of {href, text, ...}), mentions deduplication via grouping, and indicates support for raw HTML input. This adds meaningful behavioral insight beyond the schema, though it omits error handling and network behavior.
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: the first states action and return format, the second states the use case. It is front-loaded, concise, and contains no redundant 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?
Despite no output schema, the description lists the return fields, compensating well. The schema fully documents all six parameters. Combined, the description and schema provide complete understanding of tool usage, and sibling tools offer contrast.
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% with each parameter explained. The description adds context about the two input modes but no new semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 'Extract' with a clear resource 'all hyperlinks from a URL (or raw HTML)'. It distinguishes from sibling tools like fetch_url and search_content by focusing on link extraction, not content retrieval or searching.
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 provides clear usage context with 'Great for discovering pages/anchors before fetching them', implying a discovery step before fetching. However, it does not explicitly state when not to use or name alternative tools, so it stops 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.
One-shot combo: fetch a URL and simultaneously return BOTH the cleaned content AND its links AND any matching search snippets. Most efficient when you want to understand a page and also navigate/search it. Omit pattern/links as needed.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute URL to fetch. | |
| format | No | Content format to return. | markdown |
| pattern | No | Regex pattern to search in the content; omit to skip search. | |
| maxChars | No | Truncate returned content to this many characters. | |
| linkLimit | No | Max links returned. | |
| linkFilter | No | Regex to filter returned links (href or text). | |
| maxMatches | No | Max search matches. | |
| contextChars | No | Context chars around each match. | |
| includeLinks | No | Return the page's links. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It discloses the combined behavior (returning content, links, and snippets simultaneously) and the optional nature of pattern/links, but it does not mention potential side effects, network failures, rate limits, or whether the operation is read-only. This is a moderate level of transparency for a fetch tool.
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 long, front-loaded with the core purpose, and free of unnecessary details. Every sentence earns its place: the first explains what it does, the second gives usage context, and the third clarifies optional parameters. It is appropriately sized for the tool's complexity.
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 9 parameters and no output schema, so the description should provide a coherent picture. It gives a high-level overview of outputs (content, links, snippets) but does not describe the output structure or how the results are combined. While the schema covers parameters, the lack of return format details leaves some gaps for an agent invoking this 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 description coverage is 100%, so parameters are already well-documented in the schema. The description adds minimal value beyond that, with only the note to 'omit pattern/links as needed' and the implicit indication that links and search are included by default. This satisfies the baseline but doesn't significantly enhance understanding.
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 simultaneously return BOTH the cleaned content AND its links AND any matching search snippets.' It uses a specific verb (fetch) and names the resource (URL) and the combined outputs, distinguishing it from sibling tools like fetch_url and search_content by highlighting its one-shot combo nature.
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 provides explicit usage context: 'Most efficient when you want to understand a page and also navigate/search it.' It implies when to choose this combo over individual sibling tools, though it does not explicitly name alternatives or state when not to use it. The instruction 'Omit pattern/links as needed' offers additional practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an image from a URL (absolute or relative to a base page) and return it as base64 image content that the model can see. Use when a page's markdown contains relative image URLs (e.g. 
) and you need to view the image. Optional compression can shrink oversized images to fit within maxSizeKB.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Image URL. Can be absolute (http/https) or relative; if relative, baseUrl is required. | |
| baseUrl | No | Base/context URL to resolve a relative image URL against (the page the image was found on). | |
| compress | No | If true, an oversized image will be compressed (resized + quality-reduced, output JPEG) to fit within maxSizeKB instead of being rejected. | |
| maxSizeKB | No | Max image size in KB to return (rejects or compresses larger images). | |
| compressQuality | No | JPEG quality percentage when compressing (1-100, default 75). Lower = smaller file. | |
| compressMaxWidth | No | Maximum width in pixels when compressing (preserves aspect ratio). | |
| compressMaxHeight | No | Maximum height in pixels when compressing (preserves aspect ratio). |
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 discloses the base64 return format and optional compression, but it does not explain what happens when an image exceeds maxSizeKB and compress is false (rejection behavior), nor does it mention error handling. This is a partial disclosure, so a 3 is appropriate.
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 the core function, followed by the use case and the key feature. Every sentence contributes value and there is no redundancy or fluff.
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 description covers the main purpose, the relative URL scenario, and the compression option. It is complete enough for a tool with a well-documented schema, though it could mention the rejection behavior for oversized images. Given the absence of an output schema, the base64 return is mentioned, which is important.
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 describes all 7 parameters with 100% coverage, so the baseline is 3. The description adds a little context by mentioning compression in relation to oversized images and the relative URL use case, but it does not significantly expand on what the schema already provides.
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 ('Fetch') with a clear resource ('an image from a URL') and specifies the output format ('base64 image content'). It also includes a concrete use case with relative image URLs, effectively distinguishing it from sibling tools like fetch_url.
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 when to use the tool: 'Use when a page's markdown contains relative image URLs... and you need to view the image.' It provides clear context but does not explicitly list alternatives or when-not-to-use scenarios, so it doesn't earn 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 its main readable content as clean markdown by default (Readability extraction). Options: format=markdown|text|html|readable, includeLinks=false to strip hyperlinks, maxChars to truncate. Useful for reading a web page, understanding a code/docs page, or getting article content without boilerplate.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute URL to fetch (http/https). | |
| format | No | Output format. 'markdown' = readable article as markdown (default). 'readable' = same but also returns title/excerpt/length. 'text' = stripped text. 'html' = raw HTML. | markdown |
| maxChars | No | Truncate output to this many characters (0/unset = no limit). | |
| includeLinks | No | If false, strip <a> links when converting to markdown/text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals the Readability extraction behavior, default markdown output, and the impact of options like includeLinks and maxChars. This goes beyond minimal disclosure, though it omits potential error behaviors or rate limits, which are not essential for this simple tool.
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 with no redundancy. The first sentence states the core function and default behavior, while the second lists options and use cases. It is front-loaded with the key action and every clause contributes 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?
For a simple four-parameter tool with a fully described schema and no output schema, the description covers the operation, options, and ideal use cases. It does not address error handling or rate limits, but these are not critical for this tool's primary functions. The description is sufficiently complete to guide usage.
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 the baseline is 3. The description mentions format options, includeLinks, and maxChars, but essentially restates what the schema already provides. It adds no new semantic meaning beyond the schema descriptions, so a 3 is appropriate.
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 explicitly states 'Fetch a URL and return its main readable content as clean markdown by default (Readability extraction)', giving a specific verb ('fetch') and resource ('URL'), and clearly distinguishes from sibling tools by focusing on readable content extraction. This differentiates it from extract_links (link extraction), fetch_image (image fetching), and search_content (content search).
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 provides explicit use cases: 'reading a web page, understanding a code/docs page, or getting article content without boilerplate.' It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough to guide selection. The inclusion of sibling tool names in context also helps, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the content of a URL (or raw HTML) and return matching snippet(s) with surrounding context and line numbers. Useful to find specific text/code/errors on a page without reading the whole thing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to fetch and search. Required unless 'html' is provided. | |
| html | No | Raw HTML to search instead of fetching. | |
| format | No | Source content format to search in. | markdown |
| pattern | Yes | Regex pattern to search for in the page's text content. | |
| maxMatches | No | Max matches to return. | |
| contextChars | No | Characters of context before and after each match. |
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 mentions that it returns snippets with context and line numbers, which clarifies the output format, but it does not disclose details about making network requests, potential side effects, or any limitations. The description is adequate but not rich in behavioral transparency.
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 primary action, and every word earns its place. It is concise yet informative, with no redundant or filler content.
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 6 parameters and no output schema, but the description provides sufficient context: it explains the core functionality, gives a use case, and describes the return format (snippets with context and line numbers). However, it does not address the 'format' parameter or clarify the relationship with the sibling tool fetch_and_search, leaving minor gaps for a complex 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning by mentioning 'URL (or raw HTML)', which aligns with the url and html params, but it does not add substantive detail beyond what the schema already documents. Thus, the description neither substantially improves nor harms parameter understanding.
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: 'Search the content of a URL (or raw HTML) and return matching snippet(s) with surrounding context and line numbers.' This uses a specific verb and resource, and it distinguishes from fetch_url and extract_links, but it does not explicitly differentiate from the sibling tool fetch_and_search, which likely has a similar purpose.
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 provides context for when to use the tool: 'Useful to find specific text/code/errors on a page without reading the whole thing.' This gives clear usage context, but it does not mention alternative tools or when not to use this tool, so it lacks exclusions or explicit comparisons.
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.3.0extract_linksfetch_and_searchfetch_imagefetch_urlsearch_contentEach tool targets a distinct output (content, links, search snippets, combined result, or image). The combo tool fetch_and_search is explicitly labeled as a one-shot convenience, so there is no ambiguity about when to use it.
All tools use snake_case and start with a verb (fetch, extract, search). The only deviation is fetch_and_search, which uses a compound verb phrase rather than a strict verb_noun pattern, but it is still readable and consistent in style.
Five tools is a well-scoped size for a URL context server. Each tool covers a distinct need without unnecessary overlap or bloat.
The set covers the core operations of fetching content, extracting links, searching within pages, retrieving images, and a combined mode. No obvious missing functionality for the stated purpose.
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.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SkillfulElectro/url-context-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
