AgentScrape is a pay-per-call web scraping and browser automation service for AI agents, using USDC payments on Base — no signup or API keys required.
Scrape webpages: Fetch content from any URL as markdown, HTML, plain text, or JSON, with viewport control (desktop/mobile/tablet), CSS selector waiting, and post-load delays.
Extract structured data: Use natural language prompts and optional JSON schemas to extract structured data, powered by Groq + Llama 4 Scout.
Capture screenshots: Take PNG screenshots with desktop, mobile, or tablet viewports, plus optional full-page capture.
Extract metadata: Pull title, description, Open Graph tags, Twitter cards, JSON-LD, canonical URL, and all meta tags from any page.
Create browser sessions: Spin up stateful sessions that persist cookies and localStorage across multiple calls (configurable TTL up to 2 hours).
Run multi-step workflows: Automate complex browser interactions atomically with up to 20 steps — navigate, click, type, scroll, wait, screenshot, extract, and evaluate JavaScript.
Pricing is $0.001 per call (during validation) via the x402 v2 payment protocol, with a free tier of 10 calls per wallet every 30 days. Integrates with Claude Desktop, Cursor, Continue.dev, and ElizaOS via MCP.
Facilitates USDC payments via Coinbase CDP, enabling pay-per-call web scraping without accounts or API keys.
Pay-per-call web scraping for AI agents — no signup, no API keys, just USDC.
Live: agent-scrape.healingsunhaven.workers.dev
AI agents discover AgentScrape, pay per call in USDC on Base, and get clean structured data back — no accounts, no API keys, no human in the loop.
Two protocols, one service:
HTTP API with x402 v2 payment gate — for agents using raw HTTP
MCP server (Streamable HTTP transport) — for Claude Desktop, Cursor, Continue.dev, and any MCP-compatible framework
Traditional scraping APIs assume a human:
Sign up with email
Add a payment method
Manage an API key
Commit to a monthly subscription
AI agents can't do any of that. They have wallets. They have stablecoins. They need infrastructure built for them.
AgentScrape speaks two open standards:
x402 — HTTP-native payment protocol. The server returns 402 with payment requirements; the agent signs a USDC transfer; the facilitator settles on-chain; the data flows back. End-to-end in under 2 seconds.
MCP — the standard agent tool interface. Agents browse, discover, and invoke tools without per-vendor SDKs.
No signup. No API keys. No subscription. Just USDC.
Related MCP server: skim-mcp
All tools cost $0.001 USDC during the mainnet validation window. Pricing ramps after stability is proven (see Pricing).
Tool | Description |
| Scrape any URL to markdown, HTML, text, or JSON |
| AI-powered structured extraction with natural-language prompts and JSON schemas (Groq + Llama 4 Scout) |
| PNG screenshot with viewport control (desktop/mobile/tablet, optional full-page) |
| Title, description, Open Graph, Twitter cards, JSON-LD, canonical URL |
| Stateful browser session with cookie + localStorage persistence |
| Multi-step atomic execution: navigate, click, type, wait, scroll, screenshot, extract, evaluate |
# Free service discovery (no payment)
curl https://agent-scrape.healingsunhaven.workers.dev/
# Paid call — without payment, returns 402 with payment requirements
curl -X POST https://agent-scrape.healingsunhaven.workers.dev/scrape \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com", "format": "markdown"}'
# Free tier — first 10 calls per wallet, send your wallet in the X-402-Payer header
curl -X POST https://agent-scrape.healingsunhaven.workers.dev/scrape \
-H "Content-Type: application/json" \
-H "X-402-Payer: 0xYourBaseWalletAddress" \
-d '{"url": "https://example.com", "format": "markdown"}'Add to any MCP-compatible client via Streamable HTTP:
{
"mcpServers": {
"agent-scrape": {
"url": "https://agent-scrape.healingsunhaven.workers.dev/mcp",
"transport": "streamable-http"
}
}
}The x402 payment metadata is broadcast inside the MCP tools/list response. Your client handles the payment handshake automatically when configured with an x402-compatible wallet.
For machine-driven discovery, four standard endpoints are exposed (free, no auth):
Endpoint | Purpose |
| Service profile JSON (tools, prices, network, payTo) |
| x402 manifest — payTo, network, facilitator, all paid routes |
| OpenAPI 3.1 spec for traditional tooling |
| Agent-friendly plaintext description |
The 402 response itself carries the canonical payment requirements in the base64-encoded Payment-Required header, and the body includes a human-readable error with discovery links.
┌──────────────────────────────────┐
│ Cloudflare Workers │
│ (global edge, 330+ POPs) │
│ │
AI Agent ───────┼─▶ GET / (free)│
(HTTP) ├─▶ GET /.well-known/x402 (free)│
├─▶ GET /openapi.json (free)│
├─▶ GET /llms.txt (free)│
├─▶ POST /scrape ($0.001) │
├─▶ POST /extract ($0.001) │
├─▶ POST /screenshot ($0.001) │
├─▶ POST /metadata ($0.001) │
├─▶ POST /workflow ($0.001) │
├─▶ POST /session ($0.001) │
│ │
AI Agent ───────┼─▶ POST /mcp │
(MCP) │ • initialize │
│ • tools/list │
│ • tools/call (paid) │
│ │
└──────────────┬───────────────────┘
│
┌────────────────┴─────────────────┐
│ │
Coinbase CDP facilitator Browser Rendering API
(api.cdp.coinbase.com/ Groq API (Llama 4 Scout)
platform/v2/x402) KV (sessions, free tier)
Ed25519 JWT auth
Settles USDC on Base
│
▼
payTo wallet 0x3F33...9E9aStack:
Runtime: Cloudflare Workers (V8 isolates, global edge)
HTTP framework: Hono + @x402/hono v2 payment middleware
MCP framework: @modelcontextprotocol/sdk + agents/mcp with withX402 payment binding
Bazaar discovery: @x402/extensions — every paid route declares input schema + output example
Browser: Cloudflare Browser Rendering API + @cloudflare/puppeteer
AI extraction: Groq + Llama 4 Scout (17B, 16E)
Storage: Cloudflare KV (5-min response cache, browser sessions, free-tier counters)
Network: Base mainnet (eip155:8453)
Asset: Native USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)
Facilitator: Coinbase CDP (api.cdp.coinbase.com/platform/v2/x402) with Ed25519 JWT auth
Every wallet address gets 10 free calls per 30 days on the HTTP API. Pass your Base wallet in the X-402-Payer header. After 10 calls, payment via x402 is required.
Free tier is HTTP-only. MCP calls go through the standard x402 payment flow.
Launch window (first 48h on mainnet): $0.001 flat per tool call.
After validation, pricing ramps to:
Tool | Production price |
| $0.003 |
| $0.005 |
| $0.003 |
| $0.002 |
| $0.008 |
| $0.001 |
Bulk discounts (20% at 1K calls/month, 40% at 10K) are planned.
Traditional API | x402 + MCP |
Sign up at scraperapi.com | Discover via MCP |
Add credit card | Wallet holds USDC |
Get API key | No keys |
$49/month minimum | $0.001 per call |
Manage rate limits | Pay-per-use, no limits |
Human in the loop | Agent fully autonomous |
# Service identity
curl https://agent-scrape.healingsunhaven.workers.dev/ | jq .
# x402 manifest
curl https://agent-scrape.healingsunhaven.workers.dev/.well-known/x402 | jq .
# 402 challenge with x402 v2 headers
curl -i -X POST https://agent-scrape.healingsunhaven.workers.dev/scrape \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'
# → HTTP 402, Payment-Required header (base64 JSON), Cache-Control: private, no-store
# CORS preflight (browser-based agents)
curl -i -X OPTIONS https://agent-scrape.healingsunhaven.workers.dev/scrape \
-H "Origin: https://example.com" \
-H "Access-Control-Request-Method: POST" \
-H "Access-Control-Request-Headers: Content-Type,X-Payment"
# → HTTP 204, allow-headers includes X-Payment and Payment-SignatureQ3 2026:
AgentParse — document/PDF/OCR-to-markdown service (same x402 + MCP pattern)
AgentSearch — multi-backend web search aggregation
LangChain integration package (langchain-agent-scrape)
Q4 2026:
Subscription bundles (1000 scrapes for $2.50)
Multi-asset support (USDT on Base, USDC on Arbitrum)
Webhook + async response option for long-running workflows
Requires Node 22+, a Cloudflare account with Workers + Browser Rendering enabled, a Groq API key, and a Coinbase CDP API key.
git clone https://github.com/hshintelligence/agent-scrape.git
cd agent-scrape
npm install
# Set secrets
npx wrangler secret put GROQ_API_KEY
npx wrangler secret put CDP_API_KEY_ID
npx wrangler secret put CDP_API_KEY_SECRET
# Local dev
npx wrangler dev
# Deploy
npx wrangler deployTo use your own wallet as payTo, edit the PAY_TO constant in src/index.ts.
MIT — see LICENSE.
Built by HSH Intelligence, operated by Healing Sun Haven LLC (Wyoming, USA).
General inquiries: sales@healingsunhaven.com
Pay-per-call web scraping for AI agents — no signup, no API keys, just USDC.
ElizaOS supports remote MCP servers natively via the @elizaos/plugin-mcp plugin. AgentScrape works out of the box — no custom integration needed.
bun add @elizaos/plugin-mcp
# or
npm install @elizaos/plugin-mcpIn your ElizaOS character JSON, add the plugin and point the MCP server config at AgentScrape's Streamable HTTP endpoint:
{
"name": "ResearchAgent",
"plugins": ["@elizaos/plugin-mcp"],
"settings": {
"mcp": {
"servers": {
"agentscrape": {
"type": "streamable-http",
"name": "AgentScrape",
"url": "https://agent-scrape.healingsunhaven.workers.dev/mcp",
"timeout": 60
}
}
}
}
}Once configured, the agent automatically discovers all six AgentScrape tools:
Tool | Cost | Purpose |
| $0.003 USDC | Markdown/HTML/text/JSON scrape |
| $0.005 USDC | AI extraction via Groq + Llama 4 Scout |
| $0.003 USDC | PNG screenshot with viewport control |
| $0.002 USDC | Title, OG, Twitter, JSON-LD |
| $0.001 USDC | Stateful browser session |
| $0.008 USDC | Multi-step atomic workflow up to 20 steps |
The first 10 calls per wallet in the first 30 days are free. After that, calls are paid in USDC on Base mainnet (eip155:8453) via the x402 v2 payment protocol. To pay, supply the X-PAYMENT-RESPONSE header with an x402 payment receipt on retry — the standard x402 flow.
Once the plugin is wired up, your ElizaOS agent can use AgentScrape transparently:
User: "Scrape https://www.x402.org and give me a two-sentence summary."
ElizaOS routes the request through @elizaos/plugin-mcp, which calls AgentScrape's scrape_webpage tool, and the agent answers based on the live page content.
AgentScrape Worker: https://agent-scrape.healingsunhaven.workers.dev
x402 manifest: https://agent-scrape.healingsunhaven.workers.dev/.well-known/x402.json
A2A Agent Card: https://agent-scrape.healingsunhaven.workers.dev/.well-known/agent.json
Create a stateful browser session that persists cookies and localStorage across multiple scrape/workflow calls.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl_seconds | No | Session TTL in seconds (default 1800, max 7200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the persistence behavior (cookies, localStorage) but omits details like session limits, expiration effects, or reuse 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 a single, clear sentence with no superfluous words, though it could be slightly more structured (e.g., separated into purpose and details).
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 fails to mention the return value (e.g., session ID), which is critical for an agent invoking a create tool. No output schema exists to compensate.
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 already fully describes the single parameter (ttl_seconds) with its default and max; the description adds no additional semantic value beyond that.
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 creates a stateful browser session with persistence across calls, distinguishing it from sibling tools focused on scraping or data extraction.
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 for maintaining state across calls but lacks explicit guidance on when to use versus alternatives or when not to use (e.g., stateless scraping).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract page metadata: title, description, Open Graph, Twitter cards, JSON-LD, canonical URL, and all meta tags.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to extract metadata from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It indicates a read-only operation (extracting metadata) with no destructive hints. However, it lacks details on authentication, rate limits, or whether the fetch is live or cached.
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 efficient sentence that lists the extracted metadata types. Every piece of information is relevant and 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 the tool has one parameter, no output schema, and no annotations, the description adequately covers the purpose and output content. It could mention the return format (e.g., JSON object) but is complete enough for a simple extraction 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% with one parameter 'url'. The description adds that it extracts metadata from the URL, which is implied by the schema. Listing the metadata types provides context but does not enhance parameter understanding 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 verb 'extract' and the resource 'page metadata', listing specific types (title, description, Open Graph, etc.). This distinguishes it from siblings like 'extract_structured_data' and 'scrape_webpage'.
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 like 'extract_structured_data' or 'scrape_webpage'. Usage context is implied by the tool name and description but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-powered structured data extraction from any webpage using natural language. Returns JSON matching your prompt or schema.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to extract from | |
| prompt | Yes | Natural language description of what to extract | |
| schema | No | Optional JSON schema for the response | |
| wait_for | No | CSS selector to wait for before extracting | |
| wait_ms | No | Milliseconds to wait after page load |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must handle all behavioral disclosure. It only says 'AI-powered' and 'Returns JSON', omitting details like potential slowness, failure modes, or how wait parameters affect 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?
A single sentence with no unnecessary words. Every part of the description is relevant.
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 5 parameters including wait options and no output schema, the description is too brief. It does not explain return structure beyond 'JSON matching your prompt or schema' or address behavior for dynamic content.
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 provides 100% description coverage, so baseline is 3. The description adds 'using natural language' and 'Returns JSON' but does not enrich parameter semantics 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 it extracts structured data from any webpage using natural language and returns JSON. This distinguishes it from sibling tools like scrape_webpage (raw content) and extract_metadata (metadata).
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?
It implies usage for extracting specific data points via natural language but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a multi-step browser workflow atomically: navigate, click, type, wait, scroll, screenshot, extract, evaluate. Up to 20 steps.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Ordered list of workflow steps to execute | |
| session_id | No | Existing browser session ID to reuse | |
| persist_session | No | Save session state after workflow completes | |
| viewport | No | Viewport size (default: desktop) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only notes atomic execution and a 20-step limit, omitting error handling, idempotency, authentication, or rate limits.
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?
Single sentence, 16 words, front-loaded with key verbs and limit. No filler 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 the tool's complexity (nested steps, 4 parameters), the description lacks details on return values, error states, session reuse, and step composition rules. Output schema absent makes it harder for agents to anticipate results.
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%, baseline 3. Description adds meaningful constraints: step limit (20) and atomicity, which are not in the schema. This elevates the 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 the tool executes a multi-step browser workflow atomically, listing all supported actions (navigate, click, type, etc.). It distinguishes from sibling tools (scrape_webpage, screenshot_webpage) by indicating it can combine multiple actions in sequence.
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?
No guidance on when to use this tool versus alternatives. The description does not mention conditions like 'for complex interactions' or 'instead of single-step tools'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape any webpage and return content as markdown, html, text, or json. Pay-per-call web scraping for AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to scrape (http or https) | |
| format | No | Output format (default: markdown) | |
| wait_for | No | CSS selector to wait for before extracting | |
| wait_ms | No | Milliseconds to wait after page load (max 10000) | |
| viewport | No | Viewport size (default: desktop) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'Pay-per-call' as a behavioral cost, which is helpful. However, it lacks details on rate limits, error handling, JavaScript execution, or any destructive actions. Since no annotations are provided, the description carries the full burden, and this is insufficient for a scraping 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 concise at two sentences, with no unnecessary words. It conveys the core function and a key behavioral note. However, it could be slightly more structured by front-loading the primary action and then format options.
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 5 parameters and no output schema, the description should provide more context about return values, error conditions, or prerequisites. It only mentions output formats and pay-per-call, leaving gaps about behavior like waiting, viewport, or URL validation.
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 5 parameters are described in the schema (100% coverage). The description adds limited value by listing output formats, but this is already covered by the enum. 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 clearly states 'Scrape any webpage' and lists output formats, which is a specific verb+resource. However, it does not distinguish from sibling tools like extract_structured_data, which might also scrape but for different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. For example, there is no mention of when to use scrape_webpage over screenshot_webpage or extract_structured_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a PNG screenshot of any webpage. Supports desktop, mobile, and tablet viewports, plus full-page mode.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to capture | |
| full_page | No | Capture full scrollable page (default: false) | |
| viewport | No | Viewport size (default: desktop) | |
| wait_for | No | CSS selector to wait for | |
| wait_ms | No | Milliseconds to wait after page load |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States output is PNG and describes viewport support, but misses details on error handling, timeouts, or dynamic content 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?
Single sentence that front-loads the core action. Every word earns its place; zero waste.
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, the description clarifies output format (PNG). Covers main features briefly but could mention error cases or size limits for full 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 100%, and description adds minimal value beyond listing viewports and full-page mode. Does not explain wait_for or wait_ms beyond 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 states 'Capture a PNG screenshot of any webpage' with specific verb and resource. Differentiates from siblings like scrape_webpage or extract_metadata by mentioning viewport and full-page modes.
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?
Implied usage through feature listing but lacks explicit when-to-use or when-not-to-use guidance. No comparison with sibling tools provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose: session management, metadata extraction, AI-powered extraction, workflow execution, general scraping, and screenshots. No functional overlap exists.
All tools follow a consistent verb_noun pattern (e.g., create_browser_session, scrape_webpage), making it easy to predict tool behavior from names.
With 6 tools covering core scraping, extraction, workflow, and screenshot capabilities, the count is well-scoped and avoids unnecessary complexity.
The set covers essential scraping tasks, but could benefit from tools for advanced session controls (e.g., cookie management) or configuration (e.g., custom headers). Minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
25 pay-per-request intelligence APIs for AI agents via x402 micropayments (USDC/Base)
Pay-per-call data APIs for AI agents. USDC on Base via x402. 33 tools, no signup.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
x402 pay-per-call APIs for AI agents on Base: site audits, llms.txt, wallet watch, prices, fetch.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hshintelligence/agent-scrape'
If you have feedback or need assistance with the MCP directory API, please join our Discord server