[AGWAM001]

Summary

tests/mcp.test.ts still carries the four original paid_call tests. Three of them simulated the upstream with material no dependency produces, so the suite proved the classifier's branch selection works against shapes that never arrive. This rewrites those three fixtures to what the installed payment libraries actually throw and return. Fixture construction only — no titles, no assertions, no source files.

• ERR_EXPIRED_AUTHORISATION — the old message, Transaction signature expired. Signature expiration ledger 123 is less than current ledger 125, is not a string any dependency emits (grep -ri "signature expired" node_modules → nothing). @x402/fetch 2.24.0 rethrows a scheme failure as Failed to create payment payload: <cause> (dist/esm/index.mjs:48), and the SDK's expiry text is The transaction has expired (@stellar/stellar-sdk 13.3.0, lib/webauth/utils.js:124, thrown as InvalidChallengeError).
• ERR_PAYMENT_REJECTED — a rejected payment does not throw. The wrapper pays, retries and return secondResponse (@x402/fetch/dist/esm/index.mjs:80), so the seller's second 402 reaches the server as a Response with an x402 error body, not a { ok, status, text } stand-in.
• success — a settled call carries X-PAYMENT-RESPONSE, which PaymentLedger base64-decodes in src/mcp/ledger.ts:163. The previous stand-in had no headers property at all, so the call never entered the one code path that reads the settlement echo. It is now a real Response, and readBodyCapped consumes its stream the way it does in production.

The fourth is left as-is, deliberately. Horizon answers op_no_trust with BadResponseError, whose result_codes live at err.response.extras.result_codes, while extractStructuredSignal reads err.result_codes (src/mcp/codes.ts:118). Measured through the classifier, the faithful fixture returns ERR_BAD_REQUEST, not ERR_MISSING_TRUSTLINE. Flipping that assertion inside a tests-only PR would ship a behaviour change disguised as a fixture, so it stays, and the gap belongs in its own issue. Note that main's own describe('BazaarMcpServer paid_call error classification') block sets err.result_codes directly, so it exercises the same field no dependency actually populates.

Related issue

Closes #421 — its other four acceptance criteria landed with #521 (c55a980); this is the remaining "simulated errors resemble real ones" criterion. See the issue thread for the per-criterion audit.

Type of change

• Tests

Checklist

• I have read CONTRIBUTING.md
• npx tsc --noEmit passes — exit 0
• npm run build passes — prisma generate + tsc, exit 0
• I added / updated tests where relevant — npx vitest run tests/mcp.test.ts: 75 passed; full suite vitest run: 1445 passed | 1 skipped
• node scripts/check-dropped-tests.mjs origin/main HEAD — 1340 cases on base, 1340 on the merge result, exit 0
• I updated docs where relevant — no docs affected; no changeset either, since nothing here is user-facing

[AGWAM001]

review and magre pls

[Miracle656]

Merged as 07189a7, and this closes #421.

This is a small diff doing something genuinely valuable, which is the hardest kind to get credit for. The four paid_call tests were asserting against strings the test itself had written — so the text-matching in handlePaidCallError looked far safer than it is. A suite that invents its own inputs cannot tell you whether the matcher still lines up with what the libraries throw.

What I liked is that each replacement buys a code path the stand-in was skipping, not just realism for its own sake:

The expiry string reaches a different branch. paymentCouldNotHaveSettled tests a list of substrings. The invented 'Signature expiration ledger 123 is less than current ledger 125' matched 'signatureexpirationledger'. Your 'Failed to create payment payload: The transaction has expired' matches 'failed to create payment payload' — which is the branch the real client's rethrow actually hits, and it is the one that decides whether the ledger records the call as possibly-settled. That is a money-relevant classification, and it was untested.

fetchWithPayment does not throw on a rejected payment. Your comment says it exactly: it pays, retries, and hands back the seller's second response. So a 402 arrives as a resolved Response, not a rejection, and the old { ok: false, status: 402, text } object was testing a shape the code never sees.

A hand-rolled object has no Headers. The success test never ran the X-PAYMENT-RESPONSE decode, which is the only path that reads the settlement echo. Using a real Response with a base64url header is what makes that line covered.

And citing provenance in the comments — @stellar/stellar-sdk lib/webauth/utils.js for The transaction has expired — is the detail that makes this maintainable. The next person who sees a mapping break can check whether the library changed its wording rather than guessing.

Why this closes the issue

The other four acceptance criteria were already met by work merged earlier, which is easy to miss when the issue text predates it. For the record:

• bazaar_search — success (returns results from a permitted public host), empty (maps an empty resources array to ERR_NO_RESULTS, and the top-level-array variant), non-2xx (rejects a non-2xx response naming the upstream and status), malformed body (rejects a JSON content type with an unparseable body, plus the non-JSON content-type guard), and four SSRF refusals on top.
• ListTools — tells the caller what each tool costs and when not to reach for it and advertises schemas derived from Zod definitions.
• Unknown tool — returns structured ERR_UNKNOWN_TOOL error with valid tool names and the bounded-name variant.

"Simulated errors resemble real ones" was the one box left, and this is it. 76 tests in tests/mcp.test.ts now.

One observation, not a request

maps an empty resources array to ERR_NO_RESULTS treats "the node has nothing for this query" as an error. There is an open PR (#562) arguing it should be a successful empty collection instead, which I think is the better reading — an empty result is a valid answer, and clients should not have to catch an error to learn there were no matches. Not your problem here, and your test correctly pins current behaviour; flagging it so you are not surprised if that test is inverted later.

129 test files / 1,553 tests pass. tsc --noEmit clean.