Four tools with cryptographic identity focus. All have descriptions (10-20 chars baseline met), but parameter descriptions are minimal and generic. Input schemas present but lack depth: most parameters use generic 'object' types without field-level schema. No output schemas documented. Error handling absent, no guidance on what happens when verification fails or credentials are invalid. Tool names follow verb_noun pattern (create_agent, verify_agent, check_permissions, inspect_credential) but descriptions are terse and lack WHEN/WHY context. No idempotency hints, no recovery guidance.

• Document output schema for each tool. Example for create_agent_identity: {did: string, publicKey: string, privateKey: string, createdAt: ISO8601}. Example for verify_agent: {valid: boolean, issuer: string, subject: string, expiresAt: ISO8601, revoked: boolean, errors: string[]}.
• Expand parameter descriptions to include format and constraints. For 'credential' param: 'A JSON object with fields: issuer (string, DID), subject (string, DID), signature (string, base64), expirationTime (ISO8601 date), claims (object). Required: issuer, subject, signature.'
• Add error handling guidance. For verify_agent: 'If signature is invalid, returns {valid: false, error: "Signature verification failed"}. If credential is revoked, returns {valid: false, error: "Credential revoked on 2024-01-15"}. If expiration is past, returns {valid: false, error: "Credential expired on 2024-01-10"}.'
• Specify what create_agent_identity returns: DID document structure, key format (PEM? JWK?), whether private key is returned (security risk if logged), and how to store it securely.
• Add idempotency hint to create_agent_identity: 'Calling with the same name twice creates two distinct identities. To retrieve an existing identity, use inspect_credential with its DID.' This prevents accidental duplicate creation.