Two tools with clear names and risk classifications, but critical gaps in schema documentation and parameter descriptions. The 'issue' tool has a complex input schema with nested PluginIdentity type that is not formally documented in JSON Schema format. Parameter descriptions exist but lack actionable constraints (e.g., no validation rules for 'target' string format, no enum for identity_mapping modes). The 'revoke' tool is simpler but still lacks output schema documentation. No evidence of error handling guidance or recovery patterns. Tool descriptions are adequate (100-150 chars) but do not explain prerequisites, when to use each tool, or what happens on failure.

• Document input schemas in formal JSON Schema format. For 'issue', define PluginIdentity as an object with required fields (subject_id, roles, groups, scopes, attributes, trust_level, kind, auth_provider) and their types. For 'config', either remove it (if unused per code comment) or define its structure.
• Add validation constraints to parameter descriptions. E.g., 'target: Vault role name (2-128 alphanumeric chars + underscore/hyphen, no slashes or dots). Maps to a role via operator config.' This matches the is_valid_role_name() check in code.
• Document output schemas. E.g., 'issue returns {lease_id: string, username: string, password: string, ttl_seconds: number}'. 'revoke returns {status: string, revoked_at: string}'.
• Add error handling guidance to descriptions. E.g., 'issue: Returns NotAuthorized if identity trust_level is Unverified and role is identity-derived. Returns error if target role is invalid or Vault is unreachable. Retry with exponential backoff for transient failures.'
• Consider adding a 'verify_role' discovery tool that lists available Vault roles and their trust requirements, enabling agents to validate role names before calling 'issue'.

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

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