Server has 12 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with type definitions. However, descriptions are generic and lack actionable context for LLM selection. Parameter descriptions are minimal. Output schemas are not documented. No error handling guidance. No tool annotations (readOnlyHint/destructiveHint). Tool naming follows verb_noun convention (search-, get-, list-, create-) which is good, but descriptions do not explain WHEN to use each tool or dependencies between them. The single WRITE tool (create-time-entry) lacks confirmation/dry-run pattern. No pagination guidance despite search tools returning lists.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what it returns. Example: 'Search for clients by name or active status. Use this to find a client ID before creating a project. Returns up to 50 results; use pagination if needed. Returns client_id, name, and is_active.'
• Document output schemas for all tools. For list/search tools, specify: field names, types, whether pagination is supported (limit/offset/cursor), total count, and which IDs are returned for chaining (e.g., client_id for use in create-project).
• Add tool annotations to the MCP tool registration: readOnlyHint=true for all GET/search/list tools; destructiveHint=true for create-time-entry; idempotentHint=true for GET tools. This enables LLMs to reason about safety.
• Enhance parameter descriptions with format, constraints, and examples. E.g., 'clientId (string, required): Numeric ID of the client. Example: "12345". If unknown, call search-clients first.' For optional params, explain defaults and when to omit.
• Add error recovery guidance to tool descriptions. E.g., 'If no results found, try a broader search term or check is_active status. If client not found, call search-clients to verify it exists.' This guides LLM retry logic.