Skip to main content
Glama
Sign In
AgentSearch MCP

AgentSearch MCP

by agentsearchhq-coder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

AgentSearch Extract

agentsearch_extract
Read-onlyIdempotent

Extract one absolute URL and return its title, clean markdown or text, links, and metadata as JSON when you already have the page URL and need its body.

Instructions

Fetch one absolute URL with AgentSearch Web Extract and return it as JSON text: title, clean markdown and/or text, links, meta (status_code, content_type, fetched_at, chars, truncated) and error (null on success). Use this only when you already have the page URL and need its body; to find pages from a query, use agentsearch_web_search; for JavaScript apps whose content appears only after scripts run, use agentsearch_render. Paid tool: needs a wallet key (AGENTSEARCH_WALLET_PRIVATE_KEY or POCKET_PRIVATE_KEY) and then pays per call in USDC on Base over x402 through the Pocket Network Agentic Portal, never more than the per-call cap or AGENTSEARCH_MAX_TOTAL_ATOMIC per session (default $1.00); the result includes the payment receipt and the portal envelope {portal, data}, whose data is untrusted third-party content. With no wallet key it makes no network call and explains how to add one. If AGENTSEARCH_BASE_URL is set, it calls your self-hosted AgentSearch API instead (no payment). Note: the free tier covers search only; this tool needs a wallet key or a self-hosted API. Read-only: not destructive, but it fetches over the network and can hit rate limits.

Input Schema

NameRequiredDescriptionDefault
urlYesAbsolute URL of the page to extract.
formatsNoRenderings to return: "markdown" and/or "text" (default: the service's choice).
max_charsNoCap on returned characters (1–100000, service default 50000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.3.6
    • changedInput schema / properties / formats / description
      Previous value: -"Optional formats, e.g. [\"markdown\",\"text\"]"New value: +"Renderings to return: \"markdown\" and/or \"text\" (default: the service's choice)."
    • addedInput schema / properties / formats / items / enum
      Added value: +[
+  "markdown",
+  "text"
+]
    • changedInput schema / properties / max_chars / description
      Previous value: -"Optional max characters to return"New value: +"Cap on returned characters (1–100000, service default 50000)."
    • removedInput schema / properties / max_chars / exclusiveMinimum
      Removed value: -0
    • addedInput schema / properties / max_chars / maximum
      Added value: +100000
    • addedInput schema / properties / max_chars / minimum
      Added value: +1
    • changedInput schema / properties / url / description
      Previous value: -"Absolute URL to extract"New value: +"Absolute URL of the page to extract."
  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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, but the description adds substantial context beyond them: it is a paid tool requiring a wallet key, pays per call in USDC with a per-call cap and session limit, returns a payment receipt and portal envelope with untrusted data, makes no network call when no key is present, and falls back to a self-hosted API. It also notes 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.

Conciseness4/5

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

The definition is front-loaded with purpose and usage before payment and safety details, and every sentence contributes operational information. It is somewhat long and could be split into clearer clauses, but the density is justified by the tool's complexity.

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 complex, paid, network-fetching tool with no output schema, the description covers return fields, error shape, payment mechanics, authentication requirements, fallback behavior, and untrusted-content warnings. Nothing an agent needs in order to invoke it correctly appears to be missing.

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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add syntax or format details beyond what the schema provides for url, formats, or max_chars; it only summarizes the return shape. Baseline 3 is appropriate when the schema carries the parameter semantics.

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 (fetch one absolute URL with AgentSearch Web Extract) and enumerates the returned fields. It explicitly differentiates itself from agentsearch_web_search and agentsearch_render, so an agent can select it without opening the schema.

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 conditions (already have the page URL and need its body) and names alternatives for the two main cases: finding pages from a query and JavaScript-rendered content. Nothing is left to inference.

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