Output schemas are not documented. Tool responses are inferred from async client calls (e.g., `await getClient().createEndpoint(args)`) but no explicit schema declarations (e.g., return type, field names, nested structures) are visible. LLMs cannot plan downstream tool calls without knowing what fields will be returned.

No error handling guidance. Tool descriptions do not explain what happens on failure (e.g., endpoint not found, volume in use, insufficient permissions). LLMs receive raw errors and cannot self-correct.

Descriptions lack WHEN-to-use context. 'Get details of a specific endpoint by ID' does not explain when to call serverless_get vs. serverless_list vs. serverless_task_count. Similar tool names (list_* variants) risk LLM confusion without disambiguating guidance.

Parameter constraints are incomplete. Many numeric parameters (e.g., 'gpuCount', 'containerVolumeInGb', 'pageSize', 'pageNumber') lack min/max bounds. Free-form strings (e.g., 'keyword', 'status filters') accept arbitrary values without enum constraints or format validation.

Tool chaining dependencies are not documented. E.g., serverless_create returns an endpoint, but it's unclear if downstream tools (serverless_update, serverless_submit_task) require 'id' from that response. No explicit mapping between response fields and downstream parameter names.

Irreversible operations (serverless_delete, pod_delete, vm_terminate, registry_delete, volume_delete) do not provide dry-run, confirmation, or recovery guidance. No mention of whether deletion is permanent, reversible within a timeframe, or can be undone.