DEV Community

Agenium platform
Agenium platform

Posted on • Originally published at agenium.net

Why MCP Without Agent Discovery Is Like the Web Without DNS

#mcp #ai #agents #opensource

You've built an MCP server. It works great — handles tool calls, serves resources, maybe even manages prompts. But here's a question nobody's asking:

How does another agent find yours?

Right now, the answer is: it can't. You share a JSON config, paste a URL in a README, or hope someone discovers your npm package. That's not discovery — that's word of mouth.

MCP solved the interface problem beautifully. But it left the identity and discovery problems completely untouched. And as the ecosystem grows from hundreds to thousands of MCP servers, this gap is becoming a real bottleneck.

The Problem: Directories List Tools, Not Agents

Open any MCP directory today — the official registry, awesome-mcp-servers, Smithery, Glama. What do you see?

A flat list of tools. Maybe categorized. Maybe with a description. But each entry is essentially a config snippet you copy-paste into your mcp.json:

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-weather"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

This works fine when you are manually configuring your Claude Desktop. But what about:

  • Agent-to-agent communication? Agent A needs to call Agent B at runtime, not at config time.
  • Dynamic discovery? A workflow that finds the best translation service right now, not the one hardcoded last week.
  • Trust verification? How do you know the server you're connecting to is who it claims to be?
  • Capability matching? Finding an agent that supports specific tools, protocols, or quality levels.

MCP directories are the Yellow Pages of the agent world. Useful, but not how the internet actually works.

What If Agents Had Addresses?

The web solved this problem decades ago with DNS:

google.com → 142.250.80.46
Enter fullscreen mode Exit fullscreen mode

A human-readable name that resolves to a machine-readable address. Boring infrastructure. Makes everything work.

Now imagine the same thing for AI agents:

agent://weather.tools → { endpoint, capabilities, trust }
Enter fullscreen mode Exit fullscreen mode

Not just an IP address — a full identity. Who is this agent? What can it do? Can I trust it?

Proposed: The Agent Schema

Here's the core idea. Every agent gets a manifest — think package.json, but for live AI services:

{
  "agent": "weather.tools",
  "version": "1.2.0",
  "protocol": "agent://",
  "endpoint": "https://203.0.113.5:8443",
  "capabilities": {
    "tools": ["get_forecast", "get_alerts", "get_historical"],
    "transports": ["http2", "grpc"],
    "protocols": ["mcp-1.0", "a2a-1.0"]
  },
  "identity": {
    "organization": "WeatherCorp",
    "verified": true,
    "cert_fingerprint": "sha256:abc123..."
  },
  "discovery": {
    "tags": ["weather", "forecast", "geolocation"],
    "description": "Real-time weather data for 200+ countries",
    "sla": "99.9%",
    "pricing": "free-tier-available"
  }
}
Enter fullscreen mode Exit fullscreen mode

This isn't just a config file — it's a contract. When you resolve agent://weather.tools, you get back everything needed to:

  1. Find it — DNS-style name resolution
  2. Verify it — mTLS certificates, organization identity
  3. Understand it — capabilities, tools, transport options
  4. Evaluate it — SLA, pricing, tags for search

Compare that to what MCP gives you today: a command string and some args.

How Resolution Works

When Agent A wants to call agent://weather.tools, three things happen:

Step 1: Resolve — The name maps to an endpoint + manifest

import { AgeniumClient } from 'agenium';

const client = new AgeniumClient();
const agent = await client.resolve('weather.tools');

// Returns the full manifest:
// agent.endpoint → "https://203.0.113.5:8443"
// agent.capabilities.tools → ["get_forecast", "get_alerts", ...]
// agent.identity.verified → true
Enter fullscreen mode Exit fullscreen mode

Step 2: Verify — mTLS handshake, both sides prove identity (zero-config)

Step 3: Communicate — Standard JSON-RPC over the secure channel

# Same thing in Python
from agenium import AgeniumClient

client = AgeniumClient()
agent = await client.resolve("weather.tools")
result = await agent.call("get_forecast", {"city": "Tokyo"})
Enter fullscreen mode Exit fullscreen mode

The MCP Bridge: No Rewrite Needed

You don't need to rebuild your MCP server. A bridge wraps your existing server and gives it an agent identity:

import { MCPBridge } from '@agenium/mcp-server';

const bridge = new MCPBridge({
  name: 'weather-tools',
  mcp: {
    transport: 'stdio',
    command: 'npx',
    args: ['-y', '@modelcontextprotocol/server-weather'],
  },
});

await bridge.start();
// Your MCP server is now agent://weather.tools
// Discoverable. Verifiable. Chainable.
Enter fullscreen mode Exit fullscreen mode

Same MCP server. New identity layer on top. Your existing tools, resources, and prompts all work — they're just accessible through a resolvable name now.

What This Enables

With named, discoverable agents, new patterns become possible:

Agent Chains: agent://translator.ai calls agent://search.tools calls agent://summarizer.ai — each resolved dynamically at runtime.

Capability Search: "Find me an agent that can process PDF documents and supports MCP 1.0" — returns a ranked list.

Trust Networks: Verified organizations publish agents. Consumers check identity before connecting. No more blindly trusting random endpoints.

Hot Swapping: Replace agent://old-weather.tools with agent://better-weather.tools without touching client configs. DNS-style redirection.

The Layer Map

Layer MCP Agent Discovery (proposed)
Interface ✅ Tools, resources, prompts —
Transport ✅ stdio, HTTP, SSE —
Identity ❌ ✅ agent://name.tld + schema
Discovery ❌ ✅ DNS-style resolution + search
Trust ❌ ✅ mTLS + verified orgs
Capability ❌ ✅ Manifest with tools/protocols

Not a replacement. A complement. MCP defines how agents talk. This layer defines who they are and how to find them.

We Need Your Input

Here's the honest part: we're not sure this is what developers actually need.

We've built this system (AGENIUM — open source, MIT licensed). 12 npm packages, Python SDK, 4 live demo agents, a working search engine. The tech works.

But does the problem resonate? We have questions for you:

  1. Do you struggle to find and connect to MCP servers/agents today? Or is copy-pasting configs fine?
  2. Would you use a schema like the one above? Or is it over-engineered for your workflow?
  3. What would you pay for reliable agent discovery? (Free tier? $10/mo? $0 forever?)
  4. What's the #1 thing missing from the MCP ecosystem that blocks your work?

We're running developer interviews (15 min, async-friendly). If you have opinions, reach out — we genuinely want to hear them.

🔍 Try our MCP server search → agenium.net/search — Find any MCP server in seconds.

AGENIUM is MIT licensed. We think agents deserve addresses, not just APIs. Tell us if you agree — or if we're solving a problem that doesn't exist.

Top comments (0)