Strong foundation with 18 well-named tools following verb_noun convention (list_, get_, initiate_, start_, complete_, check_, revoke_). All tools have descriptions (avg ~50 chars, within baseline 34-392). Input schemas present with typed parameters and descriptions. Risk annotations (READ_ONLY, DESTRUCTIVE, WRITE) are valuable. However, descriptions are terse (many under 50 chars), output schemas are not documented in source, and error handling guidance is absent. No pagination support visible for list tools despite financial data context. Sensitive PII (CPF/subject_id) is exposed as required parameters without clear server-side handling notes.

• Document output schemas for all tools. Specify fields, types, and structure. For list_* tools, include pagination metadata (total_count, next_cursor, has_more). Example: list_accounts returns [{account_id, account_type, balance, currency}, total_count, next_cursor].
• Add pagination parameters (limit: 1-100, offset/cursor) to all list_* tools. Cap default results at 20-50 items. Document in tool description: 'Returns paginated results; default limit=20, max=100.'
• Expand descriptions to 80-150 chars. Include WHEN to use the tool and any prerequisites. Example: 'List accounts consented by the customer. Call start_consent() first if no accounts are visible. Returns account_id, type, and balance for each account.'
• Add error handling guidance to DESTRUCTIVE and WRITE tools. Document expected errors (e.g., 'Insufficient balance', 'Consent expired', 'Invalid PIX key') and recovery steps. For initiate_pix, add a dry_run parameter or require explicit confirmation.
• Mask or abstract PII in tool parameters. Consider accepting a session_token or consent_id instead of raw CPF. If CPF must be a parameter, document server-side encryption and audit logging in the tool description.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry