Proposal discussion (if anyone reads these?): an agent-facing graph CLI. If DoorDash can do it, so can we

Questions & Feedback
1

Yesterday DoorDash’s co-founder announced dd-cli, a CLI that lets agents order DoorDash directly: search stores, find deals, check out, end to end (announcement). A food delivery company just shipped a first-class agentic surface for its marketplace.

The demand side isn’t hypothetical. x402 crossed 100 million agentic transactions on Base in roughly three quarters per Chainalysis, and by April the protocol-wide numbers were around 165 million transactions across ~69,000 active agents with ~$50M in cumulative volume. Fair to note some of that is testing and farming noise, but even the conservative read is that agents with wallets are already paying for services at scale. The rail exists, the buyers exist. What’s missing on our side is the on-ramp.

The Graph already has a CLI that every subgraph developer uses (@graphprotocol/graph-cli). It’s built for humans authoring and deploying subgraphs. What it doesn’t do is serve the fastest-growing consumer of on-chain data: agents. I think we should close that gap, and most of the pieces already exist.

The pitch

Extend (or ship a companion to) graph-cli so that an agent in Claude Code, Codex, or any harness can complete the full loop without a human in the middle:

1. Discover: graph search <query> / graph registry lookup <contract|topic|chain>

Agents can’t use data they can’t find. Discovery should return machine-readable results: deployment IDs, schemas, indexed chains, health/reliability signals. This layer already exists in prototype form: subgraph-registry-mcp does registry search with reliability scoring and schema fingerprinting over MCP today (full disclosure: I built it). Point being, this isn’t speculative. The discovery mechanics are proven; they just aren’t first-party.

2. Query & pay: graph query <deployment> <graphql> --pay x402

Two payment paths, both wallet-native:

  • x402 per-query: agent hits the gateway, gets a 402 challenge, signs a USDC payment, gets data. No signup, no dashboard, no human. The Graph already has an x402 gateway live on Base. This is about making it a first-class CLI path rather than something you have to know about.
  • API key provisioning: graph auth create-key --wallet <addr>. An agent with a wallet funds a billing balance and mints its own API key programmatically. Today key creation assumes a human in Subgraph Studio. An agent shouldn’t need a browser session to become a paying customer.

3. Build: graph scaffold --contract <addr> --chain <chain>

This is the step nobody else’s marketplace has an analog for, and it’s where The Graph’s moat is. If an agent searches the registry and the subgraph it needs doesn’t exist, the CLI should help it create one: introspect the verified contract ABI, scaffold schema + mappings, deploy to the network, and pay for indexing via x402 or its wallet balance. graph init already does most of the scaffolding for humans; the delta is making the flow non-interactive, ABI-driven, and payable.

Discover, query, pay. And when the data doesn’t exist yet: build, deploy, pay. A closed loop where agents are self-serve customers of the network.

Why this matters now

  • Demand-side story. We spend a lot of energy on supply (indexers, chains, data services). Agentic consumers are the demand curve that’s actually inflecting. DoorDash’s CTO framing was that the company has to “earn the right” to serve agents as customers. That pressure applies to data infrastructure at least as much as burritos.
  • The unit economics fit. Agent queries are exactly the shape TAP/GraphTally and x402 were built for: high-frequency, low-value, trust-minimized. We have the payment rails; we’re missing the on-ramp.
  • Subgraph creation as agentic primitive. Every other data API is static from an agent’s perspective. The Graph is the only network where an agent can provision new indexed data on demand. That’s a genuinely differentiated capability and right now it’s locked behind human-oriented tooling.
  • Timing. Anthropic, OpenAI, and others are shipping agent harnesses that load CLIs and MCP servers natively. Whoever makes their marketplace easiest for agents to transact with wins default status. dd-cli is a signal that mainstream companies see this; crypto-native networks with programmable payments should be ahead of them, not behind.

What already exists vs. what’s needed

Piece Status
Human CLI (graph-cli: init, codegen, deploy) Exists
Registry discovery w/ reliability + schema fingerprints Community prototype (MCP), needs first-party home
x402 pay-per-query gateway Live on Base
Programmatic API key + billing via wallet Studio-centric today, needs headless path
Non-interactive, ABI-driven scaffold + deploy + pay The new build
MCP wrapper so the same commands work as tools Partial, fragmented

This is mostly integration and packaging work, not new protocol design. It could live as a graph agent subcommand family, a separate graph-agent-cli, or CLI + MCP shipping from the same core. Open to opinions on the right shape.

Worth noting the CLI doesn’t have to be a standalone build. I’ve been sketching a broader MCP federation design on Horizon (shared discovery layer plus a single access rail handling both API keys and x402), and the CLI slots in naturally as just another frontend to that same core. Same registry, same payment guard, whether an agent reaches it via CLI or MCP. Architecture doc here: MCP Federation on Horizon.

Open questions for the community

  1. Should this live in graph-cli proper or as a companion package? (dd-cli shipped standalone; there are arguments both ways.)
  2. Who owns first-party registry/discovery? Edge & Node, another core dev team, or a funded community effort?
  3. For agent-built subgraphs: any guardrails needed on network side (spam deployments, curation implications), or do existing economics handle it?
  4. Is headless key provisioning something the Studio team already has on a roadmap?

Curious whether core devs and other builders see this the same way. If a food delivery app can make itself agent-native in a limited beta, a decentralized data protocol with programmable payments has no excuse.

Links

1 Like