DEV Community: whiteknightonhorse

What Happens to the $0.001 When an AI Agent Pays for an API Call

whiteknightonhorse — Tue, 19 May 2026 04:56:58 +0000

An AI agent pays $0.001 in USDC for one API call. What actually happens to that money? The honest answer involves gas fees, upstream provider charges, a database write, and the smallest margin you've ever seen.

I run a pay-per-call API gateway with 618 tools across 191 providers. Every paid call settles on Base mainnet via x402. Here is the actual journey of one penny — broken down with numbers from production.

Why this matters in 2026

The "pay per call" business model for AI agent tools is finally real. Two things made it possible: the x402 protocol gave agents a standard way to send payments inside an HTTP 402 response, and stablecoin settlement on Base mainnet made the gas cost low enough that a $0.001 call is not absurd.

But the math is tighter than you'd think. Anyone who tells you "just charge $0.001 per call and you'll be rich" has not actually looked at where the money goes. Let me walk you through it.

The four buckets of $0.001

When an agent sends a $0.001 (1000 microUSDC) payment for a standard read-tier tool, the money lands in roughly four places:

Bucket	Typical share	Why
Base mainnet gas	$0.0003–$0.0008	Submitting `transferWithAuthorization` on-chain
Upstream API cost	$0.0000–$0.0005	What the underlying provider charges (often $0 for free-tier APIs)
Gateway compute	~$0.00005	Postgres + Redis + viem + Pino logs for one request
Margin	the rest	Whatever survives the above

Base mainnet finality is fast (~1–3 seconds) and gas is cheap, but it is not zero. Submitting a single transferWithAuthorization call against the USDC contract on Base costs roughly 50,000 gas units. At a typical Base gas price of 0.01 gwei and ETH at $3,000, that is 50000 × 0.01 × 10^-9 × 3000 ≈ $0.0015. Sometimes more, sometimes less.

If gas spikes during a Base congestion event, a single settle can cost $0.005. At that moment, your "comfortable" $0.001 price tier is operating at a loss until gas calms down. This is why margin discipline matters.

The five pricing tiers (with real tools)

We don't use a flat $0.001 across all tools. Different upstream costs and different data volumes demand tiered pricing. Here is the actual distribution across our 618 tools:

Tier	Price range	Tool count	Example tools
Free	$0.000	7	Some platform metadata endpoints
Low	$0.0005–$0.0011	346	Most reads — crypto, weather, jobs
Mid	$0.002–$0.005	119	Heavier reads, AI inference
High	$0.005–$0.10	30	OCR, image gen, paid upstreams
Premium	$0.10+	5	SMS sends, domain registrations

The min price we charge is $0.0005 (Polymarket read endpoints — high volume, low upstream cost, low gas overhead per settle when batched). The max is $29.99 for an AIPush market report (heavy LLM work upstream, multi-hour generation) or $21.00 for a domain registration through NameSilo (passes the actual domain price through with thin margin).

That's a 60,000× range from cheapest to most expensive. The same payment rail handles all of them.

The cache-hit shortcut

Roughly 25–40% of incoming requests in our pipeline are cache hits. We don't call the upstream for those — Redis already has the answer.

The business question: should a cache-hit cost the same as a fresh call?

We charge 10% of the full price for a cache hit. Here's why:

// src/pipeline/stages/ledger-write.stage.ts
const CACHE_HIT_COST_MULTIPLIER = 0.1;

if (ctx.cacheHit) {
  const chargeAmount = ctx.toolPrice * CACHE_HIT_COST_MULTIPLIER;
  await writeDirectCharge(ctx.agentId, chargeAmount);
  return ok(ctx);
}

For a $0.001 tool, cache-hit billing is $0.0001. That sounds tiny, but the math is:

We skip ESCROW (no $0.0005 gas for full settle — cache hits go through balance debit, not on-chain settle)
We skip the upstream provider call (no cost at all)
We do one Redis read + one Postgres write
Net cost to us: roughly $0.00001

So the agent saves 90%, we still net ~$0.00009 margin per cache hit. Volume is the multiplier — at 25K cache hits per day, that's $2.25/day from cache hits alone. Not a fortune, but it pays for the Redis container.

When the call fails

Refund math is where most pay-per-call systems break. The naive design — "take the money first, fail later, manually refund" — gets you a class-action lawsuit.

Our model: every paid request reserves USDC at ESCROW stage, before the provider call. Then:

Outcome	What happens to the reserved USDC
Provider returns 200	Finalize escrow → mark PAID in ledger → 1 PG transaction
Provider returns 5xx	Refund escrow → mark REFUNDED → 1 PG transaction
Provider times out (10s)	Refund (same path)
Pipeline crashes mid-call	Reconciliation job sweeps within 60-120s → refund
Agent retries with same Idempotency-Key	We don't charge twice — idempotent at PG level

The escrow + finalize is one atomic PG transaction — either both succeed or both roll back. No partial state, no orphaned escrows. The reconciliation job is a fail-safe for the unhappy path where the API process crashes between reserve and finalize.

For the agent this means: you only pay for what worked. A 5xx from the upstream doesn't cost you anything. This is the single biggest reason agents trust pay-per-call gateways — the alternative ("we charged your card, sorry the API is down") is the SaaS pricing model that AI agent developers are actively trying to escape.

A worked example: agent calls finnhub.quote for AAPL

Let's trace one real request end-to-end. Tool: finnhub.quote, price: $0.001, cache miss (first call this minute).

curl -X POST https://apibase.pro/api/v1/tools/finnhub.quote/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "X-Payment: eyJ4NDAyVmVyc2lvbiI..." \
  -H "Content-Type: application/json" \
  -d '{"symbol": "AAPL"}'

The 13-stage pipeline runs:

AUTH          (Redis lookup, ~1ms)
IDEMPOTENCY   (Redis check + set, ~1ms)
CONTENT_NEG   (header parse, <0.1ms)
SCHEMA_VALID  (Zod parse, <1ms)
TOOL_STATUS   (in-memory cache hit, <0.1ms)
CACHE_CHECK   (Redis lookup, ~1ms)  ← miss, continue
RATE_LIMIT    (Redis dual-bucket, ~1ms)
ESCROW        (PG reserve 1000 microUSDC, ~3ms)
PROVIDER_CALL (Finnhub API, ~200ms)  ← real cost
ESCROW_FINAL  (PG finalize, ~3ms)
LEDGER_WRITE  (PG insert, ~2ms)  ← x402 settle queued
CACHE_SET     (Redis write, ~1ms)
RESPONSE      (JSON serialize, <1ms)

