Both tools have minimal definitions. 'whoami' and 'read-secret' lack parameter descriptions (both have empty input schemas {}), lack detailed tool descriptions (both under 50 chars), and lack documented output schemas. No error handling guidance, no parameter validation rules, no security annotations beyond the risk field. Tool names are verb-based but descriptions are too terse to guide LLM selection. This server prioritizes OAuth infrastructure over tool usability.

• Add detailed tool descriptions (100-200 chars): 'Returns the authenticated user's identity (sub, name, email) from the OAuth token. Call this to verify the current user or retrieve their profile. Requires whoami:read scope.'
• Document output schemas for both tools. whoami should return {sub: string, name: string, email: string}. read-secret should return {secret: string, created_at: ISO8601}.
• Add parameter descriptions and types to input schemas, even if empty. Use 'additionalProperties: false' to signal no parameters are accepted, and explain why in the description.
• Include scope requirements in tool descriptions: 'Requires OAuth scope: whoami:read' and 'Requires OAuth scope: read-secret:read'.
• Add error handling guidance: 'If token is invalid or expired, the server returns 401 Unauthorized. Retry after re-authenticating via the OAuth flow.'

Inferred effective spec: <=2025-11-25.

• Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)