Two tools with minimal definitions. Both lack input parameter descriptions entirely (empty {} schemas). Tool descriptions are present but extremely brief (16-19 chars), falling below the 20-char minimum threshold. No parameter validation, no error handling guidance, no output schema documentation. Naming is acceptable (verb_noun pattern: 'whoami', 'health'), but the complete absence of schema detail and parameter documentation makes these tools unsuitable for LLM-driven agent use. The server appears to be a template/skeleton rather than a production-ready implementation.

• Add explicit input schemas with type definitions and descriptions for all parameters, even if empty. Use 'properties: {}' with 'required: []' and document why no parameters are needed.
• Expand tool descriptions to 50-200 characters. For 'whoami': 'Returns the authenticated principal's identity, including user ID, email, and roles. Use this to verify authentication or retrieve the current user's context.' For 'health': 'Returns the MCP server's health status, including uptime, version, and dependency health. Use this to verify the server is operational before making requests.'
• Document output schemas. For 'whoami', specify: {user_id: string, email: string, roles: [string], authenticated_at: ISO8601}. For 'health', specify: {status: 'healthy'|'degraded'|'unhealthy', uptime_seconds: number, version: string}.
• Add error handling guidance. E.g., 'If authentication fails, the server returns 401 Unauthorized. Verify your credentials and retry. If the issue persists, contact the administrator.'
• Declare tool annotations in the tool definition: readOnlyHint=true for both tools, since neither modifies state.

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

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