What happens when an agent spends your credits

You click a button. If it costs more than you expected, you notice — you're standing right there. An agent calling the same tool doesn't have that instinct. It's working through a task, it hits a step that needs keyword data, it calls the tool, it moves on. Nobody's standing over its shoulder wondering if 40 credits was a lot to spend on one lookup.

That's not a hypothetical. It's the actual shape of running research through an agent instead of a browser tab, and it's the reason we didn't just wrap the dashboard's API and call it an MCP server.

The same meter, called from somewhere else

Nextrank's MCP server exposes three tools — research, save, track — against the same organisation, plan and credit balance the web app uses. Not a parallel system with its own limits to lose track of. The same one.

That matters because the reserve-then-settle mechanic that runs every paid button in the dashboard runs underneath every agent tool call too:

1. Estimate the cost from the parameters before anything is spent.
2. Reserve the credits — refuse the call outright if the balance can't cover it.
3. Fetch the data.
4. Settle the hold to the real cost, refund the difference, release it entirely if the call failed.

An agent doesn't get a softer version of this. It gets exactly what the dashboard enforces, because it's calling the same code path, not a lookalike.

What the agent actually sees

The part we did build specifically for agents: every tool response reports what the call just spent and what's left in the balance. Not a side panel the agent has to go check — the number is in the response it already has to read to do its job.

{
  "result": { "...": "keyword data" },
  "credits": { "spent": 21, "remaining": 340 }
}

That's a deliberate design choice, not a side effect of logging something. An agent working through a multi-step research plan — research a seed phrase, then three related ones, then save the winners — is making four or five tool calls without a human reading a dashboard in between. If it can't see the running total in the same payload that has its results, it has no way to notice a plan that's about to blow through a balance until the fifth call gets refused. With the total in every response, it can decide to stop after three.

Reads are still free

Listing projects, reading saved keywords, checking what a tracker found — none of it costs a credit, agent or not. The whoami call that confirms a key works costs nothing either. Credits are for the same three things they're for in the dashboard: keyword research, metric refresh, and ad-hoc lookups. An agent that's just reading your existing data back to you never touches the balance.

Why this is the whole point, not a feature of it

Plenty of tools are adding an MCP server right now because agents are where usage is heading and nobody wants to be left out. Fewer of them are asking what changes when the thing clicking "run search" doesn't have a person's judgment behind it. We think that's the actual question. An agent that can't see its own spend, or that hits a hard stop with no explanation, is worse than useless in a loop — it either burns a budget silently or breaks the task it was given.

Building the estimate-reserve-settle sequence into the product's billing core rather than its frontend meant we got agent-safe spending for free the day the MCP server shipped. That ordering — mechanism first, then the two doors into it — is the actual differentiator, not the existence of an MCP server. Plenty of tools have one of those now.

If you want to see it directly: connect Claude Code, Cursor, or any MCP client with a free API key and ask it whoami, then have it estimate a search before running one. Read comes back with your real balance; the estimate comes back with a real number, before anything is spent.