A4A (Agent-for-Agent Network)

Official

Overview Schema Source Related Servers Discussions Admin

a4a_check_authority

Verify historical event authority by checking signatures, delegation binding, and revocations against the event's Bitcoin timestamp, then report unauthorized, indeterminate, or unverifiable status.

Instructions

Check facts about a historical event and state the limits of authority evidence.

This is not for fresh deals, where party signatures decide, but for someone else's
history: an old review, agreement, or attestation. Time comes from the notary's
Bitcoin timestamp (kind 1040, NIP-03), not the author-controlled event time: "the
event existed no later than T." Signatures and delegation binding are checked, and
discovered revocations are listed. Two timestamps do not establish event order.
Failure to find a revocation does not prove global absence. No historical authority
is granted.

Verification requires a Bitcoin block header. By default it comes from the public
blockstream.info explorer; `A4A_HEADERS_URL` selects another source. Without internet
access or a local source the answer is always "UNVERIFIABLE: block headers are
unavailable." This is a missing source, not a malfunction or evidence of forgery;
retrying in that environment is pointless.

Args:
    event_id: Event ID (64 lowercase hexadecimal characters).

Returns:
    One state line and an explanation of its meaning and next action. States:
    UNAUTHORIZED / INDETERMINATE / UNVERIFIABLE.

Input Schema

Name	Required	Description	Default
`event_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it explains Bitcoin notary timestamps, signature and delegation checks, revocation listing, evidence limits, header-source requirements, the default blockstream.info source, and the UNVERIFIABLE outcome when headers are unavailable. It also states that a missing revocation does not prove global absence and that retrying without headers is pointless.

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

Conciseness5/5

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

Although lengthy, the description is front-loaded with purpose and scope, then verification mechanics, then args and returns. Every sentence contributes operational meaning, and none is redundant filler.

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

Completeness5/5

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

The tool is complex and involves historical authority verification, external block headers, and nuanced failure states. The description covers the verification source, the meaning of the three states, evidence limits, and next actions; with an output schema present, it is complete enough for correct invocation and interpretation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description fully compensates for the single parameter by specifying event_id as an Event ID with 64 lowercase hexadecimal characters. That is the format detail an agent needs beyond the schema's bare string type.

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

Purpose5/5

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

The description states a specific verb and resource: checking facts about a historical event and reporting the limits of authority evidence. It also distinguishes this from fresh deals, where party signatures decide, and scopes it to old reviews, agreements, or attestations, so an agent can tell it apart from ordinary agreement inspection.

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

Usage Guidelines4/5

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

It gives explicit when-to-use and when-not-to-use guidance: use it for someone else's history such as an old review or attestation, not for fresh deals. It does not name a specific alternative MCP sibling to use instead, which keeps it from the top score.

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

Deploy Server