Ward MCP exposes 6 read-only tools for Next.js observability querying. Tool naming follows verb_noun conventions and is generally clear (list_projects, get_sessions, diagnose_performance). Descriptions are present and reasonably detailed (average ~120 chars), explaining the purpose and use case of each tool. Input parameters are typed with JSON Schema and include descriptions. However, there are notable gaps: (1) Output schemas are NOT documented, no response structure is specified for any tool, making it difficult for LLMs to parse results and plan chained calls; (2) Parameter descriptions lack detail on constraints, formats, and valid ranges, e.g., 'threshold_ms' has no bounds guidance, 'type' enum in find_slow_requests is clear but lacks explanation of what each type filters; (3) No error handling guidance, tool descriptions do not explain failure modes or recovery paths; (4) Composition is solid (tools are single-responsibility), but lack of documented output makes chaining uncertain. All tools are READ_ONLY, which is secure by design. This is a competent but incomplete implementation, suitable for internal/specialist use but falls short of production quality for general agent deployment.

• Document output schema for each tool in the form of explicit JSON examples or a 'Returns' section. E.g., list_projects should return {projects: [{id: string, name: string, session_count: number}], total: number}.
• Add constraint details to numeric parameters: 'threshold_ms: number (default 100, range 1 - 10000 ms)', 'limit: number (default 10, max 100)'.
• Expand parameter description for 'project_id' to clarify the auto-detection logic: 'If not specified, attempts to auto-detect from package.json in cwd; if detection fails or multiple projects exist, returns all projects. Provide explicit project_id to filter a specific project.'
• Add error handling guidance: 'If no sessions are found, returns empty array. If project_id is invalid, returns error with available project IDs.' (adapt to actual behavior).
• Clarify pagination for tools that accept 'limit'. State whether a total count is returned, whether results are sorted (and by what field), and how to request the next page (e.g., via offset parameter if supported).
• For find_slow_requests 'type' enum, expand the description: 'Filter by resource type: fetch (HTTP requests), database (DB queries), api (upstream API calls), all (no filter, default).'
• Add dependency/ordering hints: E.g., 'Call list_projects first if you don't know the project_id. Call get_sessions before get_session_details to find valid session IDs.'
• Document the response shape for diagnose_performance's diagnostic output (bottlenecks, slow queries, uncached requests, suggestions). This tool's output is complex and must be schema-defined so LLMs can extract and act on diagnostics.