agent-health

export_incident_evidence

Read-only

Export private retained incident evidence for a UTC Unix-second window within 30 days. Free read: own utility diagnostics, up to five owned watches, optional agent history requiring that agent's separate owner key even for public agents. Returns a versioned JSON timeline, coverage/truncation notes, checksum and original signed tokens where retained. sign=true authenticates the complete historical artifact with Ed25519; it does not renew tokens, prove complete retention or certify reliability. sign=false requests the legacy checksum-only export. Save the JSON privately. No public sharing, new checks, registration or credit spend.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "api_key": "<api_key>",
      "start": "<start>",
      "end": "<end>"
    },
    "name": "export_incident_evidence"
  }
}

Input Schema

Name	Required	Description	Default
`end`	Yes
`sign`	No
`start`	Yes
`api_key`	Yes
`agent_id`	No
`watch_ids`	No
`agent_api_key`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / sign

Added value: +{
+  "default": true,
+  "title": "Sign",
+  "type": "boolean"
+}

AddedOct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/non-destructive annotations, it discloses the 30-day window limit, the extra owner-key requirement for agent history, and the precise semantics of sign=true (Ed25519 attestation) plus explicit non-guarantees (no token renewal, no complete-retention proof, no reliability certification). That is substantive behavioral context, though it doesn't mention rate limits or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose leads and every clause carries information, but the telegram-style fragments and dense list ('Free read: own utility diagnostics, up to five owned watches, optional agent history...') reduce scannability and make the reader parse run-ons.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-param mutation-free export with an output schema, the description covers auth, scope, signing semantics and privacy constraints, so an agent can call it correctly. Return contents are also summarized despite the output schema, with only minor gaps like pagination or size limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 7 params, yet the description compensates well: start/end as a UTC Unix-second window within 30 days, sign=true for Ed25519 vs sign=false for legacy checksum-only, watch_ids capped at five owned watches, and agent_id/agent_api_key requiring that agent's separate owner key. api_key's role as utility credential is only implied, keeping it short of 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (export), resource (private retained incident evidence) and scope (UTC Unix-second window, ≤30 days). It distinguishes itself from siblings like agent_signed_evidence or run_signed_diagnostic by tying the evidence to incident retention and watches, though it doesn't name a sibling directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It defines what is in scope (own diagnostics, up to five owned watches, optional agent history) and what is excluded (no new checks, registration, credit spend), which implies usage. But it never explicitly says when to choose this tool over agent_signed_evidence or agent_health_feed, so routing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All agent-health tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?