Give an AI agent a verifiable identity via Digi-ID: sign auth challenges and prove who it is, no passwords. Pairs with DigiByte agent payments.
Two tools with clear naming (get_identity, authenticate) and reasonable descriptions (120-180 chars). Both have input schemas with Zod validation. However, output schemas are undocumented, responses are wrapped in a generic text() helper with no declared structure. Parameter descriptions are present but minimal. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Missing idempotency guidance for authenticate tool, which performs external HTTP POST (side effect).
Prove this agent's identity to a service. Given a Digi-ID challenge URI (digiid://...), sign it and POST the signed response to the service's callback. Returns the service's reply. This is how an agent 'logs in' with no password.
Return this agent's Digi-ID identity — the DigiByte address that other services will know it by. This is the agent's stable, public identity; it reveals no secret.
Output schemas undocumented. Both tools return text() wrapper with JSON content, but no schema definition visible. LLMs cannot predict response structure for downstream planning.
authenticate tool performs destructive side effect (HTTP POST to external service) but lacks destructiveHint annotation and no dry-run/confirmation pattern. Agents cannot reason about irreversibility.
Error messages lack recovery guidance. 'Not a Digi-ID challenge' and callback POST failures do not suggest next steps or alternatives.
Parameter 'post' (boolean, optional, default=true) lacks constraint documentation. No explanation of what 'false' returns vs 'true', LLMs must infer from code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
No pagination or result limits documented. If service replies are large, responses could exceed context window. No guidance on handling large payloads.