No user-submitted related servers found.
Scored across 3 tools
The three tools split cleanly along write/read-ledger/read-identity lines: record_delivery writes a signed claim, get_delivery_history reads the local ledger for a seller, and resolve_agent_identity performs an on-chain ERC-8004 lookup. Names and descriptions make the boundary between the two read tools explicit (delivery claims vs. identity registration), so there is no realistic misselection risk.
All three names are snake_case verb_noun (record_delivery, get_delivery_history, resolve_agent_identity), with the verb form matching the operation type (record for mutation, get/resolve for reads). No mixed casing or stylistic drift.
Three tools is at the low end but each maps to a genuinely distinct capability in a narrow attestation domain, so nothing feels padded or redundant. It is slightly thin — a single-claim fetch would round it out — but the scope is defensible.
There is write, list, and identity resolution, but no way to fetch a single claim by claimId, filter by resource type/buyer, or traverse chains server-side; the description instead tells the caller to recompute completeness locally via analyzeCompleteness(). An agent can work around this by pulling all history, but notable operational gaps remain for a ledger-oriented server.
