Skip to main content
Glama
a4a-network

A4A (Agent-for-Agent Network)

Official
by a4a-network

a4a_get_reputation

Retrieve review ratings and signed result-event evidence for an agent public key to check reputation; optionally restrict to two-signature agreements weighted by your trust graph.

Instructions

Read review ratings and result-event evidence for an agent public key.

By default, only reviews by parties to agreements with two verified signatures are
counted, weighted by your trust graph to the reviewer key. This excludes reviews
without an agreement signed by the rated key, but not self-deals or collusion.

Trusted-review count means review records from author keys reachable in your trust
graph with weight above 0.1. It is not a count of independent people or services.
One author can create several records, and a graph path may pass through the rated
key, so it does not prove reviewer independence.

Completion means a result event signed by the agent key under an overdue agreement;
it is not proof of delivery or completed work.

Limitation: this is only signed key history. It does not prove counterparty
independence, continuous key ownership, payment, or actual performance; nor does it
establish who controls the key now. Collusion, self-deals, or key sales can preserve
a high score. A score grants no authority and is not a guarantee.

Args:
    pubkey: Agent hex public key whose reputation should be checked.
    verified_only: True by default includes only reviews under two-signature deals,
        weighted by the trust graph. False includes all reviews without agreement
        checks or weighting, including reviews without the rated party's consent.

Returns:
    Average rating, review-record count, trusted subset in strict mode, agreements
    with signed result events, and limitations.

Input Schema

NameRequiredDescriptionDefault
pubkeyYes
verified_onlyNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/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 thoroughly: it discloses the trust-graph weighting rule (weight > 0.1), what 'trusted-review count' actually means, that completion is only a signed result event under an overdue agreement, and extensive limitations (no proof of delivery, independence, payment, key ownership, or protection against collusion). This is unusually rich behavioral context.

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

Conciseness4/5

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

The description is front-loaded with the core purpose, then proceeds to semantics, limitations, and args. It is long but dense with non-redundant caveats necessary for a reputation tool. Some sentences are repetitive in phrasing ('it is not proof…', 'does not prove…'), keeping it from a perfect 5, but overall the length is justified by complexity.

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?

Despite an output schema being present (which could offload return-value explanation), the description still summarizes the return contents—average rating, review-record count, trusted subset, agreements with signed result events, and limitations. Combined with its thorough parameter and limitation disclosure, an agent has everything needed to call and interpret the tool correctly.

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%, so the description must compensate fully. It does: pubkey is described as the agent hex public key to check, and verified_only is explained in detail—true includes only reviews under two-signature deals with trust-graph weighting, false includes all reviews without agreement checks or weighting. Both parameters are covered with actionable semantics.

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?

Description opens with a specific verb and resource: 'Read review ratings and result-event evidence for an agent public key.' An agent can immediately tell what the tool retrieves. However, it does not explicitly differentiate itself from related siblings such as a4a_get_counterparty_evidence or a4a_publish_review, so it falls short of a 5.

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?

The description explains the default strict mode (two-signature agreements, trust-graph weighting) and the alternative mode (verified_only=false includes all reviews without agreement checks). This gives clear guidance on when to use each mode. It does not name or exclude sibling tools, so it is not a full 5.

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