Total: ~213ms for the agent. After the response is sent, our facilitator submits the on-chain settle (~1-3 seconds, async — doesn't block the agent).

The income/expense for this one call:

Revenue: $0.001 USDC from agent
Upstream cost: $0 (Finnhub free tier covers our volume)
On-chain gas: $0.00045 (50K gas × 0.01 gwei × $3000/ETH)
Compute: ~$0.00005 (CPU + Redis + PG amortized)
Net margin: $0.0005 per call

Half a cent. The whole business has to scale on that.

How the math actually works at scale

At our current volume of ~26K x402 settles per month, the gross margin per settle is roughly $0.0005. That's $13/month in gross margin just from x402-paid calls. Not a lot.

The trick is volume × tier mix. The 119 mid-tier tools ($0.002–$0.005 price) and the 35 high-tier tools ($0.005+) have proportionally higher margins. A $0.005 OCR call has $0.004 of margin after upstream + gas. One of those covers the gas for ten $0.001 reads.

The economics flip from "barely profitable" to "comfortable" once you hit ~50K settles/month, because:

Fixed gas cost per settle stays constant (it's an externality, not our cost basis)
Per-request compute amortizes across a bigger denominator
Cache hit ratio improves with traffic (more requests → better cache locality)
Tier mix stabilizes (early users skew toward "I want to try it" cheap tools; later users skew toward production workloads on expensive tools)

This is why pay-per-call pricing models tend to look unprofitable at the start and then suddenly work once volume crosses a threshold. The thresholds for our gateway, today, look like:

Monthly settles	Status
< 5K	Operating at a loss after operator wallet top-up
5K–25K	Breakeven, no growth
25K–100K	Modest profit, infrastructure paid for
100K+	Real margin, can fund new provider integrations

What I learned

Three things, in order of how much they surprised me:

Gas is the dominant cost line for cheap tools. I assumed compute would be the biggest cost; it's actually the on-chain settlement. This means optimizing the database is less impactful than optimizing the settle path. We've since moved to self-hosted facilitator (cuts out third-party SaaS fees on top of gas) and we batch where the protocol allows.
Cache hits subsidize the cheap tiers. The 10% cache-hit billing is what makes the $0.0005 tier viable. Without it, polymarket read tools would lose money per call. With it, they net $0.00009 per cache hit and break even on cache misses — and 25-40% of requests are cache hits.
Refund math is a feature, not a cost center. Every refund we issue (5xx, timeout, agent cancellation) costs us the gas we already burned on the failed settle attempt. But the agent's confidence in the system — "I only pay for what worked" — is what makes them set up automated workflows that drive volume. The refund overhead is a fixed cost of doing pay-per-call business, and it's worth it.

Try it yourself

If you want to see this in action without writing any code:

# 1. Get an API key (auto-registration, no signup)
curl -X POST https://apibase.pro/api/v1/agents/register \
  -H "Content-Type: application/json" \
  -d '{"agent_name": "experiment", "agent_version": "1.0.0"}'

# 2. Try a free-tier call (no payment needed for free tools)
curl -X POST https://apibase.pro/api/v1/tools/iss.position/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "Content-Type: application/json" \
  -d '{}'

# 3. Try a paid tool — you'll get a 402 with the exact payment details
curl -X POST https://apibase.pro/api/v1/tools/finnhub.quote/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "Content-Type: application/json" \
  -d '{"symbol": "AAPL"}'
# → HTTP 402 with x402 challenge: pay $0.001 USDC on Base to <address>

The 402 response includes everything an x402-compatible agent needs to sign and submit the payment. Real agents do this automatically. You can also call it from any MCP-compatible client at https://apibase.pro/mcp.

The full open-source implementation is at github.com/whiteknightonhorse/APIbase. The pricing logic lives in config/tool_provider_config.yaml, the cache-hit math is in src/pipeline/stages/ledger-write.stage.ts, and the escrow + refund cycle is in src/services/escrow.service.ts. Fork it. Steal the ideas. Just don't forget the gas math.

APIbase is a unified MCP gateway with 618 tools across 191 providers, paid per call via x402 USDC on Base or MPP USDC on Tempo. The economics in this article are real production numbers.

How We Replaced Our x402 Payment Facilitator in a Single Afternoon

whiteknightonhorse — Fri, 01 May 2026 07:32:28 +0000

This morning I got an email from Coinbase Developer Platform (CDP):

Your organization has reached the monthly free tier limit for settled x402 payments using the CDP Facilitator. Additional settled payments will require a payment method on file.

Fine. I tried to add a payment method. CDP rejected my KYC documents three times. There is no support channel for KYC issues — just "try again later".

By that point we were already settling roughly 869 x402 payments per day through CDP for our MCP gateway (576 tools, 177 providers, public API at apibase.pro). When the free tier flipped, every paid call would start failing on /settle. Agents would get 5xx, escrow would leak, customer USDC would orphan.

I had two options:

Wait for KYC, lose revenue, hope it resolves.
Replace CDP. Build our own facilitator. Today.

I picked option 2. Here is how it went.

What an x402 facilitator actually does

The x402 protocol standardizes pay-per-call HTTP. The agent (payer) signs an EIP-3009 transferWithAuthorization permit. The merchant verifies the signature and submits the permit on-chain to actually move USDC.

That last part — submitting on-chain — is the facilitator's job. Most x402 services delegate it to a SaaS provider:

Facilitator	Auth	Cost	KYC	Bazaar discovery
CDP (Coinbase)	Ed25519 JWT	Free tier, then unbounded	Required for billing	Yes
PayAI	None	Free	None	No
x402.org	None	Free, testnet-leaning	None	No
Self-hosted	n/a — your own wallet	Base gas (~$0.0005/settle)	None	No

The facilitator role is genuinely simple: hold an EOA with ETH for gas, submit USDC transferWithAuthorization calls. The whole thing is public on-chain. There is no proprietary algorithm. CDP just runs a wallet and an HTTP API around viem (or some equivalent).

So why does anyone pay for a facilitator? Because operating a hot wallet 24/7 with proper monitoring and key handling is annoying and most teams would rather expense it.

That logic flips the moment the SaaS itself becomes the failure mode.

The build: 350 lines of glue

The good news: the @x402/core and @x402/evm SDKs already include a complete in-process facilitator implementation. It just normally lives behind an HTTP layer in CDP/PayAI's infrastructure. Nothing prevents us from running it ourselves.

The whole architecture, top to bottom:

                 x402ResourceServer (SDK, untouched)
                            |
                            v
                 LocalFacilitatorClient (new, ~120 lines)
                  - Redis SETNX lock per operator address
                  - Prometheus metrics
                  - PayAI HTTP fallback on throw
                            |
                            v
                 x402Facilitator (SDK, in-process)
                 + registerExactEvmScheme(signer)
                            |
                            v
                 viem WalletClient + publicActions
                  - operator privkey from .env
                  - Base mainnet, fixed RPC
                  - holds ETH only, never USDC

The viem signer is six lines:

import { createWalletClient, http, publicActions } from 'viem';
import { privateKeyToAccount } from 'viem/accounts';
import { base } from 'viem/chains';

const account = privateKeyToAccount(process.env.X402_OPERATOR_PRIVATE_KEY);
const signer = createWalletClient({
  account,
  chain: base,
  transport: http(rpcUrl, { retryCount: 2, retryDelay: 200 }),
}).extend(publicActions);

The facilitator wiring is four:

import { x402Facilitator } from '@x402/core/facilitator';
import { registerExactEvmScheme } from '@x402/evm/exact/facilitator';

const facilitator = new x402Facilitator();
registerExactEvmScheme(facilitator, { signer, networks: 'eip155:8453' });

That is genuinely the entire payment-settlement layer. The SDK does the EIP-3009 signature verification, builds the calldata, submits via the signer, waits for the receipt. We add three things on top:

A Redis SETNX lock keyed by operator address (TTL 60s). With multiple containers (api + worker) running on the same operator wallet, two concurrent eth_getTransactionCount calls would return the same nonce and the second tx would fail "nonce too low". The lock serializes settle calls cross-container.
Prometheus metrics: x402_local_settle_total{result} counter, x402_local_settle_duration_seconds histogram with result label, x402_operator_eth_balance gauge. Plus alerts at <0.005 ETH balance and >5% error rate.
PayAI HTTP fallback wired transparently inside LocalFacilitatorClient. If our local settle throws (RPC outage, signer drift, anything), the same call automatically retries against PayAI's free public facilitator. Single-RPC blips do not drop revenue.

Two architectural decisions worth explaining:

Operator wallet ≠ receiver wallet. Our receiver address (the one that accumulates USDC revenue) has no private key in the runtime environment. The operator address is a fresh hot wallet that holds only ETH for gas. If the operator key is compromised, the attacker steals unspent gas (~$10), not customer USDC. Compromise of the receiver requires compromising whatever cold custody we use for that address. Keep them separate. Always.

The SDK does not iterate fallback clients automatically. I assumed it did — the existing code I inherited had a comment claiming "if first client throws, tries next." Reading the actual @x402/core/server source disproved this. x402ResourceServer.initialize() populates a (version, network, scheme) → client lookup map, and the FIRST registered client wins. So the fallback semantics had to live inside our LocalFacilitatorClient itself: try local, catch, delegate to a PayAI HTTP client.

Full code in src/payments/local-facilitator.ts.

Three gotchas that cost us seven minutes of 502s

The implementation worked on first try. The deployment is what bit me. Three docker-compose footguns, in order:

1. `docker compose restart` does not re-read `env_file`

I edited .env to set X402_FACILITATOR_MODE=local, then ran docker compose restart api worker. The container came up healthy. Logs showed mode: "remote".

I assumed the env file load was broken. I read it three times. It was correct. Then I ran docker exec apibase-api-1 env | grep X402_FACILITATOR_MODE — empty.

restart does not reload env_file. It just SIGHUPs the existing container, keeping the env vars from the original up. To pick up new values you need docker compose up -d --force-recreate --no-deps api worker.

Documented nowhere prominent. Cost me ~3 minutes.

2. `--force-recreate` does not pull new images

The push to main had triggered a CI build that published a new image to ghcr.io. The image included our new LocalFacilitatorClient code. I assumed --force-recreate would pull it.

It did not. It happily reused the locally cached pre-push image. The container started with mode=local (from the new env), but the actual code was old (no LocalFacilitatorClient). Logs showed CDP being registered as primary.

Fix: docker compose pull api worker before recreate. Or --pull always. Cost: another ~2 minutes of confusion.

3. After `--force-recreate`, the inner nginx caches the old IP

This one was the worst. After recreating api, the new container got a new IP on the internal Docker network. Our edge nginx (apibase-nginx-1) had the old IP cached from its config-load time. Every request to apibase.pro/api/v1/tools returned 502 because nginx kept connecting to a dead IP.

Symptoms: outer health checks pass (200 from static pages), API endpoints all 502, container looks healthy from docker ps, docker exec apibase-nginx-1 wget http://api:3000/health/ready works. Took me a moment to realize nginx was holding 172.18.0.5 from the previous container while the new one was at 172.18.0.7.

Fix: docker exec apibase-nginx-1 nginx -s reload after every recreate. Cost: ~2 minutes of users seeing 502s before I diagnosed it.

I documented all three in our runbook so the next person (or my future self) does not repeat them.

Council Review and auto-fix

Before pushing, I ran our internal /councilreview skill — eight specialized reviewers (Security, Performance, Reliability, API Designer, Domain Expert, Crypto Specialist, DevOps, Observability) each look at the diff independently. They surfaced five MEDIUM findings I had not thought of:

Crypto Specialist: viem http() transport had no retry config. Added { retryCount: 2, retryDelay: 200 } so transient public-RPC blips are absorbed before triggering PayAI fallback.
Reliability Engineer: my Redis lock had a final redis.get(key) !== token check after the SETNX retry loop, which has a tiny race window where the SET succeeds and the TTL expires before the GET. Replaced with a simple in-loop boolean.
Performance Engineer: histogram buckets started at 500ms, masking sub-second optimization wins. Tightened to [0.1, 0.25, 0.5, 1, 2, 5, 10, 30].
Observability Engineer (×2): settle duration histogram had no result label, so I could not distinguish success-latency from fallback-latency. Also added a brand-new x402_operator_lock_wait_seconds histogram so I would see lock contention rising before requests started timing out.

The skill auto-applied all five fixes (with a TS+ESLint+Jest validation gate that would revert everything if any of the three regressed). Took 90 seconds. Six new useful changes, zero work.

Day-0 numbers (with honest framing)

I am writing this an hour after mode=local went live. I genuinely do not know how it will perform under a peak hour, an RPC outage, or a Base fee-market spike yet. What I do know:

~15 settles processed through LocalFacilitatorClient so far
0 errors, 0 fallbacks (Day-0 cherry — does not generalize)
~0.001 ETH spent on gas (~$3)
Operator wallet balance hit the dashboard, low-balance alert wired and tested
Production /health/ready returned 200 throughout (after the nginx reload fix)
Base finality on every settle, all transactions visible on basescan

I will follow up in two weeks with a real soak report: 7-day error rate, fallback rate, p99 lock-wait latency, total ETH spent, total USDC settled. The numbers I quote there will be production-true, not hopeful.

What I learned

Three things, ordered from operational to philosophical:

Read the SDK source, do not trust the inline docstrings. The "iterates fallback clients" comment was in our code, not in the SDK. The actual SDK behavior is single-client-wins. If I had not read @x402/core/server/index.js directly, our PayAI fallback would have been dead code.
Hot wallet operations are simpler than they sound. Generate a key, fund with ETH, hold it in .env (chmod 600, gitignored), monitor balance via Prometheus alert. The operational complexity of running our own facilitator is genuinely lower than the operational complexity of dealing with KYC, billing dashboards, and SaaS quota limits. We are saving roughly $50/month at our current volume — not a lot, but the dependency removal is the actual prize.
Vendor dependencies on critical revenue paths are technical debt. A free tier with a paid escalator is a free tier until the day it isn't. CDP did not do anything wrong here — they sent a clear notification, gave a clear path forward, and have legitimate KYC requirements. But "depend on a vendor for the part of our system that converts agent calls to revenue" was a fragile choice we had not noticed making. Self-hosting is one less hop, one less account to manage, one less single point of failure.

Try it yourself

If you run an x402-priced API and want to drop your facilitator dependency:

# Generate an operator wallet
npx tsx -e "
const { generatePrivateKey, privateKeyToAccount } = require('viem/accounts');
const pk = generatePrivateKey();
console.log('address:', privateKeyToAccount(pk).address);
console.log('privkey:', pk);
"

# Fund the address with ~$10 of ETH on Base via any exchange withdrawal

# Add to .env (chmod 600, gitignored, never log)
echo "X402_OPERATOR_PRIVATE_KEY=<the privkey>" >> .env

# Replace your HTTP facilitator with the in-process one
# (full reference impl: github.com/whiteknightonhorse/APIbase/blob/main/src/payments/local-facilitator.ts)

That is the whole pattern. The full architecture write-up — operational design, two-wallet model, observability stack, key rotation procedure — lives in docs/x402-facilitator.md. MIT-licensed, fork freely.

If you ship something on this pattern, open an issue on the repo. I would like to know it works for someone other than us.

APIbase is a unified MCP gateway with 576 tools and 177 providers, paid via x402 USDC on Base or MPP USDC on Tempo. Production endpoint: https://apibase.pro/mcp.

Build a Flight-Search MCP App in 10 Minutes with Sunpeak + APIbase

whiteknightonhorse — Fri, 10 Apr 2026 07:41:17 +0000

What if your ChatGPT plugin could search real flight prices?

Not a mock. Not a demo. Actual Amadeus GDS data — airlines, prices, stops, departure times — inside an interactive app running in ChatGPT or Claude.

That's what we're building in this tutorial. The stack:

Sunpeak — open-source framework for building MCP Apps inside ChatGPT and Claude
APIbase — unified MCP gateway with 500 real-world API tools

Ten minutes. Working app. Let's go.

What is Sunpeak?

Sunpeak is an npm framework that lets you build interactive applications — with forms, buttons, charts, and data displays — that run inside AI assistants. Think of it as React for ChatGPT.

The apps are built on MCP (Model Context Protocol), so they work in both ChatGPT and Claude without separate codebases. You develop locally with a hot-reloading inspector, then deploy once.

pnpm add -g sunpeak
sunpeak create my-flight-app
cd my-flight-app

What is APIbase?

APIbase is a single MCP endpoint that gives your app access to 500 API tools — flights (Amadeus), weather (NOAA), stock quotes (Finnhub), government data (Census, CDC, Congress), museums (Met, Rijksmuseum), and 150+ more providers.

One connection. No individual API keys to manage. Pay per call with x402 USDC micropayments.

MCP endpoint: https://apibase.pro/mcp

Step 1: Wire APIbase into your Sunpeak app

In your Sunpeak app config, add APIbase as an MCP server:

import { createApp } from "sunpeak";

const app = createApp({
  mcpServers: [
    {
      name: "apibase",
      url: "https://apibase.pro/mcp",
      transport: "streamable-http"
    }
  ]
});

That's it. Your app now has access to all 500 tools. No API key needed for initial connection — auto-registration handles it.

Step 2: Discover available tools

Before you hardcode tool names, use the discover_tools prompt to find what's available:

curl -X POST https://apibase.pro/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "prompts/get",
    "params": {
      "name": "discover_tools",
      "arguments": {"category": "travel"}
    },
    "id": 1
  }'

This returns only the travel-related tools instead of dumping all 500 into context. You'll see tools like:

Tool	What it does
`amadeus.flights.search`	Search flights by origin/destination/date
`amadeus.flights.price`	Confirm pricing for a specific flight
`amadeus.airports.search`	Find airports by keyword
`weatherapi.forecast`	Weather forecast for any city
`finance.exchange.ecb_rates`	Currency exchange rates (ECB)

Step 3: Build the flight search component

Here's a Sunpeak component that searches flights and displays results:

import { useToolCall } from "sunpeak/hooks";

function FlightSearch() {
  const searchFlights = useToolCall("amadeus.flights.search");

  async function handleSearch(origin: string, destination: string, date: string) {
    const result = await searchFlights({
      origin,      // "JFK"
      destination,  // "LHR"
      date,         // "2026-05-15"
      adults: 1
    });

    // result.flights contains real Amadeus GDS data:
    // airline, price, currency, departure, arrival, stops
    return result;
  }

  // Sunpeak renders this as an interactive form inside ChatGPT/Claude
  return (
    <SearchForm onSubmit={handleSearch}>
      <Input name="origin" placeholder="From (e.g. JFK)" />
      <Input name="destination" placeholder="To (e.g. LHR)" />
      <DatePicker name="date" />
      <SubmitButton>Search Flights</SubmitButton>
    </SearchForm>
  );
}

When a user interacts with your app in ChatGPT, they see a form. They fill in JFK → LHR → May 15. Your app calls amadeus.flights.search through the APIbase MCP endpoint. Real flight data comes back.

Step 4: Add weather and currency conversion

One endpoint, multiple tools. Let's add weather for the destination and currency conversion:

async function enrichFlightResult(flight: Flight) {
  const [weather, rates] = await Promise.all([
    callTool("weatherapi.forecast", {
      q: flight.destination_city,
      days: 3
    }),
    callTool("finance.exchange.ecb_rates", {
      base: flight.currency,
      symbols: "USD,EUR,GBP"
    })
  ]);

  return {
    ...flight,
    destination_weather: weather.forecast,
    price_in_usd: flight.price * rates.USD,
    price_in_eur: flight.price * rates.EUR
  };
}

Three API calls. Three different providers (Amadeus, WeatherAPI, ECB). One MCP connection. Total cost: ~$0.04.

Step 5: Test locally

Sunpeak's inspector lets you test your app in a simulated ChatGPT/Claude environment without needing a paid account:

sunpeak dev
# Opens inspector at http://localhost:3000
# Simulates ChatGPT and Claude runtimes

The inspector renders your forms, handles tool calls, and shows you exactly what the user would see. Hot module reloading means changes appear instantly.

Step 6: Deploy

sunpeak build
sunpeak deploy

Your app is now installable in ChatGPT and Claude. Users can search real flight prices, see destination weather, and compare prices in multiple currencies — all inside their AI assistant.

What you just built

An interactive MCP App that:

Searches real flight prices via Amadeus GDS (not scraped, not cached — live airline data)
Checks destination weather via WeatherAPI (3-day forecast)
Converts currencies via ECB exchange rates (160+ currencies)
Runs inside ChatGPT and Claude via Sunpeak MCP framework
Pays per call via x402 USDC micropayments ($0.04 total for all three queries)

No API keys to manage. No separate provider accounts. No subscription fees.

The bigger picture

MCP Apps are a new category. They're not chatbots (no free-form text generation). They're not plugins (no OAuth dance). They're interactive applications that happen to live inside AI assistants.

The missing piece has always been data. Sunpeak gives you the UI framework. APIbase gives you 500 real-world data sources through one connection. Together, they let you build apps that would have taken weeks of API integration in days.

Some ideas for what to build next:

Real estate explorer — search properties (US Real Estate API), check walkability (Walk Score), get neighborhood demographics (Census)
Research assistant — search papers (DBLP, arXiv, OpenAlex), find authors, check citations
Travel planner — flights + hotels + weather + currency + local events (Ticketmaster) + restaurant reservations
Portfolio tracker — stock quotes (Finnhub), crypto prices (CoinGecko), exchange rates, company news

All of these are 3-5 tool calls through one MCP endpoint.

Try it yourself

1. Install Sunpeak:

pnpm add -g sunpeak

2. Browse APIbase tools:

curl -s https://apibase.pro/api/v1/tools | python3 -m json.tool | head -50

3. Full framework integration guide:
apibase.pro/frameworks#sunpeak

4. APIbase MCP endpoint:

https://apibase.pro/mcp

APIbase is open source — GitHub. Sunpeak is open source — MIT license.

The 3 MCP Servers Every AI Agent Needs in Production

whiteknightonhorse — Wed, 08 Apr 2026 12:19:29 +0000

Your AI agent is probably missing two-thirds of what it needs

Most agents ship with one capability: text generation. Some get tool access — usually a single API or a browser. But in production, agents need three fundamentally different types of tools:

Documentation context — reading library docs, API references, changelogs
Browser interaction — navigating pages, filling forms, taking screenshots
Real-world data — flights, weather, stock prices, government records, package metadata

No single MCP server covers all three. But three servers together do. Here's how I wire Context7, Playwright, and APIbase into one agent — and why the combination matters.

Why three servers, not one?

The Model Context Protocol lets an agent connect to multiple tool servers simultaneously. Each server exposes its tools through the same protocol, so the agent sees one flat catalog regardless of how many servers are behind it.

But MCP servers specialize. A documentation server optimizes for RAG over markdown. A browser server manages headless Chrome sessions. An API gateway handles auth, caching, rate limits, and payment for upstream providers.

Trying to do all three in one server means doing all three badly. The separation is intentional.

Here's the architecture:

┌──────────────┐
│   AI Agent   │
│  (your code) │
└──────┬───────┘
       │ MCP (Streamable HTTP)
       ├──────────────────────────────────┐
       │                                  │
┌──────▼───────┐  ┌──────────────┐  ┌─────▼──────────┐
│  Context7    │  │  Playwright  │  │  APIbase       │
│  (docs/code) │  │  (browser)   │  │  (487 APIs)    │
└──────────────┘  └──────────────┘  └────────────────┘

Let me walk through each one.

Server 1: Context7 — Up-to-date documentation

What it does: Fetches live documentation for libraries and frameworks. Instead of relying on the LLM's training data (which is always months behind), Context7 pulls the current docs at query time.

Why agents need it: LLMs hallucinate API signatures. A lot. If your agent is generating code that calls pandas.DataFrame.to_parquet(), it needs the current parameter list — not what GPT memorized from 2024 docs.

Key tools:

resolve — finds the right library by name
get-library-docs — retrieves documentation for a specific topic

# Example: Get current Next.js App Router docs
result = await agent.call_tool("context7", "resolve", {
    "libraryName": "next.js"
})
# Returns: library_id = "/vercel/next.js"

docs = await agent.call_tool("context7", "get-library-docs", {
    "libraryId": "/vercel/next.js",
    "topic": "app router middleware"
})
# Returns: current markdown docs, not stale training data

Setup: Free, open source, no API key needed.

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

Limitation: Only covers libraries indexed in their registry. If you're using a niche library, you'll get nothing. But for popular frameworks (React, Next.js, FastAPI, LangChain), it's solid.

Server 2: Playwright MCP — Browser automation

What it does: Gives the agent a headless browser. Navigate pages, click buttons, fill forms, take screenshots, extract content from rendered JavaScript.

Why agents need it: Not everything has an API. Job application forms, internal dashboards, CMS interfaces, legacy web apps — your agent needs a browser for these.

Key tools:

browser_navigate — go to a URL
browser_click — click an element
browser_type — fill input fields
browser_screenshot — capture the current page
browser_snapshot — get accessibility tree (structured page content)

# Example: Check a competitor's pricing page
await agent.call_tool("playwright", "browser_navigate", {
    "url": "https://competitor.com/pricing"
})

snapshot = await agent.call_tool("playwright", "browser_snapshot", {})
# Returns: structured accessibility tree of the pricing page
# Agent can now parse tiers, prices, feature lists

Setup: Runs locally via npx (no remote server needed for dev):

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic-ai/mcp-server-playwright"]
    }
  }
}

