Server has 6 tools with mixed quality. Three tools (create_note, list_notes, summarize_notes) have basic descriptions and schemas, but lack depth. Three Affinidi tools (list_project, list_login_configurations, vc_issuance_event_ticket) expose API keys as required parameters, a critical security violation. Descriptions are generic (10-100 chars, below the 194-char baseline). Parameters lack validation constraints (enums, ranges). No error handling guidance. Output schemas are undocumented. Tool composition is reasonable but parameter design violates secret-injection pattern.

• Move apiKey from tool parameters to server-side environment variables or vault injection. Inject credentials at runtime, never expose in tool definitions.
• Document output schemas for all tools. Example: list_project should return {projects: [{id, name, created_at}], total_count, next_cursor}. This enables chaining.
• Expand descriptions to 100-200 chars. Example: 'list_notes' → 'Retrieve all stored notes with titles and content. Use this to review existing notes before creating new ones or to provide context for summarization.'
• Add enum constraints to parameters with known values (e.g., ticket_type: enum ['premium', 'regular']). Add min/max to numeric params (limit: 1-100, default 10).
• Add error handling guidance to tool descriptions. Example: 'If project not found, call list_project() to discover available projects. If API key is invalid, verify credentials in server config.'

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

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