!
Beta Environment Notice
TDM is currently in Beta. Exercise caution when handling assets. Use at your own risk.
Fast Export
Switch the current page to Markdown for fast agent reading, or download it as a .md file.
TDM is currently in Beta. Exercise caution when handling assets. Use at your own risk.
Fast Export
Switch the current page to Markdown for fast agent reading, or download it as a .md file.
# TDM Protocol Specs Summary: Public protocol guide for TDM. This page documents the SDK and CLI surface, the MCP session-state helper, AgentPay interoperability guidance, and the published HTTP API. Status: Public protocol documentation Topics: - TDM protocol documentation - SDK and CLI surface - MCP session-state runtime - agent payment interoperability Packages: - tdm-sdk - bundled-mcp-runtime - tdm-agentpay Commands: - tdm connect - tdm fuel - tdm sweep - tdm stats - tdm_get_session_state
This page documents only the public TDM contract. It focuses on installable packages, published commands, and documented HTTP requests.
The main SDK package. It includes the SDK APIs and the built-in tdm CLI.
A narrow MCP helper for agent runtimes that exposes tdm_get_session_state.
Public interoperability guidance for agent builders integrating with authorize outcomes and payment recovery flows.
Public discovery and buy-entry adapters that expose TDM-paid resources to external protocol ecosystems without replacing the TDM checkout and authorize flow.
TDM does not need a separate formal spec to be useful today. The current public contract is already stable enough for protocol-first integrations: one authorize request, one machine-readable 402 shape, one checkout path, and one retry path back into authorize or delivery.
The tdm CLI is included in tdm-sdk. In public docs it is usually clearer to describe them together, then call out CLI-only commands when needed.
TDM can publish the same payable resource into external discovery surfaces without moving settlement out of TDM. The bridge layer is for visibility and buy-entry routing, while checkout, authorize, and unlock stay canonical inside TDM. In practice that means resources can be discovered outside TDM, bought through lightweight entry paths, and then used more deeply inside TDM-native runtimes.