_a
Agent Identity & Discoveryv1.0.0

the 0-th hop for agent discovery.

Discovery and origin verification for agents and their tooling.

_agent.example.comTXT
u=https://example.com/mcpwhere
p=mcpwhat protocol
k=z7rW8rTq8o4mM6vVf7w…proof · Ed25519
Try the resolverRead the specification
9 protocols/6 SDKs/MIT
$npm install @agentcommunity/aid

How agents use it

Three ways an agent reaches out

agentagent

Reach another organization's agent.

_agent.acme.com → p=a2aone DNS lookup
agenttool

Reach a system's API or MCP server.

_agent.example.com → p=mcpone DNS lookup
agentcapability

Find any agent that can do a thing.

list + sort across many agentsbuilds on AID

AID answers the first two directly. One DNS lookup gives the endpoint, the protocol, and the proof. Capability search is a directory that builds on top of AID, not inside it.

The problem

Agents are flying blind

An agent reaching a new system shouldn't need a PhD in API archaeology.

Agents burn tokens guessing

With no map, an agent retries dead endpoints and scrapes docs just to find the way in.

No way to verify the endpoint

Nothing proves the server an agent reached is the one the domain intended.

Protocol guesswork

MCP? A2A? OpenAPI? The agent has to probe, or be told out of band.

No discovery standard

Every agent-to-system link is hand-wired, one integration at a time.

The solution

How AID solves it

One DNS record. Discovery, protocol, and endpoint proof.

01

One DNS TXT record

Add a single _agent.example.com TXT record. No registries, no APIs, no complexity.

Quick StartSpecification
02

Instant discovery

Any client resolves the _agent subdomain to your endpoint. Falls back to .well-known/agent when DNS is restricted.

Discovery APITroubleshooting
03

Protocol-agnostic

Works with any agent protocol. Change the p= token in your record.

mcpa2aopenapigrpcgraphqlwebsocketucp
MCP GuideA2A GuideProtocols
04

Agent identity

Publish a public key (PKA) and let clients verify your endpoint with HTTP Message Signatures (Ed25519).

Identity & PKASecurity

Identity

Public key for agents

DNS tells a client where to connect. PKA lets it verify who is on the other end.

How it works

Keys use single-letter aliases for byte efficiency (u for uri, p for proto).

  1. 1Publish k (public key) and i (key id) in your TXT record
  2. 2Client sends an AID-Challenge to your uri
  3. 3Server returns an HTTP signature (Ed25519) covering the request
  4. 4Client verifies the signature using k
Learn morePKA as an external trust anchor
DNS record
Name
_agent.example.com
Type
TXT · TTL 300
Value
v=aid1;u=https://api.example.com/mcp;p=mcp;k=z7rW8rTq8o4mM6vVf7w…;i=g1

One TXT record at the _agent subdomain. The same shape your DNS provider already understands.

Quick start

Discover, publish, validate

In minutes, from your language of choice or the CLI.

discover
import { discover } from '@agentcommunity/aid'

const { record } = await discover('example.com')
console.log(record.uri) // https://api.example.com/mcp
Need more? Read the full Quick Start guide →

Tooling

Developer toolkit

SDKs in six languages, plus a CLI, a conformance suite, and a browser workbench.

SDKs

$ npm install @agentcommunity/aid
Quickstartnpm

Tools

Vision

Where AID fits

A small, boring discovery layer that other systems build on.

A discovery layer agents can rely on

When an agent meets a domain it has never seen, it can find the endpoint, learn the protocol, and verify the endpoint before connecting. No documentation hunt, no bespoke integration code.

  • Works in public or private DNS
  • Endpoint proof with Ed25519 (PKA)
  • Composes upward to OAuth and MCP
  • Zero config for the client

Open-source agent infrastructure

We're building a vendor-neutral stack for hosting, scaling and observing agents. Curious? Get involved at agentcommunity.org.

  • MIT-licensed core
  • Self-host or cloud
  • Token registries & open index
  • Community governance
View the roadmap