Limitation: Headless browser is slow (2-5 seconds per action). Rate-limited by nature. Not suitable for bulk data retrieval — that's what APIs are for.

Server 3: APIbase — 487 real-world APIs through one endpoint

What it does: Unified MCP gateway to 487 tools from 150 upstream providers. Travel, finance, weather, government data, science, e-commerce, jobs, entertainment, dev tools — all through one connection.

Why agents need it: An agent that can only browse the web and read docs is still missing structured data. It can't check flight prices, look up stock quotes, query US Census data, or search npm packages without an API. And wiring 150 separate APIs means managing 150 auth flows, rate limits, and response formats.

APIbase handles that. One MCP endpoint, one auth token (or no token — auto-registration), pay-per-call pricing.

Key tools (487 total, here are 10 across categories):

Tool	What it returns	Price
`amadeus.flights.search`	Real-time flight prices, routes, airlines	$0.035
`coingecko.crypto.price`	Live crypto prices for any token	$0.001
`serper.search.web`	Google search results as JSON	$0.002
`census.gov.population`	US Census population data by state/county	$0.001
`npm.registry.package_info`	npm package metadata, versions, downloads	$0.001
`hf.hub.models`	HuggingFace model search (1M+ models)	$0.001
`noaa.weather.forecast`	US weather forecasts by coordinates	$0.002
`congress.gov.bills`	US Congressional bills and legislation	$0.001
`gbif.species.search`	Global biodiversity occurrence data	$0.001
`osv.security.query`	Vulnerability database (npm, PyPI, Go, etc.)	$0.001

