URLpipe MCP server

• Registry namedev.urlpipe/mcpverified in the MCP registry

The registry name sits under urlpipe.dev. The registry only lets a publisher use that namespace after proving control of the domain through DNS or HTTP.

• Stateanswerschecked 2026-10-20
• Tools17
• Server calls itselfurlpipe
• Server version1.4.0
• Protocol version2025-06-18

On 2026-10-20 the server answered initialize and tools/list without a sign-in. First answer in 209 ms.

• Its tools do every use case we checked: Convert web pages to clean markdown for an AI agent; Capture full-page screenshots or PDFs of URLs; Check client websites for changes over time.
• Checked on 2 of the 7 days it takes to judge reliability.

Said by rules from the measurements above. The likely first call is a model's pick from the tool list; read its description before relying on it.

• INITE MCP scoreafter a weeka score needs 7 daily checks: 2 so far
• What an agent can do with it3 of 3 use cases
• Answeredmeasuring2 of the 7 daily checks it takes to print a share
• Median first answer705 ms
• Space in an agent's context≈ 13,350 tokensthe definitions of all its tools (17), which an agent carries on every turn
• Tool definitionsA · 100 of 100
• Typed results17 of 17 toolsdeclared outputSchema: results come typed, read once

• Every tool passes all six checks.

A program checks the server once a day: initialize and tools/list, no model. Tokens are the definitions' length at about four characters a token. The grade averages six checks of every tool's name, description, schema and annotations; it says how well the tools are described, not whether they work. The score weighs what was measured and nothing else: answering (30%), doing the product's job (25%), definitions (20%), context (10%) and use (15%). A part that was not measured is left out, and a hidden instruction caps the score at 40. The state of vendors' MCP servers: method and numbers →

• list_projects

  The projects this token can reach, each with how many requests it has made in the last 30 days and where its results are delivered. Start here: every other tool takes a project_id from this list. A project is the unit a request is billed…

• get_usage

  What the organization's plan allows, how much of it is left this period, and what each operation costs. Worth reading before a run of expensive calls: the operations differ by seventeen times in price, so the difference between…

• fetch_markdown

  Exposes POST /markdown. Renders the page in headless Chrome and converts its main content to clean Markdown — headings, lists, links and code kept, navigation, sidebars and cookie banners dropped. Start here when you want to READ a page…

• fetch_html

  Exposes POST /html. Returns the page's HTML after JavaScript has run and redirects have been followed — the DOM a real browser sees, not the empty shell curl returns. 1 credit. Use it when you need the markup itself: a specific attribute…

• capture_screenshot

  Exposes POST /screenshot. Captures the whole rendered page as a PNG — JavaScript executed, web fonts and images included, exactly as a browser would draw it. 1 credit, whichever options you use. Use it to see a page rather than read it…

• capture_pdf

  Exposes POST /pdf. Prints the whole rendered page to a PDF — JavaScript executed, web fonts and lazy-loaded images included, its headings as bookmarks. 1 credit, whichever options you use. Use it to archive or hand on a page as a…

• capture_console_errors

  Exposes POST /console. Loads the page in headless Chrome and returns what it reported through console.error and console.warn during load, plus uncaught exceptions and unhandled promise rejections (not console.log). 1 credit. What you…

• run_lighthouse_audit

  Exposes POST /lighthouse. Runs a real Google Lighthouse audit against the live page: performance, accessibility, best-practices and SEO scores plus Core Web Vitals. 2 credits — dearer than a page fetch because the audit runs in its own…

• extract_metadata

  Exposes POST /meta. Reads everything a page declares about itself — Open Graph, Twitter cards, meta tags, JSON-LD, microdata and links — into one object with the same keys on every page: title, description, site name, kind of page…

• detect_technologies

  Exposes POST /technologies. Detects what a page is built with — CMS, e-commerce platform, JavaScript frameworks and libraries, analytics and tag managers, advertising and marketing tools, CDN, web server, programming language, payment…

• extract_keywords

  Exposes POST /keywords. Returns the 5–15 terms and phrases that best represent the page, ordered by relevance — ranked by a language model, not by raw frequency. 15 credits. As with summarize_page: if you are going to reason over the…

• summarize_page

  Exposes POST /summarize. Returns a concise Markdown summary of the page's main content, with the navigation, ads and boilerplate left out. The most expensive operation we sell, at 17 credits, because it runs a language model over the…

• extract_data

  Exposes POST /extract. Reads the page and fills an object YOU define: pass `fields`, each with a name, a type and a description of what to take from the page, and get back exactly those keys in that order. Anything the page does not give…

• scrape_url

  Exposes POST /scrape. Runs any subset of the other operations in one request, served from a single page visit where possible. Each operation is billed and stored exactly as the individual call would be, so this is not a discount — with…

• get_result

  Exposes GET /result/:token. Returns the result of a past request, in the same form the call that made it would have returned — Markdown as Markdown, a structured operation as its object, a screenshot as an image, a PDF as an embedded…

• list_requests

  A project's recent requests, newest first, with each one's token. Look here before fetching a page: if somebody already pulled it, passing that token to get_result returns the same result for nothing. A /scrape appears as one entry — its…

• get_request

  Everything about one past request except its result: what was asked for, how long each stage took, whether it came from the store, and how the webhook delivery went. This is the metadata; get_result returns the page itself. Reach for this…