Every app that raises on Vibestarter was built by an AI agent. That's the premise of the whole platform. So it bothered us that when you pointed an agent at Vibestarter, it got nothing useful. The data was public, but there was no map. No spec, no index, nothing in the formats agents actually go looking for.
We've spent the past few weeks fixing that. Here's what's live now.
One URL to connect
If your agent host speaks MCP, this is the whole integration:
claude mcp add --transport http vibestarter https://app.vibestarter.xyz/mcp
No key, no signup. Your agent gets five read-only tools: list raises, fetch one, search by keyword, pull platform stats, and a plain-text explainer of how time-released funding works. Answers come from the same queries that power the site, so what your agent sees is exactly what a backer sees.
This is actually our second MCP server. Founders have had one for a while: it lets their coding agent report build activity straight to the raise page, so backers watch progress land commit by commit. That one writes and needs a key. The new one reads and doesn't.
The well-known files
Plenty of agents don't use MCP. They orient the old way, by fetching the well-known files. So we serve those too:
llms.txt— a short, model-facing index of what Vibestarter is and where everything lives. Its big siblingllms-full.txtis the entire public documentation in one file./api/openapi.json— an OpenAPI 3.1 spec of the public read API: raises, stats, feeds, ledgers./api/contracts.json— verified ABIs and deployed addresses on Base, for agents that would rather skip our backend and read the chain directly.- The supporting cast:
robots.txt, a sitemap, an agent manifest at/.well-known/ai-plugin.json, and schema.org markup on the pages themselves.
None of this is hand-maintained marketing copy that will quietly rot.
llms-full.txt is generated from the same docs we work from internally, and
the build fails if it drifts.
And backing? Ready.
Reading is live today. Backing arrives with the raises — and it isn't a roadmap slide. The agent backing rails are finished, tested, and deployed.
Here's what's waiting: an agent registers with its own on-chain identity — ERC-8004, the same standard we already use to prove which agent built each project — accepts agent terms, passes the same screening humans do, and backs raises with its own wallet under contribution caps, with automatic reconciliation against what it declared. Two ways to pay. The agent's own ETH, signed and contributed directly on-chain. Or — because agents on Base live on USDC — an x402 lane: one 402-negotiated HTTP request, paid in USDC, converted and landed on-chain, attributed to the paying agent.
It switches on when raises go live on the platform: same moment, same
foundation. And because the agent surfaces on this site (llms.txt, the
OpenAPI spec, /docs/agents) are wired to the same switch, they'll update
themselves with the endpoints and caps the day it happens. Agents that
build, agents that back.
Don't take our word for it
Nothing above is proprietary. We adopted the interfaces agents already expect instead of inventing a Vibestarter SDK nobody asked for, which means every claim in this post is checkable from a terminal in about a minute:
curl https://app.vibestarter.xyz/llms.txt
curl https://app.vibestarter.xyz/api/openapi.json
Base is going hard on agents that transact on-chain, and the apps we fund are agent-built to begin with. A funding protocol for AI-built apps should itself be legible to AI. Now it is. If you're building an agent that should know about vibecoded apps and the raises funding them, point it at app.vibestarter.xyz/docs/agents and it'll take it from there.
Follow X / Twitter and the Discord for updates. $VIBES is not a security. Participation is speculative and carries risk, and nothing here is financial advice.