# Example: Search for flights from NYC to London
curl -X POST https://apibase.pro/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "amadeus.flights.search",
      "arguments": {
        "origin": "JFK",
        "destination": "LHR",
        "date": "2026-05-15",
        "adults": 1
      }
    },
    "id": 1
  }'

Response (trimmed):

{
  "result": {
    "content": [{
      "type": "text",
      "text": "{\"flights\":[{\"airline\":\"BA\",\"price\":\"412.00\",\"currency\":\"USD\",\"departure\":\"2026-05-15T19:00:00\",\"arrival\":\"2026-05-16T07:15:00\",\"stops\":0}]}"
    }]
  }
}

Setup:

{
  "mcpServers": {
    "apibase": {
      "url": "https://apibase.pro/mcp"
    }
  }
}

No API key required for initial connection — auto-registration gives you credentials on first request. Payment is x402 USDC micropayments (from $0.001 to $1.00 per call depending on the tool).

Limitation: Paid per call. Not suitable for bulk scraping or high-frequency polling. Use the browser server for web scraping, APIbase for structured data.

Wiring all three together

Here's a complete Python example using the OpenAI Agents SDK with all three servers:

import asyncio
from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHTTP

async def main():
    # Connect to all 3 MCP servers
    context7 = MCPServerStreamableHTTP(
        name="context7",
        url="https://mcp.context7.com/mcp"
    )
    playwright = MCPServerStreamableHTTP(
        name="playwright",
        url="http://localhost:3001/mcp"  # local Playwright server
    )
    apibase = MCPServerStreamableHTTP(
        name="apibase",
        url="https://apibase.pro/mcp"
    )

    async with context7, playwright, apibase:
        # Gather tools from all servers
        all_tools = (
            await context7.list_tools() +
            await playwright.list_tools() +
            await apibase.list_tools()
        )

        agent = Agent(
            name="research-agent",
            instructions="""You are a research agent with 3 capabilities:
            1. Context7: look up current library documentation
            2. Playwright: browse websites and interact with pages
            3. APIbase: query 487 real-world APIs (flights, finance,
               weather, government data, science, jobs, etc.)

            Use the right tool for each task. Prefer APIs over
            browser automation when structured data is available.""",
            tools=all_tools,
        )

        result = await Runner.run(
            agent,
            "Find the cheapest JFK→LHR flight for May 15, "
            "then check the current GBP/USD exchange rate, "
            "and look up London weather for that date."
        )
        print(result.final_output)

