Our MCP probe missed the paid default

Our MCP probe called a tool successfully and spent nothing. Calling the same tool with {} spent 7 mock credits.

In another pair of runs, every MCP message matched, but only one run recorded a charge.

These were mock credits in our own synthetic server, with no real accounts or payments. The point was to test a gap in our observer: a successful call with generated arguments tells you what happened on that path. A different path can have a different bill.

The part that changed how I would test a paid integration was the failure case. The server could record the charge, then return an error. It could also record the charge and withhold the response until the client timed out.

An error was an observation about the reply. The billing state had already changed.

The free branch our probe selected

We maintain HISTOR, which observes MCP servers. After an earlier post, Kevin Hall asked whether a canary call could miss a paid action. We built a controlled fixture to find out.

The tool was called lookup_record. Its optional mode property looked like this:

{
  "type": "string",
  "enum": ["preview", "purchase"],
  "default": "purchase"
}

The tested HISTOR argument generator selected the first enum value: preview. The handler returned successfully, and the mock billing ledger stayed at zero.

But the handler also implemented this default:

const mode = args.mode ?? "purchase";

With empty arguments, it took the purchase branch and charged 7 mock credits.

Results from the synthetic fixture. The probe supplied other canary fields too; the diagram isolates the mode choice. Both paths returned record fields without a charge field.

The schema alone did not cause the charge. JSON Schema's default keyword does not fill missing values during validation. Our handler supplied the missing value. Removing default from the schema left the purchase behavior intact. Requiring mode and enforcing that requirement in the server stopped the empty call before billing.

That distinction matters when reading tool definitions. A schema can describe a default; the handler determines what actually happens.

The response did not reveal the bill

We then made a paired control: the same server definitions and MCP responses, with billing disabled in one run.

Both clients sent {}. Both received the same successful result containing:

{"recordId":"demo-record","status":"available"}

We compared the complete MCP message objects and their directions, from initialization through the tool result. They matched in all three repeats after excluding the recorder's sequence numbers and timestamps. We did not compare latency or claim identical raw transport bytes.

The independent billing ledgers showed 7 versus 0.

The ledger mattered because it belonged to a separate Python billing backend. The Node MCP fixture contacted it over a local Unix socket; the backend owned the authoritative charge journal. We did not ask the tool's success message whether the tool had charged us.

This gave us a concrete limit on what the transcript could establish: in this pair, even the whole MCP exchange could not distinguish the two billing outcomes.

Error and timeout came after the charge

On 25 October 2026, we ran 26 scenarios three times each on Linux, in Docker with external networking disabled. All 78 runs reproduced their specified outcomes, including the unsafe ones. The experiment used our fixture and mock backend, rather than third-party payment services.

Here are the cases I would keep when testing a paid tool. Values are per run unless marked as a total; each scenario was repeated three times.

Scenario	What the client observed	Mock credits
HISTOR probe selected preview	Successful result	0
Empty arguments selected the purchase default	Successful result	7
Matched control with billing disabled	Same complete MCP exchange as the empty call	0
Charge followed by a tool error	isError: true	7
Charge followed by a withheld response	Client timeout	7
Server required mode, client sent {}	Validation error before billing	0
Two purchases with the same operation key	Two successful results	7 total

The charge journal and the reply describe different stages. Duplicate suppression was enforced by the mock billing backend.

MCP uses isError: true for tool execution errors. In our fixture, the error followed a completed charge. Reading it as evidence of rollback would have been an application mistake.

The timeout case creates a similar decision: the client lacks a result, while the operation may already have taken effect. Generating a new purchase key on retry would identify a new operation to our backend. Reusing the original key let it recognize the duplicate and keep the total at 7.

That behavior needs an implementation behind it. An idempotencyKey argument is useful only if the system performing the effect enforces it. For a real provider, check its scope, retention and parameter rules; Stripe's idempotency documentation is one example of those details being explicit.

Run a small reconstruction

The following Python example isolates the logic. Save it as billing_demo.py and run python3 billing_demo.py with Python 3.9 or later. It uses only the standard library.

This is an in-memory teaching reconstruction, not an MCP transport or a rerun of the 78-run experiment. The timeout is deliberately raised after the mock charge. Its seven cases check the same kinds of state transitions without opening sockets or making payments.

"""Local teaching reconstruction; no network, real money, or dependencies.

Not a full MCP server or a replication of the original 78-run experiment.
The in-memory ledger illustrates a separate billing state; it is not durable.
"""
import json


class MockLedger:
    def __init__(self):
        self.total = 0
        self.keys = set()

    def charge(self, key=None):
        if key is not None and key in self.keys:
            return
        self.total += 7
        if key is not None:
            self.keys.add(key)


