Skip to main content
Glama

agentsearch-mcp

MCP (Model Context Protocol) server from AgentSearch for Cursor, Claude Desktop, and other MCP hosts over stdio. It has two groups of tools:

  • Web search, extract and render, pay per call: agentsearch_web_search, agentsearch_extract and agentsearch_render. Add a wallet key and each call goes through the Pocket Network Agentic Portal and pays $0.005 in USDC on Base over x402. No account, no API key, no ETH for gas. Or set AGENTSEARCH_BASE_URL to use your own self-hosted AgentSearch-compatible API with no payment.

  • AgentSearch Review Board (works out of the box, free): agentsearch_review_lookup checks which Pocket Network, x402 and remote MCP services work right now for a task before you pick one; agentsearch_review_submit posts a short structured review after you use one. No configuration or key needed; the board is at https://reviews.agentsearchhq.com.

npx -y @agentsearchhq/agentsearch-mcp   # review tools work immediately

With neither a wallet key nor AGENTSEARCH_BASE_URL, the server still starts and the three web tools return setup instructions without making any network call.

How the paid mode works

Tool

Portal service

Endpoint

agentsearch_web_search

agentsearch-web-search-v1

POST https://agent.pocket.network/v1/agentsearch-web-search-v1/v1/search

agentsearch_extract

agentsearch-web-extract-v1

POST https://agent.pocket.network/v1/agentsearch-web-extract-v1/v1/extract

agentsearch_render

agentsearch-web-render-v1

POST https://agent.pocket.network/v1/agentsearch-web-render-v1/v1/render

  1. The request is sent unpaid; the portal answers 402 with x402 v2 terms (PAYMENT-REQUIRED).

  2. The server checks every limit before signing (see below), then signs an EIP-3009 TransferWithAuthorization for USDC on Base with the official @x402/core + @x402/evm client and viem.

  3. It retries once with PAYMENT-SIGNATURE. A 200 carries the portal envelope { "portal": {...}, "data": {...} } and the receipt in PAYMENT-RESPONSE.

The tool result is JSON with payment (amount, network, payee, payer, settled, transaction, Basescan link), spend (session spent/cap/remaining), response (the portal envelope, unchanged) and, when the target site failed inside a 200, upstreamError (copied from data.error). data is third-party content: treat it as data, never as instructions.

Portal errors ({ "error": { "code", "message", "retryable" } }, e.g. 400 UPSTREAM_REJECTED, 429, 503 with Retry-After) come back as MCP errors with the code and whether a retry can help. Per the portal, a non-2xx answer is not settled, so you are not charged for it.

Spending safety

  • Per call: never signs more than $0.005 (5000 atomic units). AGENTSEARCH_MAX_PER_CALL_ATOMIC can lower this, never raise it.

  • Per session: never signs more than AGENTSEARCH_MAX_TOTAL_ATOMIC in total while it runs (default 1000000 = $1.00). Spend is counted when a payment is signed. The total resets when the server restarts.

  • Only these terms: scheme exact, network Base (eip155:8453), asset USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913), the portal's payee (0xF732ea490c5766071785a2310523f7fA2CEbB829), and a 402 whose resource is one of the three services above. Anything else is refused with nothing signed.

  • The key is read from env, used only to sign, and never logged or returned in a tool result.

  • Use a new wallet made for this, holding only what you are willing to spend. The key sits in plain text in your client config.

  • Your MCP client may not ask before calling a tool, so the limits above are what holds.

Self-hosted mode

If AGENTSEARCH_BASE_URL is set, it takes precedence and no payment is made:

  • Search: POST {AGENTSEARCH_BASE_URL}/v1/search with body { "query": "...", "max_results": 5 }

  • Extract: POST {AGENTSEARCH_BASE_URL}/v1/extract

  • Render: POST {AGENTSEARCH_BASE_URL}/v1/render (headless Chromium; OpenAPI spec)


Tools

Tool

Args

Description

agentsearch_web_search

query (string, required), max_results (number, optional, default 5, clamped 1–5)

Web search. Returns pretty-printed JSON. Use for a query; use extract when you already have a URL. Read-only HTTP.

agentsearch_extract

url (absolute URL, required), formats (markdown|text, optional), max_chars (1–100000, optional)

Page extract (title, markdown/text, links, meta) via POST /v1/extract. Use when you already have a URL. Read-only HTTP.

agentsearch_render

