Aims server has 21 tools with significant definition gaps. Most tool definitions are inferred from test files rather than explicit registration code. Descriptions are present but minimal (10-50 chars typically). Input schemas are visible only for 3 tools (graphs-attach, graphs-list, graphs-get, graphs-delete); 18 tools lack visible schema definitions. No parameter descriptions found in source. No output schemas documented. Error handling and recovery guidance absent. Tool naming follows verb_noun pattern (workspaces-list, issues-create) but lacks clarity on mutual exclusivity and parameter dependencies.

• Add explicit input schemas to all 18 tools lacking them. Use JSON Schema with type, description, and enum/pattern constraints for each parameter. Reference the graphs-attach schema as a template.
• Expand all tool descriptions to 80-150 characters. Include: (1) what the tool does, (2) when to call it vs similar tools, (3) key prerequisites or dependencies. E.g., 'Create a new issue in the current workspace. Call workspaces-list first if you need to switch workspaces. Returns issue_id for use with issues-update and issues-link.'
• Add descriptions to every parameter in schemas. For graphs-attach, document owner_type enum values, explain when project_slug is required, and clarify the structure of references and edges arrays.
• Document output schemas for all tools. Specify which fields are returned, their types, and which IDs enable chaining to other tools. E.g., issues-list should return [{ issue_id, issue_key, title, workspace_id, ... }] so agents can call issues-update(issue_id) or issues-link(issue_id).
• Add error handling guidance to WRITE and DESTRUCTIVE tools. E.g., graphs-delete should document: 'Returns error if graph not found (call graphs-list first) or if user lacks delete permission. Deletion is irreversible.' Offer a dry-run or confirmation step for destructive operations.