This server has 11 tools with basic schemas and descriptions, but numerous quality gaps prevent a higher score. All tools have schemas with type definitions and descriptions present, which is a baseline requirement. However, descriptions are terse (avg 30-50 chars), parameter descriptions lack context about constraints and formats, schema completeness is inconsistent, and no output schemas are documented. No error handling guidance, no tool annotations (readOnlyHint/destructiveHint/idempotentHint), and parameter naming shows inconsistencies (e.g., 'productivity_score' vs 'productivityScore', 'isRunninng' with typo). Tool naming follows verb-noun convention, which is good. The server accepts IDs primarily, not human-readable identifiers, forcing extra lookup calls in some cases. No parameters are marked as required, and defaults are not declared. This lands the server in the 'fair/poor' range, acceptable for internal use but not production-grade.
Parameter naming inconsistency: 'productivity_score' in timing_create_project vs 'productivityScore' in timing_update_project. This forces the LLM to track different field names for the same concept, increasing errors.
Typo in parameter name: 'isRunninng' in timing_list_time_entries (three n's). This will cause silent mismatches when agents try to filter by running status.
Descriptions are too terse (30-50 chars avg, well below the 194-char baseline). Examples: 'Get project details' (21 chars), 'Stop the current time entry' (28 chars). These lack context for when/why to call tools and what they return. LLMs cannot reason about tool selection with such sparse descriptions.
Standardize parameter naming: use snake_case consistently (currently mixing 'productivity_score' and 'productivityScore'). Ensure all timestamp parameters use ISO 8601 format.
Expand tool descriptions to 100-200 characters. Current descriptions like 'Get project details' provide no context. Use pattern: 'Retrieve full project details including title, color, notes, and productivity score. Use this after listing to get metadata for a specific project.'
Add 'required' arrays to all input schemas. At minimum, timing_create_project must require 'title', timing_update_project must require 'projectId', etc.
Fix typos: 'isRunninng' → 'isRunning', 'Betweeb' → 'Between'. Add enum constraints where applicable (e.g., hideArchived as boolean enum, timespanGroupingMode with defined values).
Document output schemas for all tools. Example for timing_project: {type: 'object', properties: {id: {type: 'string'}, title: {type: 'string'}, color: {type: 'string'}, notes: {type: 'string'}, productivity_score: {type: 'number'}}. This enables tool chaining.
Add pagination parameters to timing_list_projects and timing_list_time_entries: 'limit' (1-100, default 20), 'offset' (default 0), and return a 'total' count. Document in descriptions: 'Returns up to 20 projects. Use offset for pagination.'
Add tool annotations (via MCP 2026-07-28 spec). Mark timing_list_projects, timing_project, timing_list_time_entries, timing_time_entry, generate_timing_report with 'readOnlyHint: true'. Mark timing_create_project, timing_update_project, timing_start_time_entry, timing_stop_time_entry, timing_create_time_entry, timing_update_time_entry with 'destructiveHint: true'.
No output schemas documented. Tools return data, but the LLM has no formal specification of response fields, types, or structure. This forces LLMs to guess about downstream field availability, breaking tool chains.
Parameter descriptions lack constraint/format guidance. Examples: 'startDate' has description 'Start date of the time entry.' but no format spec (ISO 8601? Unix timestamp? Natural language?). 'productivity_score' described as 'Betweeb -1 and 1' (typo: 'Betweeb') but no other guidance. LLMs cannot validate input without explicit format specs.
No required parameter declarations. All parameters have type but no 'required' array in schemas. This means tools like timing_create_project could be called with no parameters, causing silent API failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares 11 tools but does not mark which are read-only vs write/destructive. LLMs cannot reason about safety, reversibility, or retry semantics.
Tools only accept opaque IDs (project, timeEntryId, etc.). No support for human-friendly identifiers (project titles, time entry names). Agents must make extra lookup calls to resolve user input to IDs, wasting tokens and latency.
No error handling guidance. Tools do not document what errors can occur (e.g., project not found, invalid date, authentication failure) or how the agent should recover. Missing error responses leave LLMs unable to self-correct.
No pagination guidance for list tools. timing_list_projects and timing_list_time_entries return arrays but no offset, limit, or cursor parameters. Large result sets will blow context windows.
No confirmation/dry-run pattern for destructive operations. timing_create_project, timing_update_project, timing_start_time_entry, and timing_create_time_entry modify state but have no preview or confirmation step. Agents can make mistakes without recourse.
Enhance parameter descriptions with format/constraint guidance: 'startDate' → 'Start date in ISO 8601 format (e.g., 2024-01-15). Defaults to today if omitted.' Add similar guidance for endDate, color (hex or name?), notes (max length?), productivity_score (range and rounding rules).
Support human-friendly identifiers in addition to IDs. For timing_project, accept either 'id' (opaque UUID) or 'title' (project name) as parameters. Internally resolve title to ID, or let users pass natural names.
Document error scenarios with recovery guidance. Example for timing_project: 'Returns 404 error if project ID does not exist. Try timing_list_projects to find available projects.' Add this to all tools.
Consider a 'dry_run' or 'preview' parameter for timing_create_time_entry and timing_create_project, or a separate 'preview_project_creation' tool. This lets agents verify intent before committing.
Add per-parameter type hints in descriptions where JSON Schema alone is insufficient. Example: 'projects' array → 'Array of project IDs (strings). Pass empty array to include all projects.'
Define 'color' parameter constraints: is it a hex code (#FF0000)? Named color (red, blue)? RGB triplet? Document explicitly.
Clarify 'productivity_score' semantics: does -1 mean unproductive, 0 neutral, 1 productive? Any rounding rules? Currently 'Between -1 and 1' is ambiguous about whether endpoints are inclusive.
Add default values where sensible: hideArchived defaults to false (show all), limit defaults to 20, includeChildProjects defaults to false. Document in descriptions.