asyncio.run(main())

The agent sees one combined tool catalog. It picks amadeus.flights.search for flights, finance.exchange.ecb_rates for the exchange rate, and weatherapi.forecast for London weather — all from APIbase. If it needed to check a website that doesn't have an API, it'd use Playwright. If it needed current docs for a library it's using, it'd call Context7.

Three servers. One agent. Full coverage.

When to use which server

Task	Best Server	Why
Get current React docs	Context7	Up-to-date library docs, not stale training data
Fill out a web form	Playwright	Needs browser interaction, no API available
Search flight prices	APIbase	Structured API data, faster and cheaper than scraping
Read a blog post	Playwright	Rendered HTML, may need JavaScript
Query US Census data	APIbase	Government API, returns structured JSON
Check npm package versions	APIbase	Registry API, no browser needed
Navigate a dashboard	Playwright	Interactive UI, login required
Get stock quotes	APIbase	Real-time financial data via API
Look up LangChain docs	Context7	Framework docs that change frequently
Take a webpage screenshot	Playwright	Visual capture, needs rendering engine

The rule of thumb: if structured data exists via an API, use APIbase. If you need a browser, use Playwright. If you need current docs, use Context7.

What I learned running all three in production

Token efficiency matters. APIbase exposes 487 tools. Loading all of them into context is wasteful. Instead, I use the discover_tools prompt with a category filter:

curl -X POST https://apibase.pro/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "prompts/get",
    "params": {
      "name": "discover_tools",
      "arguments": {"category": "finance"}
    },
    "id": 1
  }'

This returns only the ~40 finance tools instead of all 487. The agent gets what it needs without burning 10K tokens on tool definitions.

Browser is the fallback, not the default. Agents instinctively reach for the browser because it's the most general tool. But browser actions are 10-50x slower than API calls and cost more in tokens (accessibility trees are verbose). Train your agent to check APIbase first, browser second.

Cache TTLs vary wildly. Crypto prices cache for 5 seconds. Walk Score data caches for 7 days. Census data caches for 24 hours. This is handled per-tool on the server side — your agent doesn't need to think about it. But it matters for cost: repeated calls to cached endpoints are cheaper.

Try it yourself

1. Connect to all three in Claude Desktop:

Edit ~/.config/claude/claude_desktop_config.json:

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    },
    "apibase": {
      "url": "https://apibase.pro/mcp"
    }
  }
}

(Playwright requires a local process — see the Playwright MCP docs for setup.)

2. Ask your agent:

"Search for direct flights from SFO to Tokyo for next month, check the current JPY exchange rate, and find the weather forecast for Tokyo on the arrival date."

The agent will use amadeus.flights.search, finance.exchange.ecb_rates, and weatherapi.forecast — three API calls, one agent, real data.

3. Browse the full tool catalog:

curl -s https://apibase.pro/api/v1/tools | python3 -m json.tool | head -50

487 tools across 22 categories. Travel, finance, weather, science, government, jobs, entertainment, dev tools, and more.

APIbase is open source — GitHub. Integration guides for OpenAI SDK, LangChain, Google ADK, and more at apibase.pro/frameworks.

How I Gave an AI Agent Access to 20 Job APIs Through One Endpoint

whiteknightonhorse — Tue, 31 Mar 2026 14:27:40 +0000

The Problem: Job Data is Scattered Everywhere

If you've ever tried to build anything that touches job market data, you know the pain. Every job board has its own API, its own auth, its own rate limits, its own response format.

Want global coverage? You need Adzuna for 16 countries, Reed for UK, Arbeitnow for EU, Remotive for remote roles, TheirStack for tech stack analysis, Jooble for aggregated results, and probably five more I'm forgetting.

That's 7 API keys, 7 auth schemes (Basic Auth, Bearer tokens, keys-in-URL-path, no auth at all), 7 different response formats, and 7 sets of rate limit rules. For a single query like "find me Python developer jobs in Europe, preferably remote."

I spent the last week wiring all of these into a single MCP endpoint. Here's exactly how it works and how you can use it.

What MCP Changes About Multi-API Orchestration

Model Context Protocol (MCP) is the standard that lets AI agents discover and call tools dynamically. Instead of hardcoding API calls, your agent connects to an MCP server and gets a catalog of available tools — with typed schemas, descriptions, and pricing.

The key insight: the agent decides which tools to call based on the user's question. You don't write if/else logic for "if the user asks about UK jobs, call Reed; if they ask about remote, call Remotive." The LLM reads the tool descriptions and routes naturally.

Here's what 20 job-related tools look like through one MCP connection:

# Connect and discover job tools
curl -X POST https://apibase.pro/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "prompts/get",
    "params": {
      "name": "discover_tools",
      "arguments": { "category": "jobs" }
    }
  }'

The response lists every job tool with its parameters:

Tool	What It Does	Coverage
`adzuna.search`	Job search with salary data	16 countries
`adzuna.salary`	Salary histograms by role	16 countries
`adzuna.categories`	Job category taxonomy	Per-country
`theirstack.jobs`	Tech stack-filtered job search	Global, 181M+ postings
`theirstack.companies`	Find companies by technology	Global
`jooble.search`	Aggregated search, 70+ countries	Global
`reed.search`	UK jobs with salary (GBP)	UK
`reed.details`	Full job details by ID	UK
`arbeitnow.jobs`	EU job listings	DE, AT, CH, NL
`remotive.search`	Remote-only curated listings	Global remote
`jobs.salary_data`	BLS salary statistics	US
`jobs.occupation_search`	O*NET occupation database	US
`jobs.esco_search`	EU skills/occupation taxonomy	EU
`jobs.job_search`	CareerJet search	Global

