All three tools are dynamically registered with generic descriptions that provide no actionable guidance for LLM tool selection. Tool names use verb_noun pattern (good), but descriptions are identical boilerplate stating 'Dynamically registered Convex [type] functions exposed as MCP tools', under 100 chars, failing to explain WHAT each tool does, WHEN to use it, or what it returns. No input schemas are visible in the provided source; tool definitions are inferred from configuration passed to createMCPServer(). The server provides no per-tool parameter descriptions, no output schema documentation, and no error handling guidance.

• Replace generic descriptions with specific, LLM-optimized text (50 - 200 chars) for each tool. Example: 'dynamic_convex_query: Execute a read-only Convex query function. Use this to fetch data without modifying state. Returns the query result as JSON.' Distinguish query (read-only) from mutation (write) and action (side effects).
• Document input schemas explicitly in the server initialization or registration code. Show parameter names, types (string, number, boolean, array, object), required vs optional, enums, min/max bounds, and descriptions for each parameter.
• Document output schemas for each tool. Specify what fields are returned, their types, and what IDs/references are included for chaining downstream calls. Example: 'Returns {id, name, createdAt, userId}' so agents know what to extract.
• Add per-parameter descriptions in the schema. For each parameter, explain what it controls, valid values, format (e.g., ISO 8601 for dates), and constraints. Example: 'limit (number, 1 - 100): Maximum results per page. Defaults to 20.'
• Implement error handling that guides recovery. Catch common failures (not found, validation error, timeout) and return actionable messages. Example: 'User not found. Available users: [email protected], [email protected]. Try search_users() with a partial name.'