---
title: "Capability health checks"
description: "Probe and monitor ENS-published MCP, A2A, and web endpoints."
canonical: "https://ens.tools/docs/capability-health"
section: "Agent platform"
stability: "beta"
version: "capability evidence v1 · monitoring v1"
verifiedAt: "2026-07-29"
owner: "ENS.Tools Agent Observability"
---

# Capability health checks

Probe and monitor ENS-published MCP, A2A, and web endpoints.

## Overview

Capability checks contact only HTTPS endpoints published by the ENS name. Operators can also sign a persistent monitor configuration that schedules observations, measures an SLO, and opens one deduplicated incident after two consecutive unhealthy runs.

## What this covers

- MCP initialize and tools/list evidence.
- A2A agent-card and advertised-skill evidence.
- Web reachability and HTTP status.
- Healthy, degraded, unreachable, invalid, safely blocked, and no-endpoint states.
- Stored point-in-time history for routing and audit.
- Wallet-signed 5-minute, 15-minute, hourly, or daily monitor schedules.
- Two-run incident and recovery thresholds, stale-evidence detection, and in-app alerts.

## Before you run this workflow

### Networks

- Ethereum mainnet for ENS endpoint discovery
- Public HTTPS for protocol probes

### Prerequisites

- An ENSIP-26 HTTPS endpoint record
- A controller signature only for persistent monitoring

### Wallet permissions

- No wallet for one-off checks
- EIP-712 monitor schedule signature; no transaction authority

### Expected result

- Timestamped per-endpoint state, latency, status, and advertised capability evidence

### Errors and recovery

- Retry transient transport failures
- Rotate invalid endpoint records
- Require fresh evidence before privileged work

## How to use it

1. **Enter an ENS agent name.** The checker resolves its published endpoint records; it does not accept an arbitrary probe URL.
2. **Read each endpoint separately.** One healthy web page does not prove the MCP endpoint works, and one failed endpoint does not erase other evidence.
3. **Use the observation time.** Re-check stale results before high-value or privileged work.
4. **Sign a monitor schedule.** The ENS controller signs monitoring configuration offchain. It grants no transaction or wallet authority.
5. **Respond to incidents, not noise.** Two consecutive unhealthy runs open one incident; two healthy runs resolve it. Repeated failures update the existing incident.
6. **Keep claims narrow.** The result proves a response at that moment, not operator identity, code safety, permission, or future uptime.

## Related guides

- [Intent routing](https://ens.tools/docs/intent-router)
- [Agent directory and profiles](https://ens.tools/docs/agent-directory)
- [Create and control agent fleets](https://ens.tools/docs/fleets-and-control)