DEV Community: whiteknightonhorse

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.