URLpipe

Detect a page's technologies

detect_technologies

Idempotent

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 providers, chat widgets, consent managers and more — from an open database of over 7,000 fingerprints. Each technology comes with its version when the page gives it away, a confidence from 0 to 100, its categories, its website and CPE, and which signals gave it away (html, meta tags, headers, cookies, JavaScript globals, DOM, script URLs and contents, stylesheets, DNS records, robots.txt). The page is rendered first, so technologies loaded by JavaScript are found too. 1 credit.

Input Schema

Name	Required	Description
`url`	Yes	The page to fetch. Must be a public http(s) URL.
`sync`	No	Wait for the result and return it (default false). When false the call returns a token immediately and you collect the result with get_result.
`labels`	No	Your own keys to find this request by later, e.g. {"client": "acme"}: they come back with the result, in the webhook and in list_requests, which can filter by them. Up to 16 keys of up to 40 letters, digits, _ - or .; string values up to 256 characters.
`max_age`	No	How fresh a stored result must be to be reused, e.g. "2 hours" or "3 days". Default 7 days, maximum 30. A reused result is free. Pass "0" to force a fresh fetch.
`report_to`	No	Async only: a webhook URL to deliver the result to. Defaults to the project's configured endpoint, if it has one.
`project_id`	Yes	Which project this request belongs to. From list_projects.
`residential`	No	Fetch the page from a residential (home ISP) exit instead of a datacentre one. Costs a surcharge per page visit — see get_usage. Use it for sites that block datacentre traffic.
`auth_profile`	No	Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles
`page_options`	No	What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them.
`idempotency_key`	No	Makes the call safe to retry: sending it again with the same key within 24 hours returns the first call's token and result instead of starting (and charging for) new work, even with max_age "0". Up to 255 printable ASCII characters; a UUID is ideal.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / auth_profile

Added value: +{
+  "description": "Load the page signed in, as this auth profile's visitor: its id, ap_…. A profile is a browser's signed-in state uploaded once over the HTTP API (POST /auth_profiles); only URLs on its domains are accepted. Costs nothing extra. https://urlpipe.dev/docs/auth-profiles",
+  "type": "string"
+}

Changed2 schema fields changedOct 12, 2026

changedInput schema / properties / page_options / description

Previous value: -"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too."New value: +"What to do to the page before anything is read off it. Applies to the result itself: removed ads and banners are gone from html, markdown and summaries too, and what scrolling loaded is in all of them."

addedInput schema / properties / page_options / properties / scroll_to_bottom

Added value: +{
+  "description": "Scroll down the page before reading it, for as long as scrolling loads more (up to 25s). For listings and feeds that load their content as they are scrolled.",
+  "type": "boolean"
+}

AddedOct 12, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only flag the coarse profile (openWorld, idempotent, non-destructive), while the description adds two things they cannot convey: the page is rendered first so JS-injected technologies are caught, and the call costs 1 credit. It does not contradict the annotations — POST-ing a job that isn't destructive and is idempotent is consistent with readOnlyHint false, destructiveHint false, idempotentHint true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded paragraph that opens with the purpose, then the result contents, then rendering behavior and cost. It is dense but each clause adds value; only the long enumeration of technology categories and signal types is slightly padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an existing output schema and fully described parameters, the description covers the non-obvious pieces an agent needs: rendering before detection, fingerprint database scope, and credit cost. It stops short of advising on sync vs async or cached-result reuse, though those live in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Every parameter is already documented at 100% schema coverage, so the schema carries the semantics. The description adds no parameter-level detail beyond noting the rendering step (loosely tying to page_options), so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Detects what a page is built with') and enumerates the technology classes found (CMS, JS frameworks, analytics, CDN, payment providers, etc.), which clearly separates it from siblings like extract_metadata or fetch_html.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The use case is implied clearly enough — you call this when you want a technology fingerprint of a URL — but there is no explicit guidance on when to prefer it over scrape_url, extract_metadata or run_lighthouse_audit, and no stated prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All URLpipe tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?