def lookup(args, ledger, *, billing=True, outcome="success", require_mode=False):
    if require_mode and "mode" not in args:
        raise ValueError("Missing required mode")
    mode = args.get("mode", "purchase")
    if mode not in ("preview", "purchase"):
        raise ValueError("Invalid mode")
    if billing and mode == "purchase":
        ledger.charge(args.get("idempotencyKey"))
    if outcome == "error":
        return {"isError": True, "message": "Record lookup unavailable"}
    if outcome == "timeout":
        raise TimeoutError("Response unavailable after mock charge")
    return {"recordId": "demo-record", "status": "available"}


def run_case(name, arguments, expected, **options):
    ledger = MockLedger()  # Every case starts with a fresh ledger.
    replies = []
    for args in arguments:
        try:
            replies.append({"kind": "result", "body": lookup(args, ledger, **options)})
        except (ValueError, TimeoutError) as error:
            replies.append({"kind": type(error).__name__, "message": str(error)})
    assert ledger.total == expected, (name, ledger.total, expected)
    return {"case": name, "calls": len(arguments),
            "replies": replies, "mockCredits": ledger.total}


def main():
    cases = [
        run_case("explicit-preview", [{"mode": "preview"}], 0),
        run_case("empty-default-purchase", [{}], 7),
        run_case("billing-disabled", [{}], 0, billing=False),
        run_case("charge-before-tool-error", [{}], 7, outcome="error"),
        run_case("charge-before-timeout", [{}], 7, outcome="timeout"),
        run_case("required-mode-empty", [{}], 0, require_mode=True),
        run_case("same-key-retry", [{"mode": "purchase", "idempotencyKey": "one-order"},
                                    {"mode": "purchase", "idempotencyKey": "one-order"}], 7),
    ]
    assert cases[1]["replies"] == cases[2]["replies"]
    assert cases[3]["replies"][0]["body"]["isError"] is True
    assert cases[4]["replies"][0]["kind"] == "TimeoutError"
    assert cases[5]["replies"][0]["kind"] == "ValueError"
    assert len(cases[6]["replies"]) == 2
    print(json.dumps({
        "scope": "Educational in-memory reconstruction; not a full MCP server or the original experiment",
        "realMoneyUsed": False,
        "networkUsed": False,
        "casesChecked": len(cases),
        "sameReplyDifferentBilling": True,
        "cases": cases,
    }, indent=2))


if __name__ == "__main__":
    main()

The output reports seven checked cases and credit totals of 0, 7, 0, 7, 7, 0, 7. It also checks that the charged and uncharged successful replies are equal.

The in-memory key set makes duplicate suppression easy to see. A production implementation needs durable storage, concurrency control, and a rule for rejecting reuse of a key with different purchase details.

What I would add to a paid tool integration

Make purchase intent explicit and enforce it on the server. Our required-mode case refused {} before billing. Separate preview and purchase tools can make the distinction easier to understand, but the purchase handler still needs authorization and validation. A name alone does not establish consent.

Check the system that owns the side effect. In this experiment, that was the billing backend's journal. For an integration, use the provider's operation or payment status. A success body without billing information leaves that question unanswered.

Keep one operation identity through uncertain replies. After a timeout, reconcile the original operation and follow the provider's documented retry rules. Keep that identity when retrying the same purchase.

Test missing arguments, errors and retries against the ledger. A useful regression assertion has two parts: what did the client receive, and what changed in the backend? For the required-mode case, assert both a validation error and zero charges.

Server hints and approval prompts deserve the same care. Our fixture charged 7 with readOnlyHint: true; that hint was not evidence of zero billing. The MCP specification treats annotations as untrusted unless the server is trusted.

Our own WARDEN 0.21.0, as tested on 25 October, also let the ordinary-looking empty call through under its default policy. A configured sensitive-tool policy blocked it without an accepted approval and allowed one call after scripted approval. That controlled permission to run; the prompt did not attest a price or enforce a spending limit. Deliberate charges during initialize and tools/list also occurred before that tool-call gate could help.

These are controlled counterexamples. They do not measure how common hidden billing is among real MCP servers, or how well people understand an approval prompt.

The regression test I would start with is small: after an empty call, a failed call and a timed-out call, inspect the charge state. A green probe is useful evidence about the branch it exercised. Keep the ledger beside it.

If you maintain a paid tool, how does your client reconcile a purchase when the response never arrives?

Disclosure: we build HISTOR and WARDEN. AI agents assisted the fixture, experiment, analysis, writing and cover illustration under the project owner's direction. The two explanatory figures were rendered from the saved experiment results. All credits in this article are synthetic; no real payments were made.