Six read-only tools with clear, domain-specific purposes. Tool names follow verb_noun convention (list_projects, get_board, get_tasks, daily_standup, deploy_health, next_actions). Descriptions are substantive (100-200 chars) and explain what each tool returns and when to use it. However, input schemas are inferred from demo code rather than explicitly visible in tool registration. Parameter descriptions exist but lack type constraints (enums, ranges). Output schemas are documented in descriptions but not formally specified. Error handling is absent, no guidance on what happens if a project is not found or a URL is unreachable.

• Explicitly register all tools with full JSON Schema input definitions, including type, description, and constraints (enum, minimum, maximum) for every parameter.
• Document output schemas formally (e.g. as JSON Schema or TypeScript interfaces) in tool descriptions or a separate schema file. Include field names, types, and what each field represents.
• Add error handling guidance to each tool description: 'If project not found, returns error with available project names. If URL unreachable, returns HTTP status and latency timeout.' This guides LLM recovery.
• For 'project' parameter, either provide an enum of valid project names or explain how LLMs can discover them (e.g. 'Call list_projects first to see available projects').
• Add tool annotations (readOnlyHint: true) to all six tools to signal to clients that these are safe, non-destructive operations.