Single tool 'complete' has a basic description (58 chars) but critical gaps in schema documentation and parameter guidance. Input schema visible with 'query' and 'model' parameters, both typed as strings with descriptions. However, no output schema is documented, LLMs cannot plan downstream actions or extract structured data. The 'model' parameter lists example values in the description ('gpt-5.1-codex-mini', 'gpt-5.1', etc.) rather than declaring them as an enum, inviting hallucinated model names. No error handling guidance, no idempotency declaration, and no indication of whether this tool modifies state (it appears read-only per the Risk field, but this is not stated in the description). The tool name 'complete' is generic and does not follow verb_noun convention, 'query_llm' or 'send_to_model' would be clearer. No parameter constraints (min/max length for query, valid model list as enum). Baseline: 100% of A+ tools have documented return types; this tool has none visible.

• Rename tool from 'complete' to 'query_llm' or 'send_to_model' to follow verb_noun convention and clarify intent.
• Convert model parameter to an enum: ['gpt-5.1-codex-mini', 'gpt-5.1', 'gpt-5.1-codex-max', 'gpt-5.2', 'gpt-5.2-codex', 'gpt-5.3-codex', 'gpt-5.3-codex-spark', 'gpt-5.4']. Remove example values from description.
• Document the output schema explicitly. Specify: response type (string or object), fields returned (e.g., 'text', 'usage', 'model'), and data types. Example: {"type": "object", "properties": {"text": {"type": "string"}, "model": {"type": "string"}}}.
• Add parameter constraints: query (min 1, max 4096 chars), model (enum as above). Include these in parameter descriptions: 'The prompt or question (1 - 4096 characters).'
• Add error handling guidance to the tool description: 'If the model is unavailable, try a different model from the list. If the API key is invalid, check server configuration. If the query is too long, split it into smaller prompts.'