That's one connection, one auth token, one response format. The agent picks which tool fits the question.

Building the Agent: From Question to Multi-Source Results

Let me walk through what happens when a user asks: "Find me senior Python developer jobs in Berlin, preferably remote, and compare salaries with London."

A well-prompted agent would break this into 3-4 tool calls:

Call 1: TheirStack for tech-stack-specific results

curl -X POST https://apibase.pro/api/v1/tools/theirstack.jobs/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "X-PAYMENT: ..." \
  -H "Content-Type: application/json" \
  -d '{
    "keywords": "senior python developer",
    "country": "DE",
    "remote": true,
    "technologies": "python, django, fastapi",
    "limit": 10
  }'

Response:

{
  "jobs": [
    {
      "title": "Senior Python Developer",
      "company": "Delivery Hero",
      "location": "Berlin",
      "country": "DE",
      "remote": true,
      "salary_min_usd": 75000,
      "salary_max_usd": 95000,
      "posted": "2026-03-28",
      "url": "https://..."
    }
  ],
  "count": 10
}

Call 2: Reed for UK salary comparison

curl -X POST https://apibase.pro/api/v1/tools/reed.search/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "X-PAYMENT: ..." \
  -d '{
    "keywords": "senior python developer",
    "location": "London",
    "salary_min": 60000,
    "permanent": true,
    "limit": 10
  }'

{
  "jobs": [
    {
      "id": 56671234,
      "title": "Senior Python Developer",
      "company": "Revolut",
      "location": "London",
      "salary_min": 80000,
      "salary_max": 110000,
      "currency": "GBP",
      "applications": 47,
      "url": "https://www.reed.co.uk/jobs/..."
    }
  ],
  "total": 443,
  "count": 10
}

Call 3: Remotive for remote-only options

curl -X POST https://apibase.pro/api/v1/tools/remotive.search/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "X-PAYMENT: ..." \
  -d '{
    "search": "python senior",
    "category": "software-dev",
    "limit": 10
  }'

{
  "jobs": [
    {
      "id": 982341,
      "title": "Senior Python Backend Engineer",
      "company": "GitLab",
      "category": "Software Development",
      "salary": "$130,000 - $170,000",
      "location_requirement": "Americas, EMEA",
      "tags": ["python", "django", "postgresql"],
      "url": "https://remotive.com/remote-jobs/..."
    }
  ],
  "count": 10,
  "total": 2847
}

Call 4: Adzuna salary histogram

curl -X POST https://apibase.pro/api/v1/tools/adzuna.salary/call \
  -H "Authorization: Bearer ak_live_..." \
  -H "X-PAYMENT: ..." \
  -d '{
    "what": "python developer",
    "where": "london",
    "country": "gb"
  }'

The agent now has: Berlin jobs with tech stack filters, London jobs with GBP salaries, global remote positions with USD salary ranges, and a salary distribution histogram. Total cost: 4 API calls × $0.001-0.002 each = less than $0.01 for a comprehensive multi-market job analysis.

The Part Nobody Talks About: Why 7 Providers, Not 1

Here's what I learned integrating all these job APIs in one day.

No single provider covers everything:

Need	Best Provider	Why
"Show me Python jobs"	TheirStack	Only one with tech stack filter (`technologies_or`)
"UK jobs with salary"	Reed	Structured min/max GBP salary, not free text
"Remote jobs only"	Remotive	Curated remote-only board, salary strings included
"Jobs in Germany"	Arbeitnow	EU-native, German market coverage
"Salary comparison"	Adzuna	Statistical salary histograms, not just listings
"Global search"	Jooble	70+ countries, widest aggregation
"How competitive is this role?"	Reed	`applications` count per listing

The auth diversity is wild. In one afternoon I dealt with:

Bearer JWT tokens (TheirStack)
API key in URL path — literally /api/{key} (Jooble)
HTTP Basic Auth with key as username, empty password (Reed)
No auth at all (Arbeitnow, Remotive)
App ID + App Key as query params (Adzuna)

That's 5 different auth schemes for one category. An MCP gateway normalizes this — your agent sends one Authorization: Bearer header and the gateway handles the rest.

Response Format Normalization

This is the unsexy-but-critical part. Each API returns salary differently:

TheirStack:  "salary_min_usd": 75000, "salary_max_usd": 95000
Reed:        "minimumSalary": 80000.0, "maximumSalary": 110000.0, "currency": "GBP"
Remotive:    "salary": "$130,000 - $170,000"
Adzuna:      "salary_min": 45000, "salary_max": 65000 (no currency field, inferred from country)
Arbeitnow:   no salary field at all
Jooble:      "salary": "" (often empty)

The adapter layer normalizes each response into a consistent shape. Reed's minimumSalary becomes salary_min. Remotive's free-text salary string gets passed through as-is (parsing "$130,000 - $170,000" into min/max is the agent's job — the API shouldn't guess).

Every adapter also strips HTML from descriptions (job boards love injecting   and <b> tags into plain text fields) using a shared stripHtml() utility. This sounds trivial until you're debugging why an agent is hallucinating HTML entities.

Payment: Per-Call, Not Per-Month

Each job search costs $0.001 to $0.002 per call. The payment happens via x402 — the HTTP standard where:

Agent calls a tool → gets 402 Payment Required with price
Agent signs a USDC micropayment on Base
Agent retries with payment proof in X-PAYMENT header
Server verifies, escrows funds, calls the upstream API, returns data
Escrow settles to the platform wallet

For a recruiting agent that runs 100 job searches per day across 7 providers, that's roughly $0.15/day. Compare that to subscribing to 7 different job APIs at $30-100/month each.

Traditional: 7 APIs × ~$50/month = $350/month
Per-call:    100 calls/day × $0.002 × 30 days = $6/month

This is why per-call pricing matters for agents. Most agents are bursty — they run a batch of searches, synthesize results, then go idle. Paying subscriptions for idle capacity is exactly the wrong model.

Try It Yourself

The entire jobs toolkit is live right now. Connect any MCP client:

{
  "mcpServers": {
    "apibase": {
      "url": "https://apibase.pro/mcp",
      "transport": "streamable-http"
    }
  }
}

Or use REST directly:

# Get all available job tools
curl -s https://apibase.pro/api/v1/tools | \
  python3 -c "
