The Infisical MCP server presents well-structured tool definitions with complete JSON schemas, clear descriptions, and proper use of enums for constrained inputs. All 10 tools are explicitly registered with schemas visible in src/index.ts. Tool names follow verb_noun conventions (create-secret, delete-secret, list-secrets, etc.). Descriptions are present and reasonably detailed (typically 40-90 characters), explaining the action and context. However, several patterns are underutilized: (1) No output schemas are documented, only input schemas are visible; (2) Parameter descriptions lack constraint guidance (e.g., no mention of format, length, or allowed patterns beyond enums); (3) Error handling is not visible in the tool definitions; (4) No idempotency hints or permission declarations; (5) Secrets are passed as parameters rather than injected server-side (HIGH RISK). The code shows solid engineering (Zod validation, environment-based auth injection, masking support), but the tool interface itself has gaps typical of mid-tier production servers.

• Document output schemas for all tools. For get-secret, specify: {type: 'object', properties: {secretName: {type: 'string'}, secretValue: {type: 'string'}, secretPath: {type: 'string'}}}. For list-secrets, include total_count and next_cursor for pagination.
• Remove secretValue from tool parameters. Instead, design create-secret to accept only projectId, environmentSlug, secretName, secretPath. Retrieve the secretValue from a secure backend input prompt (Multi-Round-Trip Request) or require it via separate credential injection.
• Enhance parameter descriptions with constraints. E.g., 'projectId: UUID (36 chars, format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)' or 'secretName: 1-255 alphanumeric characters and underscores, no spaces'.
• Add pagination to list-secrets and list-projects: introduce limit (default 20, max 100) and offset/cursor parameters. Document in descriptions: 'Supports pagination; returns up to 20 items per call.'
• Implement confirmation-request pattern for delete-secret: add an optional 'confirm: true' boolean parameter that must be explicitly set, or support a separate dry-run mode that returns what would be deleted without executing.
• Add tool annotations for permission requirements. In the capability object, add a 'scope' field: ['read:secrets'] for get-secret, ['write:secrets'] for create-secret, ['delete:secrets'] for delete-secret, etc.
• Document error handling behavior in tool descriptions. E.g., for get-secret: 'Returns 404 with message "Secret not found. Check projectId, environmentSlug, secretName." Try list-secrets to discover available secrets.' For create-secret: 'Returns 409 if secret already exists. Use update-secret to modify.'