All 6 tools have identical structural weaknesses: zero input parameters (empty {} schemas), minimal descriptions (20-80 chars, below the 194-char baseline), and no parameter documentation. Tools are read-only discovery operations with no error handling guidance. Descriptions reference external API docs but lack context for LLM selection. No output schema documentation visible. Tool names follow verb_noun pattern (positive), but lack of input validation, pagination support, and result limits makes these unsuitable for production agent use.

• Add input parameters to all tools: limit (1 - 100, default 20), offset/page (for pagination), and filter options (e.g., state, region, tags). Document each parameter with type, range, and description.
• Expand tool descriptions to 150 - 250 characters. Include: (1) what the tool does, (2) when to use it (e.g., 'Call this first to discover available servers before creating a load balancer'), (3) what it returns (e.g., 'Returns a list of server objects with id, name, state, and region').
• Document output schemas in tool descriptions or via structured annotations. Example: 'Returns {servers: [{id, name, state, region, created_at}], total_count, next_offset}'.
• Implement result capping and pagination. Return max 20 items by default, include total_count and next_offset/next_cursor in response. Update descriptions to state the limit.
• Add error handling with recovery guidance. Catch API errors and return structured messages like 'Failed to list servers: authentication error. Verify NIFCLOUD_ACCESS_KEY_ID and NIFCLOUD_SECRET_ACCESS_KEY are set correctly.' instead of raw exceptions.

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

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