Skip to main content
Glama
agentsearchhq-coder

AgentSearch MCP

by agentsearchhq-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

agentsearch-mcp

MCP (Model Context Protocol) server that exposes AgentSearch web search — and optional URL extract — to Cursor, Claude Desktop, and other MCP hosts over stdio.

AgentSearch is a web-search API aimed at agents. You can run it against a local/self-hosted AgentSearch instance (direct mode) or the Pocket Network agent portal (portal mode).

  • Portal search endpoint (reference):
    POST https://agent.pocket.network/v1/agentsearch-web-search-v1/v1/search
    body: { "query": "...", "max_results": 5 }

  • Direct search: POST {AGENTSEARCH_BASE_URL}/v1/search with the same body

  • Direct extract: POST {AGENTSEARCH_BASE_URL}/v1/extract

Pocket explorer: agentsearch-web-search-v1

Discovery: This package is free to list and use. There is no paid promotion channel — discovery comes from MCP Registry / Smithery / Glama listings and real usage.

Tools

Tool

Args

Description

agentsearch_web_search

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

Web search in direct or portal mode. 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 (string[], optional), max_chars (positive integer, optional)

Page extract via POST /v1/extract. Direct mode only — portal fails before any request. Use when you already have a URL. Read-only HTTP.

On portal HTTP 402, the search tool returns a clear MCP error that x402 payment is required (or switch to AGENTSEARCH_MODE=direct). In portal mode, agentsearch_extract does not call the network; it returns an MCP error telling you to switch to direct mode or use search.

Related MCP server: Grok Search MCP

Requirements

  • Node.js 20+

  • An AgentSearch backend for direct mode (default http://127.0.0.1:8000), or portal access for portal mode

Install & build

cd agentsearch-mcp
npm install
npm run build

Scripts: build → tsc, start → node dist/index.js, prepare → runs build (for publish).

Binary: agentsearch-mcp → dist/index.js

Environment variables

Variable

Default

Notes

AGENTSEARCH_MODE

direct

direct | portal

AGENTSEARCH_BASE_URL

http://127.0.0.1:8000

Direct mode base URL (no trailing slash)

AGENTSEARCH_API_KEY

(empty)

Optional Authorization: Bearer … for direct; on 401 the client retries once without the key

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

Cursor mcp.json

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

{
  "mcpServers": {
    "agentsearch": {
      "command": "node",
      "args": [
        "C:/Users/Holla/OneDrive/Desktop/AgentSearch/agentsearch-mcp/dist/index.js"
      ],
      "env": {
        "AGENTSEARCH_MODE": "direct",
        "AGENTSEARCH_BASE_URL": "http://127.0.0.1:8000"
      }
    }
  }
}

After npm install && npm run build, optionally use the bin:

{
  "mcpServers": {
    "agentsearch": {
      "command": "npx",
      "args": ["-y", "agentsearch-mcp"],
      "env": {
        "AGENTSEARCH_MODE": "direct",
        "AGENTSEARCH_BASE_URL": "http://127.0.0.1:8000"
      }
    }
  }
}

(Local path form is recommended until the package is published to npm.)

Optional API key (direct only):

"env": {
  "AGENTSEARCH_MODE": "direct",
  "AGENTSEARCH_BASE_URL": "http://127.0.0.1:8000",
  "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": "node",
      "args": [
        "C:/Users/Holla/OneDrive/Desktop/AgentSearch/agentsearch-mcp/dist/index.js"
      ],
      "env": {
        "AGENTSEARCH_MODE": "direct",
        "AGENTSEARCH_BASE_URL": "http://127.0.0.1:8000"
      }
    }
  }
}

Restart Claude Desktop after saving.

Local run (smoke)

npm run build
# MCP hosts spawn the process; for a quick boot check:
node dist/index.js
# (process waits on stdin — Ctrl+C to stop)

Publish (high level)

No paid promo — list the package so tools can discover it via registries and usage.

npm

  1. npm login

  2. Confirm name / version in package.json

  3. npm publish --access public (ensure prepare/build succeed; no secrets in the tarball)

MCP Registry

  1. Ensure server.json matches your npm package + stdio transport

  2. Follow the MCP Registry publish flow (authenticate publisher, submit server metadata)

  3. Verify the listing resolves agentsearch-mcp / stdio

Smithery

Publish with the durable helper (preferred):

npm run smithery:publish

That runs scripts/publish-smithery.mjs, which ensures agentsearch-mcp.mcpb exists (npm run mcpb:pack if missing), idempotently patches the global Smithery CLI so the deploy payload always includes a tool inputSchema object when the MCPB omitted it, then runs smithery mcp publish ./agentsearch-mcp.mcpb -n agentsearchhq/agentsearch-mcp.

MCPB note: manifest.json must omit tool inputSchema — mcpb validate rejects it. The publish helper patches the CLI payload side instead.

Manual equivalent (after CLI is patched):

npm run mcpb:pack
smithery mcp publish ./agentsearch-mcp.mcpb -n agentsearchhq/agentsearch-mcp

npm run mcpb:pack compiles TypeScript to dist/index.js, installs production dependencies, then writes agentsearch-mcp.mcpb. Check the manifest with npm run mcpb:validate. manifest.json (MCPB 0.3) launches node ${__dirname}/dist/index.js and maps optional AGENTSEARCH_MODE (default direct), AGENTSEARCH_BASE_URL (default http://127.0.0.1:8000), and sensitive AGENTSEARCH_API_KEY. smithery.yaml remains as start-command metadata. Dry-run patch detection only: node scripts/publish-smithery.mjs --dry-patch.

Glama

  1. Submit the GitHub (or npm) package to Glama MCP directory

  2. Link README + tools list; keep env docs in sync

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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

Resources

Related MCP Connectors

Related MCP Servers

  • open-search-mcp

    rockindahizzy
    A
    license
    Not graded
    quality
    D
    maintenance
    Web search, page fetching, and research from the terminal or any MCP client — no API key required.
    1
    MIT

  • Grok Search MCP

    Hello-Lv-tu
    A
    license
    Not graded
    quality
    B
    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.
    20 npm
    MIT

  • agentsearch-mcp

    IsaiahDupree
    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.
    -

  • bathys

    Korrnals
    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