# Let a Cursor agent pay for APIs over MCP

_By Apoorv Khanna, July 13, 2026_

A Cursor agent is very good at deciding it needs something from outside the repository. It needs a web search to check a library's current API, a scrape of a documentation page, a hundred enriched contacts for the script it is writing, or a sandbox to run something it does not trust in your terminal. It is very bad at paying for any of that, because the only mechanism it has ever had is an API key you pasted into an environment file, one per vendor, each with a card behind it and no limit in front of it.

This post is the other way. One MCP server, and the agent can call paid APIs from a single balance, with a maximum cost it states on every call, and a receipt on every success. Nothing vendor-specific lives in the repo.

## Install

The installer writes the server into Cursor's MCP configuration and signs you in:

```bash
npx @vaaya/mcp install
```

If you prefer to see what it wrote, or you keep configuration in the repository, the entry in `.cursor/mcp.json` is this:

```json
{
  "mcpServers": {
    "vaaya": {
      "command": "npx",
      "args": ["-y", "@vaaya/mcp"]
    }
  }
}
```

Restart Cursor, and the agent has two tools it did not have before: `consult` and `use`.

## The first paid call

Ask the agent for something that needs the outside world. In the Composer, something like:

> Find the three most-cited sources on Stripe's Machine Payments Protocol from the last two months and summarise how they differ from x402.

The agent calls `consult` with that intent. What comes back is not a result; it is a plan with prices. Two or three providers that can do the job, what each costs per call, and a recommendation. This is the moment the agent learns what things cost, which is the moment most agent frameworks skip.

The agent then calls `use` for the option it chose, and the argument that matters is the ceiling:

```json
{
  "service": "exa",
  "action": "search",
  "params": {
    "query": "Stripe Machine Payments Protocol MPP x402 comparison",
    "numResults": 10
  },
  "max_cost_cents": 5,
  "intent": "primary sources for an MPP vs x402 summary"
}
```

Vaaya checks the quoted price against that ceiling, runs the search against the provider with its own credentials, and returns the results to the agent together with a receipt: what was charged, on which key, and the transaction it can be traced to. The agent continues with the task. You did not create an Exa account, and there is no Exa key anywhere in the project.

## The refusal

Now the part that matters more than the success. Run the same call with a ceiling below the price:

```json
{ "service": "exa", "action": "search", "params": { "...": "..." }, "max_cost_cents": 1 }
```

The response is a refusal, and it is precise about why:

```json
{
  "error": "over_max",
  "message": "price is 5¢ but max_cost_cents was 1",
  "price_cents": 5
}
```

Nothing was charged. The provider was never contacted. The refusal is recorded against the agent's key with that reason, and the agent receives the reason so it can raise its ceiling, choose a cheaper option from the plan, or carry on without the call. This is the whole control in one exchange: the agent has to say the most it will pay, every time, and the system will not let it pay more. A well-built agent sets the ceiling from the plan and never sees this message. A careless one sees it constantly and costs you nothing.

Above the per-call ceiling sit the limits you set on the key the agent uses: which categories it may spend in, and how much per month. The details are in [how to give an AI agent a budget](/blog/give-an-ai-agent-a-budget). The short version is that one key per agent, with a category list and a monthly number, is the entire configuration.

## What this is not

It is not Cursor's billing. Cursor's spend limits, usage credits, and cloud agent pricing govern what you pay Cursor for the model doing the thinking. That bill is unchanged by anything here. This governs what your agent pays third parties for the things it fetches, runs, and generates while it thinks, and that bill goes to a separate account with separate controls. The two are easy to confuse because both use the word "agent" and both involve a limit, and they have nothing to do with each other.

It is also not a virtual card. The agent does not get a card number and cannot check out at a merchant. It can pay for anything that is an API in the catalog, which covers search and research, scraping, people and company data, public records, compute, media, and memory, and it cannot pay for a flight.

## What the agent can reach

The catalog is at [vaaya.ai/network](/network). The categories a Cursor agent tends to use most are search and research (Exa, Parallel, Tavily, Perplexity, Linkup), scraping (Firecrawl, Apify, Bright Data, Jina), compute (Modal, E2B, Daytona), and contact data (Apollo, ContactOut, Prospeo). Every provider is metered per call, priced before the call runs, and billed only on success. The agent reads the same catalog through `consult`, so it will usually know about a provider before you do.

```bash
npx @vaaya/mcp install
```

## Questions

**How do I let a Cursor agent pay for an API?**

Install the Vaaya MCP server with npx @vaaya/mcp install, or add it to .cursor/mcp.json by hand. The agent then asks consult for a priced plan and calls use with a maximum cost. Vaaya runs the call, pays the provider, and bills the account only if the call succeeds.

**Is this the same as Cursor's spend limits?**

No. Cursor's spend limits govern what you pay Cursor for models and cloud agents. This governs what your agent pays third-party providers for search, scraping, data, compute, and media. The two are separate bills with separate controls.

**Does the Cursor agent need API keys for each provider?**

No. The agent never sees an upstream URL or key. It names a service and an action, states a maximum cost, and Vaaya proxies the call with its own provider relationships. Revoking the agent's Vaaya key stops all of it at once.