vcf-mcp exposes 4 well-named tools with clear verb-noun patterns (list_specs, search_endpoints, get_endpoint, call_api). Descriptions are present and substantive (100 - 250 chars), explaining WHAT each tool does and WHEN to use it. Input schemas are visible and typed. However, output schemas are not documented, callers cannot predict response structure. Parameter descriptions are good but lack format constraints (e.g., spec enum, limit bounds). Error handling is minimal; no recovery guidance. The design elegantly abstracts 300+ API operations into 4 composable tools, but lacks LLM-optimized output documentation and validation messaging.

• Add output schema documentation to each tool. E.g., list_specs returns {spec_name: {title, version, endpoint_count, auth, base_url_configured, credentials_configured}}. search_endpoints returns [{operation_id, path, method, summary, tags}]. This enables LLMs to plan downstream calls.
• Convert 'spec' parameter to enum: spec: {type: 'string', enum: ['fleet', 'vcf-ops', 'sddc'], description: 'API spec to query'}. Prevents hallucinated spec names.
• Add bounds to 'limit' parameter: limit: {type: 'integer', minimum: 1, maximum: 100, default: 15, description: 'Max results (1 - 100)'}. Prevents runaway requests.
• Enhance error messages in call_api. When a 401 occurs, return 'Token expired or invalid credentials. Check {spec}_USER and {spec}_PASSWORD env vars are set correctly.' When a 4xx occurs, include the invalid value and constraint violated.
• Document the body schema for call_api. Add a note: 'body structure depends on the operation. Call get_endpoint first to see required/optional fields and their types.' Or validate body against the operation schema and return field-level errors.