Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@x402-money-farm extract the main article text from https://example.com/blog/post"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Paid web-extraction tools for agents. No account, no API key, no subscription, no signup form: each call settles a fraction of a cent in USDC on Base, per request, and the response arrives only after settlement.
Tool | What it returns | Price |
| Everything below, with live prices and wallet status | free |
| Main article text without nav/ads/boilerplate, text or Markdown | $0.02 |
| Title, description, canonical, OpenGraph, Twitter, icons, dates | $0.01 |
| All links, absolutised, deduplicated, internal/external, per-host counts | $0.01 |
| JSON-LD blocks parsed and indexed by schema.org type | $0.01 |
| Noise-normalised page fingerprint plus a changed/unchanged verdict | $0.015 |
Claude Desktop — claude_desktop_config.json:
{
"mcpServers": {
"x402-money-farm": {
"command": "npx",
"args": ["-y", "x402-money-farm-mcp"],
"env": {
"X402_PRIVATE_KEY": "0xyour_funded_base_wallet_key",
"X402_MAX_USD": "1.00"
}
}
}
}Claude Code:
claude mcp add x402-money-farm \
--env X402_PRIVATE_KEY=0x... \
--env X402_MAX_USD=1.00 \
-- npx -y x402-money-farm-mcpAny other MCP client works the same way — it is a plain stdio server.
Related MCP server: navi-x402-mcp
npx -y x402-money-farm-mcpThen have the agent call farm_catalog. It reports the live prices, whether a
wallet is configured and how much has been spent this session. Nothing is
billed, and no wallet is needed to see it. If the prices do not suit you, you
learned that for free.
The server pays from your wallet, one call at a time. Gas is paid by the facilitator, so the wallet needs USDC on Base but no ETH.
Variable | Default | Meaning |
| — | Your funded Base wallet, |
|
| Hard spend cap for the process. Once reached, every further paid call is refused. |
|
| The service to buy from. |
|
| Base mainnet. |
Fund a wallet for this purpose with a few dollars — not your main one. The key sits in a config file on disk; treat it accordingly. The spend cap exists so a looping agent cannot drain even that wallet.
The price in the table is the whole price. No monthly minimum, no per-seat fee,
no metered surprise. The server returns HTTP 402 with the exact amount, your
wallet signs that amount, and you get the answer after settlement. A failed
call is not billed. Every response carries a _payment block with the amount,
the running session total and the paying address, so you can reconcile against
the chain yourself.
Because the alternative is a signup, a credit card, a minimum plan and a key to rotate — for an agent that wanted the metadata of four URLs. Here the agent decides on its own, pays four cents, and nobody had to create an account.
MIT.
List every tool this service offers, its price and its input schema, and report whether a wallet is configured in this session. Free — no payment required. Call this before paying for anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 usefully adds that the call is free with no payment required and that it reports wallet configuration status. However, it doesn't explicitly state that the operation has no side effects, and without an output schema it doesn't describe the return structure beyond content items.
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?
Three short sentences deliver the full function, the cost, and the recommended call timing in order of importance. The only redundancy is 'Free — no payment required' repeating the title's '(free)', but it reinforces a decision-relevant fact and earns its place.
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?
For a complexity of zero parameters, no output schema, and no annotations, the description is nearly complete: it defines the result content (tools, prices, schemas, wallet status) and gives the key routing instruction. The only missing piece is the exact return format, which is a minor gap for a no-argument listing call.
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 tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description correctly reflects this by referring to a single implicit input (the session) and focusing on what the call returns rather than argument handling.
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 names a specific verb ('List') and a precise resource ('every tool this service offers'), and enumerates exactly what is returned: price, input schema, and wallet status. This clearly distinguishes it from sibling content-processing tools like farm_clean_text and farm_jsonld, which have entirely 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?
'Call this before paying for anything' is explicit, actionable timing guidance that tells an agent exactly when this tool is the right choice. No when-not-to-use or alternative routing is given, but none of the siblings are remotely similar to a catalog function, so no contrast is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page and return the main article text without navigation, ads or boilerplate, as plain text or Markdown, with title, language and word count. Use this to feed a page into a model or a RAG index. Costs $0.02 per call, paid in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL of the page to process. | |
| format | No | Output format. Default text. | |
| max_chars | No | Truncate to N characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses output contents (title, language, word count) and the $0.02 USDC cost, but it does not mention failure modes, handling of non-article pages, JavaScript-dependent pages, rate limits, or response format details.
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?
Three short sentences, each earning its place: behavior and output, use case, and cost. It is front-loaded with the core action and contains no filler.
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?
For a tool with three parameters and no output schema, the description covers the essential calling context: what it returns, how it can be formatted, why to use it, and the financial cost. It could be more complete by describing the exact return shape, but it is still sufficient for correct invocation.
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%, so the baseline is 3. The description reinforces the 'text or Markdown' format choice and the notion of truncated output, but it does not add meaning beyond the schema's already-clear parameter descriptions.
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 gives a specific verb and resource: 'Fetch a web page and return the main article text without navigation, ads or boilerplate.' This clearly differentiates it from sibling tools like farm_metadata or farm_jsonld by emphasizing cleaned body text, though it does not explicitly name or contrast those siblings.
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 states a clear intended use: 'Use this to feed a page into a model or a RAG index.' This gives an agent a concrete signal for when to select this tool, but it does not mention when not to use it or suggest an alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A stable fingerprint of a page that ignores noise like timestamps and session ids, plus a verdict on whether it changed since a previous fingerprint. Use this to watch a page without storing or diffing its HTML yourself. Costs $0.015 per call, paid in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL of the page to process. | |
| previous | No | Previous digest to compare against. | |
| selector | No | CSS selector to scope the fingerprint to one region. | |
| ignore_numbers | No | Treat digits as volatile (prices, counters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It usefully reveals that the tool has a cost ('Costs $0.015 per call, paid in USDC on Base') and that it normalizes away noise such as timestamps and session ids. It does not detail output structure or edge cases, but it covers the most important operational 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 three short sentences with no redundant wording. It front-loads the core purpose, then gives the usage scenario, then the cost note. Every sentence earns its place.
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?
For a tool with no output schema and no annotations, the description gives enough context to decide when to call it and what behavior to expect. The parameter meanings are fully covered by the schema, and the description supplies the missing operational context: cost, payment method, and the 'watch a page' use case. A full return-shape description would improve completeness, but it is not essential for selecting and invoking the 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 description coverage is 100%, so the baseline applies. The description adds some context by explaining that the fingerprint ignores noise like timestamps and session ids, which relates to ignore_numbers, but it does not materially extend what the schema already says about url, previous, selector, or ignore_numbers.
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 a specific verb and resource: it produces a stable fingerprint of a page and a change verdict, while ignoring noisy data like timestamps and session ids. This distinguishes it from sibling tools like farm_metadata or farm_links, which clearly serve different extraction 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?
The description gives an explicit use case: 'Use this to watch a page without storing or diffing its HTML yourself.' This tells an agent when to choose the tool, though it does not explicitly name sibling alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All JSON-LD blocks on a page, parsed and indexed by schema.org type, with an optional type filter and a microdata fallback. Use this to read product, price, article or event data without writing a scraper. Costs $0.01 per call, paid in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL of the page to process. | |
| type | No | Return only nodes of this @type, e.g. Product. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses parsing/indexing behavior, optional type filtering, microdata fallback, and the $0.01/USDC cost. It does not mention failure behavior, response structure, rate limits, or authentication expectations, but it is not misleading or contradictory.
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 compact and front-loaded with the core behavior, followed by a one-sentence use case and a brief cost note. Every sentence earns its place; no filler or redundant restating of the tool name.
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?
For a simple two-parameter extraction tool with no output schema, the description gives enough context to understand the scope, filter behavior, fallback, and cost. It could add a note about the returned data shape, but the low parameter complexity and clear use cases make it sufficiently complete.
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%, so the schema already fully documents both url and type. The description's 'optional type filter' adds no new semantic detail beyond what the schema provides, so the baseline of 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 states exactly what the tool does: it extracts all JSON-LD blocks from a page, parses them, indexes them by schema.org type, supports an optional type filter, and falls back to microdata. This clearly distinguishes it from sibling tools like farm_metadata and farm_links by naming JSON-LD/structured data as the specific resource.
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 gives clear use cases: 'read product, price, article or event data without writing a scraper.' However, it does not explicitly say when not to use this tool or name an alternative for other metadata/extraction needs, so it stops short of a full when/when-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every link on a page, made absolute and deduplicated, split into internal and external, with anchor text, rel attributes and per-host counts. Use this to crawl, to map a site, or to find outbound references. Costs $0.01 per call, paid in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL of the page to process. | |
| limit | No | ||
| scope | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does well: it reveals the per-call cost and payment token, and describes the transformation behavior and output fields. It does not mention auth requirements, rate limits, or failure behavior, which are meaningful gaps for a paid external-fetching 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?
Three sentences, each carrying distinct information: output shape, use cases, and cost. The description is front-loaded with the most important detail and contains 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?
The tool has no output schema and no annotations, and two of three parameters are undocumented. The description omits limit/scope semantics, response envelope, and edge-case behavior, so an agent cannot fully anticipate the result of a call. The cost and output-feature details are valuable, but not sufficient for complete invocation confidence.
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 only 33%, so the description must compensate for limit and scope being undocumented. 'Split into internal and external' loosely hints at scope, but it does not explain scope values, defaults, or the meaning of limit. The description therefore fails to close the parameter documentation gap.
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 specifies what the tool returns—every link, absolute, deduplicated, internal/external split, anchor text, rel attributes, and per-host counts—which unambiguously identifies this as a link-extraction tool. It is distinguishable from siblings like farm_metadata and farm_clean_text. It lacks an explicit imperative verb like 'extracts', but the meaning is unmistakable.
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 explicitly states when to use it: 'Use this to crawl, to map a site, or to find outbound references.' This gives an agent concrete use-case signals for selecting it. It does not mention alternative tools or provide negative guidance, so it stops short of full when-not-to-use coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalised metadata for a web page: title, description, canonical URL, OpenGraph and Twitter card fields, icons, language, robots directives, author and dates. Use this for link previews, deduplication or classifying a URL. Costs $0.01 per call, paid in USDC on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL of the page to process. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses a cost behavior ('Costs $0.01 per call, paid in USDC on Base') which is valuable. However, it does not mention authentication requirements, rate limits, failure modes, or explicitly confirm that it only reads data and does not modify anything. The cost and normalization hint are useful but incomplete.
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 three sentences with every sentence earning its place: the first lists the output fields, the second gives use cases, and the third states cost. It is front-loaded with the core purpose and contains 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?
For a simple one-parameter tool with no output schema, the description is quite complete. It lists the exact fields the agent can expect (title, description, canonical URL, OpenGraph, etc.), covers use cases, and discloses cost. It does not describe error behavior or output serialization, but given the low complexity, these are minor gaps that do not prevent correct invocation.
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% – the only parameter 'url' is described as 'Absolute http(s) URL of the page to process.' The description adds no extra parameter-level guidance beyond the schema; it mentions web page metadata but does not elaborate on URL edge cases or formats. The baseline of 3 applies because the schema already documents the parameter fully.
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 states exactly what the tool does: 'Normalised metadata for a web page: title, description, canonical URL, OpenGraph and Twitter card fields, icons, language, robots directives, author and dates.' It enumerates the specific resources it retrieves, which clearly distinguishes it from siblings like farm_links (links only) and farm_jsonld (JSON-LD only). The purpose is unambiguous and immediately actionable.
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 provides explicit use cases: 'Use this for link previews, deduplication or classifying a URL.' This gives clear context for when to invoke the tool. However, it does not name sibling alternatives or state conditions for when NOT to use it, so it stops short of the full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1farm_catalogfarm_clean_textfarm_fingerprintfarm_jsonldfarm_linksfarm_metadataScored across 6 tools
Each tool targets a clearly distinct extraction task: text, metadata, links, JSON-LD, fingerprint, and service catalog. Descriptions clearly separate concepts like HTML metadata vs JSON-LD structured data, so an agent can reliably choose the right tool.
All tools follow a uniform farm_ prefix with lowercase snake_case names, and each suffix describes the output type. This predictable naming pattern makes the toolset easy to navigate.
Six tools is a well-scoped set for a paid web extraction API; every tool provides a unique function and none feel redundant. The catalog tool earns its place by exposing pricing and schemas for the paid operations.
The surface covers core extraction needs: main text, metadata, links, structured JSON-LD, and change detection, with few dead ends for typical workflows. Minor gaps such as raw HTML fetching or arbitrary selector extraction are not offered, but the stated purpose is handled well.
Web search and URL-to-markdown for agents. Pay per call in USDC on Base, no signup.
Pay-per-call web scraping for AI agents via x402 on Base USDC. Six tools, no signup.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
