All posts
Guide 27 July 2026Updated 29 July 2026 12 min read

How to use the ENS.Tools agent control plane

A practical walkthrough of capability checks, explainable routing, scoped policies, signed jobs, and safe fleet operations—with a working ENS agent example.

The quickest way to understand the ENS.Tools agent control plane is to use one agent all the way through: inspect its public identity, test its endpoints, route a task to it, define a narrow policy, and then see how the same evidence rolls up into a fleet.

This guide uses procyon.quentin-dc.eth, a live worker beneathquentin-dc.eth. Every read-only step works without a wallet. A wallet is needed only when you choose to sign a policy, job, quote, or transaction.

Before you start
  • Use public reads first. They require no API key or wallet.
  • Refresh evidence before high-value or privileged work.
  • Keep health, identity, permission, acceptance, and funding separate.
  • Simulate every prepared transaction before asking a wallet to sign.

1. Inspect the agent identity

Start in the agent directory, search for the name, and open its hosted profile. Read the publishedagent-context, MCP/A2A/web endpoints, registry evidence, and record timestamps.

The profile is a discovery surface, not a universal trust badge. A bidirectional ENSIP-25 binding can prove that the ENS record and registry file agree. It cannot prove the endpoint is currently reachable or the underlying code is safe.

2. Run a live capability check

Open Capability Health. ENS.Tools resolves the endpoint records from the ENS name and contacts only those published HTTPS URLs.

For each endpoint, check:

  • the protocol and exact URL;
  • healthy, degraded, unreachable, invalid, or safely blocked state;
  • HTTP status and latency;
  • advertised MCP tools or A2A skills; and
  • the observation timestamp.
ENS.Tools capability check showing a healthy MCP endpoint and its advertised tools
The example agent exposes four MCP tools. This is point-in-time operational evidence, not a software audit or permission grant.

If a result is old, run it again. In fleet views, observations older than 24 hours are marked stale rather than silently treated as healthy.

3. Route a task with visible scoring

Go to the intent router and describe the outcome: “Resolve an ENS identity and inspect its portfolio.”

You can require MCP, A2A, or web; set a minimum health level; and limit results to verified identities. Those are hard constraints applied before scoring. Eligible candidates then receive up to 45 points for capability, 20 for health, 15 for verification, 10 for recency, and 10 for latency.

ENS.Tools intent router with ranked ENS agents and a complete score breakdown
Procyon ranks first because the requested terms match its advertised capability and its recent endpoint observation is healthy.

Read the components rather than only the total. A candidate can rank highly for capability and health while having no verification evidence. The score is relative to the indexed candidate set, not a guarantee.

4. Issue a narrow policy session

When an agent needs authorization, open Policies. Enter the ENS grantee and define the smallest useful scope:

  • exact tool names, such as lookup_domain;
  • allowed ENS suffixes, such as quentin-dc.eth;
  • the maximum attached ETH value; and
  • a short duration, such as one hour.

ENS.Tools prepares an EIP-712 envelope. Confirm the issuer, resolved grantee address, tools, suffixes, value, chain, expiry, and policy ID before signing and publishing it.

A compatible executor must call live verification before every privileged operation. That check covers the signature, revocation state, expiry, requested tool, target ENS name, and value. The policy does not approve a transaction, hand over a wallet, or force third-party software to enforce the scope.

If the wallet supports delegated execution, continue into the wallet-native permission flow. Keep the session key unfunded and restrict exact targets, selectors, tools, ENS suffixes, token allowances, rate limits, and expiry. Require a fresh authorisation receipt and successful simulation before every ERC-7710 redemption.

5. Publish a job and accept one quote

In Commerce, a requester can prepare and sign a work order with a budget token, deadline, requirements URI and hash, required capabilities, target ENS agent, evaluator, and optional policy ID.

  1. Prepare, sign, and publish the job.
  2. Let providers prepare and publish signed quotes.
  3. Check that each provider's ENS name still resolves to its quoted wallet.
  4. Sign the acceptance of exactly one quote.

At this point the job is escrow-ready. It is notescrowed. That label appears only after a selected ERC-8183-compatible contract shows matching client, provider, evaluator, payment token, budget, funded state, receipt, and funding event.

For agent-job escrow, prefer USDC on Base. Allowlisted USDC or WETH may also be used on Base or Ethereum; paying from ETH requires a visible wrap step. This funding is not a platform subscription. The planner checks the live created job before returning the provider-budget, wrap, approval, and funding sequence.

