Server provides 10 tools with complete input schemas and descriptions. Naming follows verb_noun convention (deny_encrypt, deny_decrypt, deny_vault_list). Descriptions are adequate (100-150 chars) but lack actionable context about when to use each tool vs. alternatives. Parameters are typed and described, but lack constraints (enums, ranges, format specs). No output schemas documented. Error handling is minimal, no recovery guidance or categorization. Security is strong (no secrets in params, API key injected via env). Composition is good, tools are single-responsibility and chainable. Main gaps: output schema documentation, error recovery patterns, and parameter constraints.

• Document output schemas for all tools. Example: deny_encrypt should return {ciphertext: string (hex), controlData: string (hex)}. deny_vault_list should return {items: [{id: string, label: string, ...}], total: number}.
• Add parameter constraints to descriptions. E.g., 'plaintext: The text to encrypt (max 1MB, UTF-8)' and 'password1: Primary password (min 8 chars, any UTF-8)'. Use enums for hex-encoded fields: 'ciphertext: Hex-encoded ciphertext (64+ hex chars)'.
• Add decision guidance to tool descriptions. E.g., deny_encrypt: 'Use for API-based encryption with vault storage. For offline-only encryption, use deny_local_encrypt.' This helps LLMs choose the right variant.
• Implement error recovery patterns. Wrap API calls in try-catch blocks that return structured errors: {error: string, code: 'INVALID_INPUT'|'API_ERROR'|'AUTH_FAILED', suggestion: string}. Example: 'Invalid ciphertext format. Expected hex string (64+ chars). Did you mean to call deny_local_encrypt?'
• Add tool annotations (readOnlyHint, destructiveHint) to the tool definitions. deny_vault_store and deny_create_decoy should be marked destructiveHint=true; deny_decrypt and deny_vault_list should be marked readOnlyHint=true.