Skip to main content
Glama
Sign In
AgentSearch MCP

AgentSearch MCP

by agentsearchhq-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

AgentSearch Web Search

agentsearch_web_search
Read-onlyIdempotent

Search the web for a query and return up to five result hits as pretty-printed JSON. Use it when you need search results rather than page content; for an existing URL, use extraction instead.

Instructions

Search the web with AgentSearch and return the response as pretty-printed JSON text. Use this when you have a query and need hits rather than a page body; if you already have a URL, use agentsearch_extract instead (or agentsearch_render for JavaScript-heavy pages). Free by default: with no configuration it uses the AgentSearch free tier (up to 25 searches/day per IP, subject to shared daily capacity, no payment), even if a wallet key is set for Extract/Render. Only if the operator sets AGENTSEARCH_MODE=paid does it pay $0.005 per call in USDC on Base over x402 through the Pocket Network Agentic Portal instead (never more than the per-call cap or AGENTSEARCH_MAX_TOTAL_ATOMIC per session, default $1.00); paid results include the payment receipt and the portal envelope {portal, data}, whose data is untrusted third-party content. If AGENTSEARCH_BASE_URL is set, it calls your self-hosted AgentSearch API instead (no payment). Read-only: not destructive, but it uses the network and can hit rate limits (on the free tier, a 429 means the daily limit was reached; the error says how to upgrade). Integers for max_results outside 1–5 are clamped (default 5), not rejected.

Input Schema

NameRequiredDescriptionDefault
queryYesKeywords or a natural-language question to search for.
max_resultsNoHow many hits to request (1–5, default 5). Values outside that range are clamped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.3.6
    • changedInput schema / properties / max_results / description
      Previous value: -"Max results to return (1–10, default 5)"New value: +"How many hits to request (1–5, default 5). Values outside that range are clamped."
    • changedInput schema / properties / query / description
      Previous value: -"Search query string"New value: +"Keywords or a natural-language question to search for."
  2. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses free-tier limits (25 searches/day per IP), paid-mode pricing and caps, self-hosted behavior, rate-limit semantics for 429 responses, payment receipt/envelope handling, and that paid portal data is untrusted third-party content. These are substantive operational details not captured by readOnlyHint, openWorldHint, idempotentHint, or destructiveHint.

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?

The description is front-loaded with purpose and usage guidance before moving into operational and payment details. It is dense and somewhat lengthy for a two-parameter search tool, but the length is largely justified by the behavioral transparency it provides.

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

Completeness5/5

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

For a tool with no output schema, the description explains the return format, paid-mode envelope, payment receipt inclusion, and operational failure behavior. It is complete enough for an agent to understand both how to call the tool and what to expect from the response.

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 both parameters are already documented in the input schema. The description repeats the max_results clamping behavior and default, but adds little semantic detail beyond the schema's own parameter descriptions.

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 states a specific verb and resource: 'Search the web with AgentSearch' and return pretty-printed JSON. It also explicitly distinguishes this tool from URL-based siblings by directing agents to agentsearch_extract or agentsearch_render when a URL is already available.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: use this when you have a query and need hits rather than a page body. It also names alternatives and their conditions, including agentsearch_extract for existing URLs and agentsearch_render for JavaScript-heavy pages.

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

Deploy Server

Other Tools