Skip to content

Remove the flat-fields back-compat shim from _meta.x402 once all consumers read accepts[] #892

@MQ37

Description

@MQ37

Problem

X402PaymentProvider.decorateToolSchema advertises every paid tool's _meta.x402 in two shapes: the spec-shaped accepts[] array AND a flat copy of the preferred entry's fields (scheme, network, amount, ...). The flat shape is a back-compat shim for pre-#876 clients that don't iterate accepts[].

// src/payments/x402.ts
metaRecord.x402 = {
    paymentRequired: true,
    ...(preferred ?? {}),         // flat back-compat fields
    ...(accepts && { accepts }),  // spec-shaped array
};

Two shapes for the same data invites drift (which scheme is "preferred"? both clients diverge over time) and forces every reader to handle both branches. The flat fields also can't express more than one scheme, so any new scheme support requires accepts[] anyway.

Fix

Drop the flat fields once every consumer reads accepts[]. Known consumers to confirm first:

  • apify/mcpc ≥ the release that lands PR #238 (uses accepts[] end-to-end).
  • apify/actor-agentic-payments-tester x402 canary ≥ PR #2 (uses accepts[]).
  • Any third-party MCP client we know of that reads _meta.x402 (none on file — please confirm before removal).

After the consumer matrix is green, this PR is a 5-line change: drop the flat spread + the selectPreferredAcceptEntry helper + the four flat-field assertions in the integration suite.

Out of scope

The accepts[] itself, the structuredContent in 402 tool results, and the upto scheme support all stay — only the duplicated flat fields go.

Metadata

Metadata

Assignees

Labels

t-aiIssues owned by the AI team.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions