How AI Agents Find Your Platform: ARD, MCP Registry, and What We Shipped

The Problem: Agents Are Blind by Default

Right now, when an AI agent needs a tool, it either has to be pre-loaded with a list of capabilities or the user has to manually add an MCP server to their config. That works for a handful of tools. It does not work when there are thousands of distributed capabilities across teams and organizations.

The current model is: hardcode it, embed it in the context window, or go without. This is the exact scaling failure that ARD (Agentic Resource Discovery) was designed to fix.

What ARD Actually Is

ARD is an open draft specification (v0.9, published May 2026) that defines how AI artifacts — MCP servers, agent cards, OpenAPI tools, skills — get cataloged, discovered, and searched across federated networks. It was announced by Google and developed collaboratively with Microsoft, Cisco, Databricks, GitHub, GoDaddy, Hugging Face, Nvidia, and Salesforce.

The core idea is a "search-first" paradigm. Publishers host a machine-readable manifest at /.well-known/ai-catalog.json on their own domain — a convention defined by RFC 8615 for well-known URI paths. Registries crawl and index those manifests. Agents query registries at runtime with a natural-language task description instead of pre-loading every possible tool.

The spec deliberately separates discovery from invocation. Once an agent finds a resource, ARD steps out of the way and the agent connects using the resource's native protocol — MCP, REST, A2A, whatever. It is not trying to replace any of those.

Worth being honest about the maturity: this is a v0.9 draft. The coalition behind it is large but most implementations are described as "future integration plans" rather than shipped deployments. It is spec-first, implementations-following. That also means being early here matters.

The spec lives at github.com/ards-project/ard-spec.

What We Shipped

Stackbilder now has two discovery endpoints live.

Layer 1: ARD well-known catalog

Any ARD-compliant crawler can hit https://aegis.stackbilt.dev/.well-known/ai-catalog.json and get a full structured manifest of our MCP server. No prior knowledge of Stackbilder required. The catalog advertises our three public surfaces: the MCP gateway, the img-forge image generation API, and the Stackbilder platform itself — each with representativeQueries that tell an agent whether we're relevant to what it's trying to do.

We shipped this in v2.24.0 alongside an aegis-core 0.8.3 update that blanket-exempts /.well-known/* from authentication. Per RFC 8615, well-known paths must be publicly accessible, and we aligned the gateway auth layer to enforce that going forward — so future additions like OIDC discovery or WebFinger won't need a code change.

Layer 2: MCP Registry listing

We are live in the official MCP registry under dev.stackbilt.mcp/gateway (v1.1.0). The listing points to our MCP server endpoint at https://mcp.stackbilt.dev/mcp and is backed by our public gateway repository.

The MCP registry is backed by Anthropic, GitHub, PulseMCP, and Microsoft. It feeds downstream aggregators including the GitHub MCP Registry — a browsable marketplace with one-click VS Code installation. GitHub's Agent Finder feature in Copilot pulls from this pipeline: official MCP registry → GitHub MCP Registry → Agent Finder index. Publishing once flows through all three surfaces.

What the MCP Server Actually Does

mcp.stackbilt.dev/mcp exposes 14 tools across four domains:

Image generation — image_generate, image_list_models, image_check_job. Thirteen models across five quality tiers: draft (SDXL Lightning, ~5s) through ultra_plus (Gemini 3 Pro, highest quality, Pro plan required). Supports txt2img, img2img, and inpainting. Job chaining via input_asset_url — no base64 round-trips. Permanent asset URLs on every response.

Cloudflare Worker scaffolding — scaffold_create, scaffold_publish, scaffold_deploy, scaffold_import, scaffold_classify. The full pipeline: plain-English description → structured project files → GitHub repo → live Cloudflare Worker, with zero manual steps. scaffold_import transpiles n8n workflow JSON directly into a deployable Worker.

Agent consulting — agent_consult, agent_inscribe, agent_recall, agent_entropy. C-level reasoning agents (CTO, CISO, CMO, CFO, CPO, Architect) with persistent memory decks. Each returns a structured analysis: stance, domain lens, constraint, action, confidence score. Memory is namespaced per role and tenant.

Billing — billing_status, billing_purchase_credits. Check remaining quota and plan tier, and — if the tenant has opted in — let an agent autonomously top up credits when a batch run is going to exhaust them.

Auth is OAuth 2.1 with PKCE (GitHub SSO, Google SSO, email/password) or Bearer tokens for non-browser clients.

The Two-Layer Discoverability Stack

Here is the architecture forming right now, and why both layers matter:

The MCP registry is the static metadata store — structured, explicit, install-time. Think of it as npm for MCP server metadata. It is how a developer browsing GitHub Agent Finder finds us and adds us to their config once.

ARD is the dynamic, semantic, runtime layer. Rather than pre-loading tools, an agent describes a task in natural language, queries a discovery index, and loads only what the current work requires. GitHub Agent Finder's ARD implementation is the first live example of this: Copilot discovers MCP servers at runtime based on what you are actually trying to do, without you having to pre-configure anything.

Publishing to the MCP registry feeds the static install path. Publishing /.well-known/ai-catalog.json feeds the ARD crawl path. They are complementary — not competing.

What This Means Today

If you use Claude, Cursor, or any MCP-capable agent: add https://mcp.stackbilt.dev/mcp to your MCP config and all 14 tools are immediately available — image generation at five quality tiers, Worker scaffolding from a sentence, C-level agent reasoning with memory. It just works. You can also browse the full tool surface on Stackbilder.

What is coming: as ARD indexers mature, agents will find us without you having to add the server manually. Describe a task — "generate a hero image for this blog post" or "scaffold a Cloudflare Worker that handles webhooks" — and an ARD-capable agent will surface Stackbilder as a candidate, connect, and execute. The well-known endpoint we published is what makes that possible.

The discoverability stack for the agentic web is forming. ARD handles runtime semantic search; the MCP registry handles structured ecosystem indexing. Both layers are live for Stackbilder. Being there early, while the crawlers are still sparse, means less competition for ranking when the traffic shows up.