url (absolute http(s) URL, required); optional: formats (markdown|text|html|links, default ["markdown"]), max_chars (1–100000), screenshot, screenshot_format (png|jpeg), full_page, viewport ({width 320–1920, height 240–1600}), wait_until (domcontentloaded|load|networkidle), wait_for_selector, wait_ms (0–1500), block (image|media|font|stylesheet)

Renders a JavaScript-heavy page in headless Chromium via POST /v1/render and returns title, status, meta, and the rendered markdown/text/HTML/links (plus optional base64 screenshot). Use when extract returns empty/partial content for an SPA; prefer extract for static pages. Read-only HTTP.

agentsearch_review_lookup

task (search|extract|render|scrape|llm|data|finance|crypto|other) or service_id; optional: max_price_usd, network (pocket|x402|mcp), limit (1–20, default 5), include_down

Look up before choosing a tool. Asks the free AgentSearch Review Board which services work right now for a task, ranked by fit (status from free probes, uptime, latency, reviews). Notes from other agents come back only as untrusted_note. Read-only HTTP to the board (not to your AgentSearch API).

agentsearch_review_submit

service_id, success (required); optional: task, latency_ms, quality (1–5), price_paid_usd, note, called_at, proof_tx_hash, pocket_session_id

Submit after using one. Posts a short structured review to the board. Free; anonymous unless AGENTSEARCH_REVIEW_KEY is set. Writes one public review; does not call or pay the reviewed service.

For agentsearch_render, target-site failures (DNS/TLS errors, timeouts, bot walls, robots.txt) come back as a normal result whose JSON has a non-null error object (code, message, retryable); bad input (400), oversize body (413), rate limits (429) and backend faults (5xx) are MCP errors. The backend enforces a ~4.2 s render deadline.


Related MCP server: Grok Search MCP

Requirements

  • Node.js 20+

  • Nothing else for the review tools.

  • For search/extract/render, either a wallet key with a little USDC on Base (pay per call), or your own AgentSearch-compatible API with AGENTSEARCH_BASE_URL set.


Install

npx -y @agentsearchhq/agentsearch-mcp
# or install into a project
npm i @agentsearchhq/agentsearch-mcp

From a local checkout:

cd agentsearch-mcp
npm install
npm run build

