Aegis exposes 19 admin/tenant management tools with HTTP transport. All tools have basic descriptions (10-100 chars) and JSON Schema input definitions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool or what happens next. Parameter descriptions are minimal (1-5 words). No output schemas documented. Error handling is absent from tool definitions. Tool names follow verb_noun convention but lack clarity on mutual exclusivity (e.g., revoke_key vs delete_key). No tool annotations (readOnlyHint, destructiveHint). Schemas present but sparse, many parameters lack type constraints, enums, or range limits. This is typical community-grade tooling: functional but not production-optimized for agent reasoning.

• Expand tool descriptions to 100-200 chars. Include: what the tool does, when to use it (vs similar tools), what it modifies, and what the agent should do next. Example: 'Revoke an API key to immediately block all requests using it. This is reversible, the key can be re-enabled. Use this to temporarily disable a key; use delete_key to permanently remove it. Returns the revoked key ID.'
• Document output schemas for all tools. Specify what fields are returned, their types, and which IDs/references downstream tools need. Example: create_agent returns {agent_id: string, name: string, model: string, created_at: ISO8601}.
• Add parameter constraints: enums for 'type' (http|sse|stdio), ranges for 'rpm' (1-10000), patterns for 'name' (alphanumeric + underscore, 1-64 chars). Include these in parameter descriptions, not just JSON Schema.
• Clarify tool pairs: revoke_key (temporary disable, reversible) vs delete_key (permanent removal). patch_key (update limits) vs create_key (new key). Add a 'See also' section in descriptions.
• Add error recovery hints to descriptions. Example: 'If name already exists, call list_mcp_servers to see existing names, or choose a unique name and retry.'