Why MCP Without Agent Discovery Is Like the Web Without DNS

Source: Dev.to

You’ve built an MCP server. It works great—handles tool calls, serves resources, maybe even manages prompts.
But 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—it’s word‑of‑mouth.

MCP solved the interface problem beautifully, but it left the identity and discovery problems completely untouched. As the ecosystem grows from hundreds to thousands of MCP servers, this gap becomes a real bottleneck.

The Current State

Open any MCP directory today—official registry, awesome‑mcp‑servers, Smithery, Glama. You see:

• A flat list of tools (maybe categorized, maybe with a description).
• Each entry is essentially a config snippet you copy‑paste into your mcp.json:

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

This works fine when you manually configure your Claude Desktop, but it falls short for:

• 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 hard‑coded 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.

Inspiration: DNS

The web solved this problem decades ago with DNS:

google.com → 142.250.80.46

A human‑readable name resolves to a machine‑readable address. Boring infrastructure, but it makes everything work.

Imagine the same thing for AI agents:

agent://weather.tools → { endpoint, capabilities, trust }

Not just an IP address—a full identity.

Core Idea: Agent Manifests

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"
  }
}

This isn’t just a config file—it’s a contract. When you resolve agent://weather.tools, you receive 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 It Works

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

Step 1 – Resolve

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

Step 2 – Verify

Perform an mTLS handshake; both sides prove their identities (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"})

Bridging Existing MCP Servers

You don’t need to rebuild your MCP server. A bridge wraps the 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.

Same MCP server, new identity layer on top. Your existing tools, resources, and prompts keep working—they’re just accessible through a resolvable name now.

New Patterns Enabled

Comparison Matrix

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

We Need Your Feedback

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 with 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 right now?

Your answers will shape the next generation of agent discovery. 🙏

Thank you for reading. We look forward to building a more discoverable, trustworthy AI agent world together.

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.

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.