This server uses dynamic tool generation from CloudStack API responses. The critical issue is that tool definitions are not statically visible in the source code, tools are generated at runtime via CloudStackApiToJsonSchema function. While the code attempts to create schema from CloudStack API metadata, the actual tool names, descriptions, parameter schemas, and output formats cannot be verified from static analysis. The tool registration pattern is indirect and inferred rather than explicit. No actual tool definitions with names, descriptions, or verified schemas are visible in the provided source. The schema generation function exists but its output quality, parameter descriptions, and error handling capabilities are not documented or verifiable. This violates HARD SCORING RULE: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Additionally, the single 'dynamic CloudStack API names' entry represents an unknown number of actual tools with unknown quality characteristics.

• Generate tool wrappers that translate CloudStack API names to human-friendly verb_noun patterns (e.g., 'listVirtualMachines' → 'list_virtual_machines' with descriptive name 'list_vms_in_region'). Store mapping in static registry.
• For each generated tool, synthesize a descriptive docstring: 'What does it do? When to call it? What does it return?' Example: 'List all virtual machines in a region. Use this to discover available VMs before creating or modifying them. Returns VM ID, name, state, IP address, and resource usage.'
• Extract parameter metadata from CloudStack API schema and generate parameter descriptions. Document expected format, constraints, and examples. Use enums for constrained values instead of free-form strings.
• Document output schema for each tool. Include all returned fields, types, and what they mean in agent context. If a response includes VM ID, ensure it matches what downstream tools expect.
• Implement pagination support (limit, offset, page_size). Cap default results at 20-50 items and return total_count so agents know when to paginate.
• Add dry-run or confirmation pattern for WRITE operations. CloudStack API calls that create/delete/modify resources should support --dry-run flag or require explicit confirmation.
• Wrap CloudStack API error responses in recovery guidance. If a VM creation fails due to insufficient resources, suggest alternative zones/sizes. If an API key is invalid, guide user to check credentials.
• Create high-level composite tools for common workflows (e.g., deploy_vm_with_networking that internally chains CloudStack API calls and returns ready-to-use VM with single tool call).