The server defines 12 tools with explicit schemas in src/tool-schemas.ts. All tools have names starting with action verbs (get_, create_, update_, delete_, search_, add_), which is correct per naming patterns. Descriptions are present for all tools and range from 84 - 342 characters, which is within the recommended 10 - 1024 character band. However, most descriptions lack actionable specificity, they do not explain WHEN to use each tool vs. similar alternatives, DO NOT document prerequisites or dependencies, and do not provide recovery guidance for failure modes. Parameter descriptions exist but are often generic ('required', 'optional') without format constraints, allowed ranges, or examples of valid values. Schemas are properly typed JSON Schema (object, string, array, number) with properties and required arrays declared. Output schemas are NOT documented anywhere in the visible code, LLMs cannot infer what fields get_test_case or create_test_case return, making downstream tool chaining risky. Error handling is listed as present (errorReporting=true) but implementation details are not visible in the provided source. The create_test_case tool is complex with nested objects (test_script.steps, parameters.variables) but lacks validation hints for the nested structure, increasing the risk of LLM misuse. BDD-specific guidance in create_test_case and update_test_case_bdd descriptions is helpful but could be more explicit about format conversion ('markdown will be converted to Gherkin'). Resource hints (e.g., 'use zephyr://testcase/EXISTING-KEY resource') are present and positive. Overall: descriptions and schemas exist but lack depth, actionability, and output documentation.

• Add return-type documentation to every tool. For get_test_case, specify: 'Returns: {test_case_key, name, status, priority, folder, owner, estimate_time_ms, custom_fields, test_script}'. Make field names match parameter names expected by downstream tools.
• Expand tool descriptions to 50 - 150 chars with explicit WHEN/WHY guidance. Example: 'Create a new test case in Zephyr Scale (STEP_BY_STEP, PLAIN_TEXT, or BDD format). Use this when defining test steps before execution. To match existing project structure, call the zephyr://testcase/PROJECT-T1 resource first to see custom_fields format.'
• Add min/max/enum constraints to numeric and free-text parameters. For max_results: 'integer, 1 - 100 (default: 20)'. For estimated_time: 'number in milliseconds, 60000 - 3600000 (1 min - 1 hour)'.
• Document idempotency and retry safety for each tool. Example: 'create_test_case is NOT idempotent, calling twice with the same name and project will create duplicate test cases. If creation fails, verify the test case exists via get_test_case before retrying.'
• Add pagination details: if search_test_runs returns 20 items and max_results is 20, document whether to use offset/limit or cursor-based pagination, and include a next_cursor field in responses.
• Simplify BDD/STEP_BY_STEP examples. Instead of relying on resource fetching, provide a minimal inline example in create_test_case description: 'For STEP_BY_STEP, steps: [{description: "Click login", expectedResult: "User logged in"}]. For BDD, text: "Given user is on login page\nWhen user enters valid credentials\nThen user sees dashboard."'