---
name: agent-reliability-check
description: Run a bounded, read-only reliability check on an MCP or A2A endpoint before a user connects, buys, deploys, or depends on it.
---

# Agent Reliability Check

Use this skill when the user provides an MCP server, A2A endpoint, Agent Card,
or agent product and asks whether it is reliable, safe to connect, ready to
buy, or ready for production use.

## Outcome

Return a concise evidence report that separates:

1. discovery and identity;
2. protocol compatibility;
3. declared authority and authentication;
4. payment and quote behavior;
5. delivery and acceptance evidence;
6. retention or recurring-operation evidence; and
7. technical health.

Technical health, listings, traffic, tests, and payments are not evidence of a
delivered, accepted, useful, or repeated result.

## Safety boundary

- Default to read-only requests.
- Do not authenticate, connect an account, approve permissions, pay, invoke a
  priced tool, submit private data, send a message, publish, deploy, or change
  external state without the user's explicit authorization for that action.
- Never probe outside the supplied origin or clearly advertised discovery URLs.
- Do not perform vulnerability exploitation, credential testing, fuzzing, load
  testing, or evasive scanning.
- Redact tokens, cookies, personal information, and private payloads from the
  report.
- Treat absent evidence as `unknown`, not as a failure or a passing claim.

## Required input

Obtain one of:

- an HTTPS MCP endpoint;
- an HTTPS origin that advertises MCP or A2A discovery;
- an Agent Card or server manifest supplied by the user; or
- a local manifest/package path.

If the target is ambiguous, ask for the exact endpoint or artifact. Do not
guess a host that could belong to another party.

## Check sequence

### 1. Freeze the subject

Record the supplied URL or local path, UTC observation time, and a SHA-256 hash
of every downloaded or supplied manifest used for conclusions. Keep the raw
artifact local unless the user authorizes sharing it.

### 2. Inspect advertised discovery

Where applicable, make bounded GET requests to the supplied origin and these
standard or explicitly linked paths:

- `/.well-known/agent-card.json`
- `/llms.txt`
- `/robots.txt`
- `/sitemap.xml`
- `/healthz`

Do not infer a route from unrelated domains. Record HTTP status, content type,
declared service identity, versions, capabilities, and whether discovery links
resolve consistently.

### 3. Check MCP compatibility without invoking business tools

If an MCP endpoint is supplied, attempt the minimum supported initialization or
discovery exchange. Record the requested and negotiated protocol versions,
server identity, advertised tools/resources, authentication challenge, and
whether durable-task or current discovery behavior is declared.

Do not call a priced or state-changing tool. A successful `tools/list` proves
only that a tool was advertised.

### 4. Check A2A identity and authority

If an Agent Card is available, record its identity, endpoints, protocol
version, capabilities, authentication declarations, and signature presence.
Do not describe an unsigned card as fraudulent; report it as unsigned or as
signature evidence unavailable.

### 5. Check payment and delivery contracts

Inspect only publicly advertised quotes, price ceilings, payment protocols,
refund or dispute statements, delivery states, acceptance mechanism, receipt
format, and support path. Distinguish:

- quote from settlement;
- settlement from delivery;
- delivery from buyer acceptance;
- acceptance from usefulness; and
- usefulness from repeat purchase or active subscription.

### 6. Bundled MCP scope

The bundled Viridis Security Preflight evaluates buyer-supplied static
manifests, policies, and sample text. It does not fetch or test a deployed
runtime and does not certify that an agent is secure.

The adapter exposes exactly `describe_agent`, `get_security_receipt`,
`security_preflight`, `scan_source`, and `screen_injection`. For this diagnostic,
use only `describe_agent` and, when the user supplies a public receipt ID,
`get_security_receipt`. The other three tools create priced assessments; do not
invoke them as part of this read-only workflow. Do not substitute invented
quote, signup, checkout, or reliability-audit tools. Checkout is a separate
service, not bundled by this plugin.

The prepared receipt workflow returns an unsigned filtered public summary
with an opaque ID, allowlisted verdict/counts and hashes of original records.
It omits subject IDs, input digests, detailed findings, tool/policy names,
scanner metadata and original signatures. Retain authorized original delivery
for signature verification. Originals can repeat submitted identifiers; never
submit secrets. No retention/deletion or anonymity promise is established.
The plugin grants no access and implements no signup or OAuth flow.

The coordinated local gateway patch routes assessments through caller-bound
fixed orders and rejects shared-credit consumption. It is not deployed by
loading this package. Until release verification, treat the reviewed live
shared-credit behavior and full public receipts as unresolved. Restrict the
three assessment tools in the host policy for this diagnostic; stop if the
restriction cannot be established.

### 7. Report

Lead with the verdict and first exact blocker. Use these verdicts:

- `READY_FOR_BOUNDED_TRIAL`
- `REVIEW_REQUIRED`
- `INSUFFICIENT_EVIDENCE`
- `DO_NOT_CONNECT`

Use `DO_NOT_CONNECT` only for concrete, material evidence such as identity
mismatch, unsafe authority, credential exposure, deceptive payment behavior,
or an actively failing required contract.

Report each finding as:

| Field | Required content |
|---|---|
| Observation | What was directly seen |
| Evidence | URL/path, time, status/version, and artifact hash when relevant |
| Meaning | What the observation establishes |
| Boundary | What it does not establish |
| Priority | P0, P1, or P2 |

End with one smallest safe next action supported by the observed evidence.
Do not refer the user to paid Viridis services or present a sales offer.

## Commercial truth

Do not call a diagnostic a customer, delivery, adoption event, or revenue.
Count only externally verified settlement as cash, buyer-verifiable possession
as delivery, explicit acceptance as acceptance, a buyer statement as a
usefulness receipt, and a second purchase or active paid operation as retention.