The server defines 10 tools with consistent verb_noun naming (antigravity_ask, antigravity_continue, etc.) and non-empty descriptions. However, definition quality is undermined by several systematic issues: (1) Descriptions are moderately detailed but often exceed the recommended 200 chars (e.g., antigravity_ask at ~180 chars is borderline; codex_ask exceeds 200), and critically lack actionable context about when to use each tool vs. alternatives. (2) Input schemas are visible and properly typed (string, enum), but parameter descriptions are present yet generic, many lack guidance on valid formats, constraints, or dependencies. (3) No documented output schema for any tool, responses are described informally in text ('returns the answer') without structured schema documentation. (4) The 5 sandbox-accepting tools (codex_ask, codex_continue, copilot_ask, copilot_continue, cursor_ask, cursor_continue, grok_ask, grok_continue) all expose a 'sandbox' parameter with enum values ('read-only', 'workspace-write', 'danger-full-access') but lack clarity on implications of each mode or when to use each. (5) Error handling is not evident in the tool definitions, no guidance on how tools report failures or what an agent should do on errors. (6) No idempotency guarantees documented for the _continue tools, which retain state across calls. (7) The model parameter validation differs across tools (agy validates via 'agy models', codex has 'not validated', cursor validates via 'cursor-agent models') but this variance is not explained to users. Average tool description length is ~140 chars (within baseline range 34-392), but clarity and actionability are moderate. All parameters have descriptions, meeting that baseline, but quality varies significantly.

• Add structured output schema documentation to all 10 tools. Document response as JSON object with typed fields (e.g., {answer: string, model: string, conversation_id?: string, error?: {code: string, message: string}}). This enables agents to parse responses and chain tools.
• Expand sandbox parameter descriptions with concrete implications. Explain what 'read-only' prevents, what 'workspace-write' allows, and what 'danger-full-access' enables. Add a note like 'Use read-only for untrusted code; use workspace-write for file generation; danger-full-access only when full system access is required.'
• Document model validation behavior consistently. Either validate all model parameters server-side and document the validation mechanism, or document each tool's validation approach. Provide a discovery tool (e.g., list_models) if agents need to enumerate valid models.
• Add error handling guidance to all tool descriptions. Include examples: 'On authentication failure, [error message]. On timeout, [error message]. On invalid model, [error message].' Pair with recovery hints ('Try search_models first to validate the model name').
• Document idempotency guarantees for _continue tools. Clarify: 'Retrying with the same prompt may re-run the previous conversation or append to it depending on pinned session state. Idempotency is NOT guaranteed.' Or implement idempotency and document it.
• Add comparative descriptions for paired _ask/_continue tools. E.g., 'Use antigravity_ask for new independent queries. Use antigravity_continue to extend an existing conversation in the workspace (continues pinned session if available, else newest conversation).'