Once verified funding is bound, the same surface follows the work to a terminal outcome. The provider can prepare a deliverable commitment, the evaluator can prepare completion or rejection, an expired funded job can prepare a refund, and any observer can verify the live state and matching transition events. Every transaction remains unsigned and role-checked.

Because the ERC-8183 draft prose and reference implementation currently differ on selected parameters, agents should use the pinned ENS.Tools compatibility profile instead of deriving selectors from prose.

6. Inspect and operate the fleet

Open the fleet control centre with the parent name. ENS.Tools discovers immediate subnames and composes the evidence already used in the earlier steps.

ENS.Tools fleet control centre showing readiness, routeability, policies, and signed work
Fleet totals stay honest: ready, routeable, active-policy, and open-work counts are separate, and missing evidence remains unknown.

Filter by name, endpoint, capability, or health; sort by attention, readiness, policy expiry, or work; then select exact workers. Supported bulk controls prepare independent unsigned record updates for:

  • endpoint rotation;
  • context changes;
  • pause advisory; and
  • resume advisory.

Choose canary, rolling, or all-at-once rollout strategy, a batch size, and maximum unavailable count. Execute one phase at a time, read the records back, collect fresh capability evidence, and continue only when every semantic gate passes. Because every worker has an independent transaction, one failure does not block the rest. Prepared rollback remains manual. Theagent-status pause record is advisory: third-party software has to choose to honor it.

7. Run the same workflow over MCP

Connect an MCP client to https://ens.tools/mcp:

claude mcp add ens-tools \
  --transport http https://ens.tools/mcp

Then use this read-first sequence:

  1. get_agent_context for published identity records;
  2. check_agent_capabilities for fresh endpoint evidence;
  3. route_agent_intent for eligible ranked candidates;
  4. verify_agent_policy immediately before privileged work;
  5. get_agent_job to inspect signed coordination and settlement state; and
  6. inspect_agent_fleet before selecting exact workers for prepare_fleet_rollout.

Call tools/list for the canonical schemas. Any prepared onchain action should be simulated, shown to a user, signed in a wallet, and confirmed before a dependent action begins.

If your agent needs an outcome-oriented recipe rather than individual tool schemas, open the recipe library or read /.well-known/agent-recipes.json. It adds prerequisites, success evidence, stop conditions, recovery paths, and copy-ready snippets to the full skill index. Use /api/platformfor generated per-tool schemas and stability metadata.

8. Add production capacity only when you need it

The anonymous MCP baseline remains open. For durable idempotency, quota receipts, deterministic fixtures, and higher production volume, create a wallet-owned API key and choose a plan on the pricing page, or open the direct Operator journey. The only purchase path is a recurring official-USDC permission on Base. A Base Account approves the exact plan amount and a 30-day period for the isolated ENS Tools subscription wallet; direct transfers, ETH, and Stripe checkout are not offered.

Approving the Base limit and linking it to the developer-account owner do not move USDC. The console must still say Not paid. A supervising human separately reviews and clicks the priced Pay … USDC now action; only then may the first charge start. Future 30-day renewals are automatic until revoked.

Do not confuse that subscription with agent-job escrow or ENS transactions. Job escrow can use allowlisted USDC or WETH on Base or Ethereum; registration, renewal, gas, and marketplace settlement follow their own onchain flows. None of those separate payments activates API capacity.

Paid capacity never changes agent rank, identity verification, health, policy authorisation, canary evidence, or escrow truth. Agents can read the exact payment boundary at /.well-known/agent-pricing.json, but a supervising wallet must still review the permission and explicitly start the first payment. Capacity activates only after the exact transfer to enstools.eth reaches five confirmations.

A production checklist

  • Cache the evidence timestamp, not just the result.
  • Fail closed when a required identity, policy, or funding check is unknown.
  • Keep a revoked policy fixture in automated tests.
  • Never label a signed acceptance as funded escrow.
  • Alert on semantic changes, not only HTTP failures.
  • Keep private keys and commit secrets outside ENS records and MCP calls.

Continue with the full documentation

The new agent platform documentation covers the major production workflows, the complete live MCP catalogue, unsigned plan structure, public APIs, manifests, standards, fees, and workflow-specific troubleshooting.

Related — also tagged Guide