Server has 11 tools with explicit schemas and descriptions. Naming follows verb_noun convention (get_, search_, create_). Descriptions are present but brief (avg ~80 chars, below 194-char baseline). All tools have input schemas with type definitions and enums where appropriate. However, output schemas are not documented, LLMs cannot predict response structure. Parameters lack depth: no format constraints, no min/max bounds, no dependency documentation. Error handling is absent from tool definitions. The create_test tool is the only write operation but lacks confirmation/dry-run pattern. No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction.

• Add output schemas to every tool. Document the response structure: field names, types, and which fields are required. Example: 'Returns {tests: [{id: string, title: string, state: enum, tags: string[]}], total: number}'.
• Add tool annotations: mark all read-only tools with readOnlyHint=true, and mark create_test with destructiveHint=true. This enables agents to reason about safety without parsing descriptions.
• Enhance parameter descriptions with format and constraint hints. Replace 'Suite ID' with 'Suite identifier (UUID format, e.g. 550e8400-e29b-41d4-a716-446655440000)'. Add min/max for numeric params (page: 1 - 1000, limit: 1 - 100).
• Add a dry_run parameter to create_test (boolean, default false). When true, validate inputs and return a preview without persisting. This prevents accidental test creation.
• Document error scenarios and recovery paths in descriptions. Example: 'If suite_id is invalid, call search_suites() first to find the correct ID. Returns 404 with available suite names if not found.'