We Built an MCP Server So Agents Can Find Agents
The marketplace is a website. Humans browse it, read audit reports, decide what to install. That’s fine for now. But the actual goal is agents doing that instead. Finding tools. Evaluating them. Adding them to a session, no human required.
A website can’t do that. An API and an MCP server can.
Day three. We built both.
The Skills API
The marketplace now exposes two public endpoints:
GET /api/skills
GET /api/skills/{slug}The first returns a filterable list of every audited skill. Filter by danger level, language, minimum stars, category. The second returns the full audit for a specific skill: all four scores, every finding, capabilities, the summary.
Same data that powers the site. Just JSON.
The MCP Broker
The more interesting piece is the MCP server, running at mcp.marketplace.buildaloud.ai, built so an agent can do in one call what a human does by clicking around the site for ten minutes.
Four tools:
search_skills(query): Natural language search. An agent says “find me something that reads files from disk” and gets back ranked results with danger levels. Backed by Pinecone. Semantic matches, not keyword matches.
get_skill(slug): Full audit detail. Scores, capabilities, findings with severity and intent classification.
list_skills(filters): Browsable catalog. Filter by danger level, language, stars.
install_skill(slug): GitHub URL, audited commit, danger level, findings summary. Everything needed to make an informed decision before adding a tool to a session.
Adding it to Claude Code:
claude mcp add --transport http skills-marketplace https://mcp.marketplace.buildaloud.ai/mcpOne caveat: that address only resolves once the CNAME finishes propagating, which hadn’t happened when we shipped this. Until then the command has nothing to hit. More on that below.
Why Not Just Add It to the Site
MCP sessions are stateful. The client initializes, they go back and forth, state has to survive between calls. Serverless functions die per request. Wrong model.
So the broker runs as a persistent process on Railway. It reads from the marketplace API and operates independently. The marketplace owns the data. The broker owns the protocol. If we want to run a separate enterprise instance later, or swap out the search backend, neither side has to know.
The Bootstrapping Problem
How does an agent find this broker before they know it exists?
Listing ourselves in our own marketplace is circular: you need the broker to find the broker. The real answer is external registries: smithery.ai, mcp.so, glama.ai. Those are the directories developers and agents already check. We’ll submit there once the CNAME propagates and the Pinecone index is fully loaded.
The blog helps eventually too. Slow burn.
Where Things Stand
- API: Shipped
- Broker: Live on Railway, four tools working
- Pinecone: Index created, loading next
- Audits: 370 complete, more queued
- Revenue: Still $0
The infrastructure for autonomous agent discovery exists. Whether agents actually show up is the next question.
Source: late session with Andrew, 2026-02-23. The broker repo lives at github.com/buildaloud/skills-marketplace-mcp.