Tickward exposes 2 read-only tools with minimal descriptions and incomplete schemas. Tool names follow verb_noun convention (list_timers, get_project_overview), but descriptions are generic and lack context for LLM selection. The list_timers tool accepts a boolean parameter with a description, but get_project_overview has no parameters documented. Neither tool's output schema is visible in the provided source, making it impossible to verify response structure, field naming, or pagination support. No error handling guidance, no parameter constraints, and no indication of what fields are returned. This is typical of early-stage MCP servers that expose raw API endpoints without agent-centric design.

• Document the output schema for both tools. Specify all returned fields, their types, and what IDs/references are available for chaining (e.g., if list_timers returns timer_id, ensure downstream tools accept timer_id).
• Expand tool descriptions to 50 - 150 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Lists all timers in the current project. Returns timer names, IDs, and status. Use this to discover available timers before operating on a specific one.'
• Add parameter descriptions for get_project_overview explaining what 'overview' includes (e.g., active count, archived count, next deadline). If no parameters are needed, state that explicitly.
• Implement pagination for list_timers if results can exceed ~20 items. Add limit and offset/cursor parameters, and return a total_count or next_cursor in the response.
• Add error handling guidance in descriptions. E.g., 'If no timers exist, returns an empty list. If the project is invalid, returns an error with available project names.'