import sys,json
tools = json.load(sys.stdin)['data']
jobs = [t for t in tools if t['category'] == 'jobs' or 'job' in t['name'].lower()]
for t in jobs:
    print(f\"{t['id']:30s} \${t['pricing']['price_usd']}\")
"

The MCP endpoint is at https://apibase.pro/mcp. The full tool catalog (409 tools across 30+ categories — not just jobs) is at https://apibase.pro/api/v1/tools. Source code is on GitHub.

The jobs category alone now has 20 tools across 7 specialized providers. Each one was chosen for a specific coverage gap — there's no overlap where one provider does everything another does. That's the point of a gateway: you pick the best tool for each question, not the best "one API to rule them all."

Built with APIbase.pro — 409 tools, 121 providers, one MCP endpoint.

6 Things No Other MCP Server Lets Your AI Agent Do

whiteknightonhorse — Tue, 24 Mar 2026 12:47:28 +0000

Your AI agent can chat. But can it buy a domain?

Most MCP servers give agents access to search, weather, maybe a database. Useful, but not differentiated. Every MCP directory has a dozen weather tools and five search wrappers.

I spent the last week asking a different question: what can an AI agent do through MCP that it literally cannot do anywhere else?

The answer turned into six exclusive integrations that I haven't seen on any other MCP server. Here's what they are, why they matter, and how agents actually use them.

Why "exclusive" matters for MCP

MCP servers are multiplying fast. Smithery lists hundreds. Most wrap the same APIs — OpenWeatherMap, Google Search, maybe a stock price feed.

The problem: if every MCP server offers the same tools, agents have no reason to prefer one over another. The value isn't in wrapping APIs. It's in which APIs you wrap and what workflows they unlock when combined.

That's what pushed me to look beyond data-retrieval tools toward tools that let agents take action in the real world.

1. Register a domain name

# Check if a domain is available
POST /tools/namesilo.domain_check
{
  "domains": "mycoolstartup.com,awesomeapp.io,buildfast.dev"
}

{
  "available": [
    { "domain": "mycoolstartup.com", "price_usd": 17.29 },
    { "domain": "buildfast.dev", "price_usd": 14.99 }
  ],
  "unavailable": ["awesomeapp.io"]
}

The agent checks availability, sees the price, and can call namesilo.domain_register to actually purchase it. The domain cost gets charged through x402 USDC — the agent pays, the domain is registered, WHOIS privacy included.

Why it matters: An agent building a website for a client can now handle the entire domain lifecycle — check, buy, configure — without a human opening GoDaddy.

2. Manage Cloudflare DNS

Once the agent owns a domain, it needs to point it somewhere:

POST /tools/cloudflare.dns_create
{
  "zone_id": "abc123...",
  "type": "A",
  "name": "api",
  "content": "5.78.135.159",
  "proxied": true
}

Six DNS tools: list zones, list records, create records, delete records, view traffic analytics, and purge CDN cache.

The real power is the combination. Domain purchase (NameSilo) + DNS configuration (Cloudflare) = an agent that can deploy a complete web presence from scratch. No dashboards, no clicking through UIs.

Agent workflow:
1. namesilo.domain_check → "buildfast.dev available"
2. namesilo.domain_register → domain purchased
3. cloudflare.dns_create → A record → server IP
4. cloudflare.purge_cache → CDN active
Total: 4 API calls. Zero human interaction.

3. Search 577,000 clinical trials

This one surprised me. ClinicalTrials.gov has a public API with every clinical study registered in the US — drug trials, device trials, behavioral studies — from 220+ countries.

POST /tools/clinical.search
{
  "condition": "Breast Cancer",
  "intervention": "pembrolizumab",
  "status": "RECRUITING"
}

Returns: NCT ID, title, sponsor, enrollment count, phase, interventions, dates. The detail endpoint (clinical.study) gives you the full protocol — eligibility criteria, primary outcomes, dosing schedules.

Why it matters: Healthcare AI agents are one of the fastest-growing segments. A research agent can now search for "all Phase 3 trials for lung cancer recruiting in 2026" and get structured, machine-readable results. No scraping, no parsing PDFs.

Who uses this: Pharma competitive intelligence agents, clinical research assistants, patient-matching systems, academic research bots.

4. Send Telegram messages

POST /tools/telegram.send_message
{
  "chat_id": "123456789",
  "text": "Portfolio alert: AAPL dropped 5% to $237.50",
  "parse_mode": "Markdown"
}

Five tools: send text messages (with Markdown/HTML), send photos, send documents (PDFs, CSVs), check for incoming messages, and get chat info.

The game-changer is combining this with monitoring tools:

Agent workflow:
1. finnhub.quote → check stock price
2. Price dropped 5%? →
3. telegram.send_message → alert the user
4. edgar.company_facts → pull latest SEC filing
5. telegram.send_document → send financial summary as PDF

Every monitoring agent needs a notification channel. Telegram is free, has 900M users, and the bot API has no meaningful rate limits.

Content moderation built in: Every outbound message passes through a content filter that blocks prohibited content (drugs, weapons, CSAM, terrorism) before it reaches the Telegram API. The blocklist covers exact phrases, regex patterns, and URL validation. If the filter catches something, the message is never sent.

5. Spin up managed browser sessions

POST /tools/browser.create_session
{
  "region": "us-west-2",
  "proxy": true
}

{
  "session_id": "0f5e888e-8109-4395-a62a-95f07943160e",
  "status": "RUNNING",
  "connect_url": "wss://connect.browserbase.com?apiKey=...&sessionId=..."
}

This creates a real Chromium browser session in the cloud. The agent gets a WebSocket URL it can connect to with Puppeteer or Playwright. Navigate pages, fill forms, click buttons, take screenshots — on infrastructure that handles anti-bot detection and residential proxies.

Why it matters: Computer-use agents (Claude Computer Use, GPT-4o browsing) need browser infrastructure they can't self-provision. Per-session pricing ($0.01-0.05) makes it economically viable for agents to browse the web on-demand.

6. Search free stock photos and videos

POST /tools/pexels.search_photos
{
  "query": "modern office workspace",
  "orientation": "landscape",
  "size": "large",
  "limit": 5
}

Returns high-quality photos with download URLs in multiple sizes (original, large, medium, small, portrait, landscape). All photos are free for commercial use under the Pexels license — no attribution required.

Why it matters: Content-generation agents building websites, reports, or marketing materials need licensed media. Instead of a human browsing stock photo sites, the agent searches, selects, and downloads — all programmatically.

The pattern: action, not just data

Capability	Traditional MCP	These tools
Domain	❌	Check + buy + manage
DNS	❌	Create, delete, analytics
Clinical data	❌	577K trials searchable
Messaging	❌	Telegram with content filter
Browser	❌	Managed sessions with proxy
Stock media	❌	Free commercial-use photos

The common thread: these tools let agents do things, not just look things up. Register a domain. Configure infrastructure. Send a notification. Spin up a browser. Get licensed media.

That's the direction agentic commerce is heading. McKinsey projects $3-5 trillion in agentic commerce by 2030. The agents that win won't be the ones with the best chat — they'll be the ones that can take action in the real world.

The numbers

After this week's sprint:

300 tools across 84 providers
6 exclusive capabilities no other MCP server offers
30+ categories: travel, finance, health, legal, entertainment, infrastructure, messaging, media
All paid per-call via x402 USDC on Base
Open source: GitHub

Try it yourself

Connect any MCP-compatible client:

{
  "mcpServers": {
    "apibase": {
      "url": "https://apibase.pro/mcp"
    }
  }
}

Or browse the full tool catalog: https://apibase.pro/api/v1/tools

The clinical trials search, stock photos, and domain availability check all work on the free tier. Send a Telegram message to see the content filter in action.

Built with APIbase — 300 tools, 84 providers, one MCP endpoint.

What Happens When an AI Agent Pays for Its Own API Calls

whiteknightonhorse — Thu, 19 Mar 2026 14:53:30 +0000

Your AI agent needs to search flights. It needs real-time stock prices. It needs to OCR a receipt image. Each of these requires a different API, a different auth flow, a different billing account.

What if the agent just... paid for each call itself? No subscriptions. No API key management. No human in the loop.

That's what I built. Here's how it works.

The Problem: API Integration Is a Tax on Every Agent Builder

If you're building an AI agent that interacts with the real world, you already know the pain:

Amadeus needs OAuth2 with double-base64 encoding
Finnhub uses a query param token
Serper wants an X-API-KEY header
NASA uses ?api_key= in the URL
Some APIs charge per call, others per month, others per character

For each provider, you're writing auth code, error handling, retry logic, rate limiting, and billing integration. Multiply that by 10 providers and you've spent more time on plumbing than on your actual agent logic.

I wanted one endpoint where my agent sends a tool call, pays in USDC, and gets data back. No signup forms. No dashboards. No invoices.

The Solution: MCP + x402 in One Pipeline

I built an MCP server that wraps 46 upstream API providers behind a single endpoint. The agent connects to https://apibase.pro/mcp, discovers 203 available tools, and calls any of them. Payment happens automatically via the x402 protocol — HTTP 402 with USDC on Base.

Here's what a single tool call looks like from the agent's perspective:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "stocks.market.quote",
    "arguments": {
      "symbol": "AAPL"
    }
  }
}

The response comes back with the stock price. Behind the scenes, $0.001 in USDC was escrowed, the Finnhub API was called, and the payment was settled — all in under 400ms.

The 13-Stage Pipeline

Every tool call passes through 13 stages in strict order. No stage can be skipped or reordered:

AUTH → IDEMPOTENCY → CONTENT_NEG → SCHEMA_VALIDATION → TOOL_STATUS → CACHE_OR_SINGLE_FLIGHT → RATE_LIMIT → ESCROW → PROVIDER_CALL → ESCROW_FINALIZE → LEDGER_WRITE → CACHE_SET → RESPONSE

Let me walk through the stages that matter most.

Stage 1: AUTH

