AgentRoot

AgentRoot does not have free or paid API tiers today. All read endpoints, including the legacy `/api/discover` discovery endpoint, share a single IP-based throttle of **1000 req/min per IP** unauthenticated, with a **burst allowance of 100 requests in 10 seconds**. Higher tiers via API keys are planned for v3.1. Write endpoints (`POST /api/submit`) are limited to 60 req/hour per IP regardless of authentication state.

Source: /docs/limits

AgentRoot does not use signing keys for records itself—DNS is the root of trust. However, if you publish signed payloads (e.g., signed JSON Web Keys at your A2A endpoint), AgentRoot recommends keeping the old key valid for **7 days** after rotating to the new key, so in-flight consumers can complete operations. The documentation notes you can adjust this based on your threat model (e.g., 24 hours for finance/PII flows, 30 days for low-stakes content APIs).

Source: /docs/security

The `_agentroot` TXT record must start with the version prefix `v=ar1` (protocol version 1). You cannot paste the JSON capability manifest directly into the TXT record. There are two valid modes: (1) Manifest mode — the TXT record contains `v=ar1 manifest=https://<domain>/.well-known/agentroot.json` and the JSON manifest is hosted at that URL. (2) Inline mode — for a single record, the TXT record contains the fields directly as key=value pairs (e.g., `v=ar1 type=agent name=MyBot endpoint=https://example.com/api`) with no separate JSON manifest file.

Source: /docs/protocol/dns, /docs/protocol/dns, /docs/protocol/dns

AgentRoot queries a single recursive resolver in the indexing region (currently `sin1` / `iad1` Vercel functions, falling back to system DNS). It does not perform multi-resolver consensus — if your authoritative DNS returns a valid `_agentroot` TXT record, the record is considered verified. Therefore, it is neither a simple majority nor a fixed quorum; verification relies on one resolver node.

Source: /docs/security

The registry API endpoints default to 20 items per page and enforce a maximum limit of 100 items per request.

Source: /docs/api, /openapi.yaml

The recommended default TTL for stable production is 3600 seconds (1 hour). If you are actively iterating on records, use 300 seconds (5 min); for long-term stable records that rarely change, use 86400 seconds (24 hours). AgentRoot's resolver re-queries DNS on every search request, so a low TTL costs you nothing in performance on AgentRoot's side — it only means downstream caches (other AI agents, DNS resolvers) will see your changes faster.

Source: /docs/protocol/dns, /docs/protocol/dns

A DNS TXT record at `_agentroot.<domain>` is always required to prove domain ownership; uploading a file to `.well-known` is never sufficient by itself. The `.well-known/agentroot.json` file is only required when using manifest mode, where the DNS record points to it via `manifest=<url>`. In inline mode, the TXT record contains all fields directly and no `.well-known` file is needed. The DNS record takes precedence as the root of trust — the manifest is trusted only because the DNS record points to it — and domain ownership is provable only via DNS with no email or file-upload alternative.

Source: /docs/protocol/dns, /docs/protocol/dns, /docs/protocol/dns, /docs/security

AgentRoot's protocol docs state that v2 (`ar2`) does not currently exist or is in active development. When v2 is introduced, the resolver will accept both v1 (`ar1`) and v2 records concurrently for at least 12 months from the v2 launch date. During the overlap, mixed deployments are supported, and `ar1` records published today will continue to be valid until that 12-month overlap ends. The docs explicitly state: 'We do not break `ar1` before then.'

Source: /docs/protocol/versions

Most agents appear in the global registry within 2–3 minutes of submission, assuming the `_agentroot` DNS TXT record is already propagated. The breakdown is: DNS verification within ~30 seconds, manifest fetch 1–2 minutes, and search indexing 1–2 minutes. If you just added the TXT record, DNS propagation itself can take anywhere from 15 seconds to 24 hours depending on your provider’s TTL (the DNS docs note 1–5 minutes is typical, but it can take up to 48 hours). The site also gives a practical timeout threshold: if your domain isn’t appearing after 5 minutes, verify the DNS record with `dig`, check the manifest URL returns valid JSON, and re-submit via `POST /api/submit` to trigger immediate re-verification.

Source: /publish, /publish, /docs/protocol/dns

Installing a skill installs it to your local environment and applies across all AI tools on that machine—it is neither registered globally for your entire domain nor scoped to a specific agent. The install-skill page states it installs skills ‘to your local environment for use with Claude Code, Codex CLI, Gemini CLI, Cursor, or any agent platform’ (chunk [2]), and the manifest describes list-installed as listing ‘all AgentRoot records installed on this machine across all AI tools’ (chunk [6]), indicating the scope is per-machine and spans all agents.

Source: /skills/agentroot.io/install-skill, /manifest/agentroot.io

AgentRoot does not currently emit outbound webhooks; the registry is read-only and consumers must poll `/api/discover` or use MCP tools. Webhook delivery is planned for v3.1. When it ships, the contract will be: at-least-once delivery (consumers must handle duplicates via the `event_id` header); exponential backoff retries at 1 minute, 5 minutes, 25 minutes, 2 hours, 8 hours, and 24 hours; delivery is marked failed after 6 retries and logged to the `webhook_delivery_log` table, with the next event resuming delivery attempts.

Source: /docs/limits

AgentRoot does NOT enforce mutual TLS for A2A endpoints. The platform treats A2A endpoints as opaque URLs published by the domain owner, and the protocol used at that endpoint—including auth, mTLS, signed requests, or JWT—is the responsibility of the endpoint operator. If your use case requires mTLS, you must configure your own endpoint to require client certs and document the auth requirement in your manifest's `auth` field.

Source: /docs/security

No. The 90-day threshold applies only to records that have **failed DNS verification** for 90 consecutive days. After 90 days of consecutive failed verification, a record is treated as abandoned—it remains in the database with `status: 'failed'` but is excluded from default search results. If your DNS record is valid and simply stays unchanged, AgentRoot automatically re-verifies it every ~6 hours, so it stays active and you do not need to set up health check pings.

Source: /docs/registry/lifecycle, /docs/registry/lifecycle

AgentRoot does not resolve such conflicts. The docs state that "AgentRoot is a registry, not a dependency resolver." When two installed skills declare different requirements on the same underlying capability, "the host runtime — Claude Code, Cursor, your own agent — is responsible for resolving that, not AgentRoot." There is no semver precedence rule at the protocol level, and there is no fail-fast error from the registry when two records overlap.

Source: /docs/limits

There is no standalone `discover-skills` CLI binary, and no `--filter` flag is documented. Discovery is done via `agent-root search` and `agent-root resolve`. The CLI only supports `--type` for filtering by record type (`agent`, `mcp`, `skill`, `a2a`, `payment`), accepting a single value per call. Filtering by capability substring, author domain, or semantic tags is not available as a CLI flag today. To filter by those dimensions, use the REST endpoint `GET /api/records?q=&type=&capability=&domain=` directly, or pipe `--json` output through `jq`. The REST API parameters include `capability` (substring match on record capabilities) and `domain` (substring filter on manifest domain).

Source: /docs/tools, /docs/api