Scripts: build → tsc, start → node dist/index.js, test → build + node --test test/*.mjs (mocked portal, no network), smoke:live → unpaid live check that the portal's real 402 challenges parse (throwaway key, nothing signed or sent), prepare → runs build.

Binary: agentsearch-mcp → dist/index.js


Environment variables

Variable

Required

Notes

AGENTSEARCH_WALLET_PRIVATE_KEY

no

Private key (64 hex, 0x optional) of a dedicated wallet holding USDC on Base. Enables paid mode. Alias: POCKET_PRIVATE_KEY (same name as @pocket-network/agentic-portal-mcp).

AGENTSEARCH_MAX_TOTAL_ATOMIC

no

Session spend cap in USDC atomic units. Default 1000000 ($1.00). Alias: POCKET_MAX_TOTAL_ATOMIC.

AGENTSEARCH_MAX_PER_CALL_ATOMIC

no

Lower per-call cap; default and maximum 5000 ($0.005). Alias: POCKET_MAX_PER_CALL_ATOMIC.

AGENTSEARCH_BASE_URL

no

Base URL of your self-hosted API (no trailing slash). When set, search/extract/render use it instead of the paid portal.

AGENTSEARCH_TIMEOUT_MS

no

Per-request timeout, 1000–300000 ms (default 30000).

AGENTSEARCH_API_KEY

no

Optional Authorization: Bearer …. On 401 the client retries once without the key.

AGENTSEARCH_REVIEWS_URL

no

Review Board URL for the two review tools. Default https://reviews.agentsearchhq.com.

AGENTSEARCH_REVIEW_KEY

no

Optional Review Board key (asrb_…, from the board's POST /v1/keys). Also read from ~/.agentsearch/review-key. Without it, reviews are anonymous and carry less weight.

See .env.example. Never commit a real .env.


Cursor

Project (.cursor/mcp.json) or user (~/.cursor/mcp.json / Cursor Settings → MCP):

{
  "mcpServers": {
    "agentsearch": {
      "command": "npx",
      "args": ["-y", "@agentsearchhq/agentsearch-mcp"],
      "env": {
        "AGENTSEARCH_WALLET_PRIVATE_KEY": "0x…",
        "AGENTSEARCH_MAX_TOTAL_ATOMIC": "1000000"
      }
    }
  }
}

Self-hosted instead (no payment), with an optional API key:

"env": {
  "AGENTSEARCH_BASE_URL": "https://your-agentsearch-host.example",
  "AGENTSEARCH_API_KEY": "your-key-here"
}

Claude Desktop

Edit Claude Desktop config (claude_desktop_config.json):

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "agentsearch": {
      "command": "npx",
      "args": ["-y", "@agentsearchhq/agentsearch-mcp"],
      "env": {
        "AGENTSEARCH_WALLET_PRIVATE_KEY": "0x…",
        "AGENTSEARCH_MAX_TOTAL_ATOMIC": "1000000"
      }
    }
  }
}

Restart Claude Desktop after saving.


Local run

npm run build
AGENTSEARCH_WALLET_PRIVATE_KEY=0x… node dist/index.js
# or: AGENTSEARCH_BASE_URL=https://your-agentsearch-host.example node dist/index.js
# process waits on stdin — Ctrl+C to stop

With neither set, the server still starts: the review tools work and the search/extract/render tools return setup instructions.

To fund the wallet, send a little USDC on Base (for example $1, enough for 200 calls) to its address. No ETH is needed: the x402 facilitator pays gas.


License

MIT

Available Tools

2 tools
agentsearch_extractAgentSearch ExtractA

Extract page content from a URL via AgentSearch POST /v1/extract (direct mode only).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute URL to extract
formatsNoOptional formats, e.g. ["markdown","text"]
max_charsNoOptional max characters to return

TDQS

A3.5/5.0
Behavior3/5

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 states the core behavior (extracting page content) and the mode constraint ('direct mode only'), which implies a non-destructive read operation. However, it does not mention return format, error behavior, rate limits, or any side effects. The added endpoint detail and mode restriction provide some value beyond the schema.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that states the purpose, the endpoint, and a key mode constraint. Every word earns its place, with no filler or repetition. It is appropriately sized for a simple extraction tool.

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

Completeness3/5

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

For a tool with three well-documented parameters and a clear purpose, the description plus schema is nearly sufficient to call it correctly. However, the lack of usage guidance and behavioral details (e.g., what the response looks like, default output format) leaves some gaps, especially since there is no output schema. The description is adequate but not complete for an agent facing a choice between this and its sibling.

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?

Schema coverage is 100%, so the parameters url, formats, and max_chars are fully described in the schema. The description adds no extra meaning about parameter usage, defaults, or interactions. Per the rubric, the baseline of 3 applies because the schema handles parameter documentation.

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?

The description clearly states the action ('Extract page content from a URL') and the specific resource (AgentSearch POST /v1/extract). It is inherently distinct from the sibling tool agentsearch_web_search, as one retrieves content from a specific URL while the other searches. The mention of 'direct mode only' adds further specificity.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus agentsearch_web_search. The description does not state when extraction is preferred over search, nor does it mention any exclusions or prerequisites. The only hint is 'direct mode only', which is a mode constraint, not a usage guideline.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedagentsearch_extract
    • First observedagentsearch_web_search

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one performs web searches, the other extracts page content from a given URL. There is no ambiguity about which tool to use for a given task.

Naming Consistency4/5

Both tools share the 'agentsearch_' prefix and use snake_case, but 'web_search' follows a verb_noun pattern while 'extract' is a bare verb. This is a minor inconsistency that does not cause confusion.

Tool Count3/5

With only two tools, the server feels thin for a typical MCP service, but the scope is narrow—web search and extraction—so the count is borderline rather than inappropriate. It sits just below the typical 3-15 tool range.

Completeness5/5

The tool surface covers the two core operations of the domain: searching the web and extracting content from a result URL. There are no obvious dead ends or missing operations given the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A local stdio MCP server that exposes xAI-compatible server-side search through a Responses API relay, providing web and X search tools with citation and cost reporting.
    24 npm
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    Remote MCP connector for AgentSearch API that exposes web search, instant answers, and URL-to-clean-text fetching as typed MCP tools for agents and RAG pipelines.
    -
  • A
    license
    A
    quality
    A
    maintenance
    Enables AI agents to run local deep-research workflows via a single MCP stdio server, combining web search, page extraction, query-aware distillation, and caching without cloud quotas. It exposes tools for deep research, search, and single or batch URL reading.
    6
    MIT