The agent authenticates with a Bearer token. On first request, the system auto-registers the agent and returns an API key — no human signup required.

curl -X POST https://apibase.pro/api/v1/agents/register \
  -H "Content-Type: application/json" \
  -d '{"agent_name": "my-agent", "agent_version": "1.0.0"}'

Returns api_key: ak_live_... — stored as SHA-256 hash in PostgreSQL, never in plaintext.

Stage 4: SCHEMA_VALIDATION

Every tool has a Zod schema with .describe() on every field. The agent can't send garbage — invalid params are rejected at this stage with a clear error message, before any money moves.

const search = z.object({
  q: z.string().min(1).describe('Search query'),
  gl: z.string().max(2).optional().describe('Country code (e.g. "us")'),
  num: z.number().int().min(1).max(100).optional().describe('Results count'),
}).strip();

Stage 8: ESCROW

This is where it gets interesting. Before calling the upstream provider, we lock the tool's price in USDC:

Tool	Price	What happens
`finnhub.quote`	$0.001	Escrow $0.001 USDC
`serper.web_search`	$0.002	Escrow $0.002 USDC
`amadeus.flight_search`	$0.035	Escrow $0.035 USDC
`stability.generate`	$0.070	Escrow $0.070 USDC

The USDC is reserved from the agent's balance in a PostgreSQL transaction. If the provider call fails, Stage 10 automatically refunds.

Stage 9: PROVIDER_CALL

Now we actually call the upstream API. Each provider has a dedicated adapter that handles auth, request building, and response normalization.

What the agent sends:

{"symbol": "AAPL"}

What our adapter sends to Finnhub:

GET https://finnhub.io/api/v1/quote?symbol=AAPL&token=xxxxx

What comes back to the agent (normalized):

{
  "price": 249.94,
  "change": -4.06,
  "change_percent": -1.60,
  "high": 254.94,
  "low": 249.00,
  "open": 253.78,
  "previous_close": 254.00
}

The agent never sees the upstream API format, auth headers, or error codes. Every tool returns the same normalized structure.

Stage 10: ESCROW_FINALIZE + LEDGER_WRITE

If the provider call succeeded: settle the escrow, write to the append-only ledger. If it failed: refund the USDC, write a REFUNDED ledger entry. This happens in a single PostgreSQL transaction — no partial state possible.

The ledger is append-only. We never UPDATE or DELETE rows. This gives us a complete audit trail of every payment.

What 46 Providers Look Like Through One Pipe

Here's a sample of what agents can do through this single MCP endpoint:

Category	Tools	Example
Flights	amadeus.flight_search	Search JFK to LHR, real prices
Stocks	finnhub.quote, finnhub.candles	AAPL $249.94, OHLCV charts
Web Search	serper.web_search	Google results as JSON
AI Search	tavily.search	AI-synthesized answers + sources
News	news.latest, news.crypto	180K+ sources, 200+ countries
Legal	courtlistener.search	US court opinions since 1995
Real Estate	walkscore.score	Walk/Transit/Bike scores
Image Gen	stability.generate	Stable Diffusion from text
Email	resend.send_email	Transactional email delivery
OCR	ocr.extract_text	Text from image/PDF URL

Each tool costs between $0.001 and $0.070 per call. The agent decides what to call based on the task. No subscriptions, no minimums.

The Cache Layer: Why Most Calls Are Nearly Free

Stage 6 checks Redis before hitting the upstream provider. Each tool has a configured TTL:

finnhub.quote — 5 seconds (stock prices change fast)
walkscore.score — 7 days (walkability scores rarely change)
news.latest — 1 minute (news updates frequently)
courtlistener.search — 1 hour (court opinions are historical)

If 100 agents request AAPL's stock price in the same 5-second window, only one upstream call happens. The other 99 get the cached result instantly — still billed, but at a lower cache-hit price, and the upstream provider sees only one request.

Single-flight deduplication prevents thundering herd: concurrent identical requests wait for the first one to complete rather than all hitting the provider simultaneously.

What I Learned Building This

1. Escrow-first is non-negotiable. Early versions charged after the provider call. But if the agent disconnected mid-response, we'd already incurred upstream cost with no payment. Escrow-before-call eliminates this entirely.

2. Idempotency prevents double charges. Agents retry on timeout. Without idempotency keys, a single flight search could charge the agent twice. Stage 2 catches duplicates before any work happens.

3. Fail-closed beats fail-open. When Redis goes down, we reject all requests rather than disabling rate limits and caching. This sounds aggressive, but it prevents a single Redis restart from causing a cascade of unthrottled upstream calls.

4. 13 stages sounds like overhead, but each one prevents a real production bug. We removed a stage once (content negotiation) and immediately got agents sending XML to JSON-only providers. Every stage exists because we hit the bug it prevents.

Try It Yourself

Connect any MCP client to the endpoint and discover the tools:

curl -X POST https://apibase.pro/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"initialize","id":1,"params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

Or add it to Claude Desktop / Cursor:

{
  "mcpServers": {
    "apibase": {
      "url": "https://apibase.pro/mcp"
    }
  }
}

203 tools. One endpoint. The agent pays for what it uses.

Built with APIbase — open source on GitHub.

DEV Community: whiteknightonhorse

What Happens to the $0.001 When an AI Agent Pays for an API Call

Why this matters in 2026

The four buckets of $0.001

The five pricing tiers (with real tools)

The cache-hit shortcut

When the call fails

A worked example: agent calls finnhub.quote for AAPL

How the math actually works at scale

What I learned

Try it yourself

How We Replaced Our x402 Payment Facilitator in a Single Afternoon

What an x402 facilitator actually does

The build: 350 lines of glue

Three gotchas that cost us seven minutes of 502s

1. docker compose restart does not re-read env_file

2. --force-recreate does not pull new images

3. After --force-recreate, the inner nginx caches the old IP

Council Review and auto-fix

Day-0 numbers (with honest framing)

What I learned

Try it yourself

Build a Flight-Search MCP App in 10 Minutes with Sunpeak + APIbase

What if your ChatGPT plugin could search real flight prices?

What is Sunpeak?

What is APIbase?

Step 1: Wire APIbase into your Sunpeak app

Step 2: Discover available tools

Step 3: Build the flight search component

Step 4: Add weather and currency conversion

Step 5: Test locally

Step 6: Deploy

What you just built

The bigger picture

Try it yourself

The 3 MCP Servers Every AI Agent Needs in Production

Your AI agent is probably missing two-thirds of what it needs

Why three servers, not one?

Server 1: Context7 — Up-to-date documentation

Server 2: Playwright MCP — Browser automation

Server 3: APIbase — 487 real-world APIs through one endpoint

Wiring all three together

When to use which server

What I learned running all three in production

Try it yourself

How I Gave an AI Agent Access to 20 Job APIs Through One Endpoint

The Problem: Job Data is Scattered Everywhere

What MCP Changes About Multi-API Orchestration

Building the Agent: From Question to Multi-Source Results

Call 1: TheirStack for tech-stack-specific results

Call 2: Reed for UK salary comparison

Call 3: Remotive for remote-only options

Call 4: Adzuna salary histogram

The Part Nobody Talks About: Why 7 Providers, Not 1

Response Format Normalization

Payment: Per-Call, Not Per-Month

Try It Yourself

6 Things No Other MCP Server Lets Your AI Agent Do

Your AI agent can chat. But can it buy a domain?

Why "exclusive" matters for MCP

1. Register a domain name

2. Manage Cloudflare DNS

3. Search 577,000 clinical trials

4. Send Telegram messages

5. Spin up managed browser sessions

6. Search free stock photos and videos

The pattern: action, not just data

The numbers

Try it yourself

What Happens When an AI Agent Pays for Its Own API Calls

The Problem: API Integration Is a Tax on Every Agent Builder

The Solution: MCP + x402 in One Pipeline

The 13-Stage Pipeline

Stage 1: AUTH

Stage 4: SCHEMA_VALIDATION

Stage 8: ESCROW

Stage 9: PROVIDER_CALL

Stage 10: ESCROW_FINALIZE + LEDGER_WRITE

What 46 Providers Look Like Through One Pipe

The Cache Layer: Why Most Calls Are Nearly Free

1. `docker compose restart` does not re-read `env_file`

2. `--force-recreate` does not pull new images

3. After `--force-recreate`, the inner nginx caches the old IP