Three simple time-utility tools with basic descriptions and minimal parameter documentation. All tools have descriptions (10-50 chars, below the 194-char baseline), but lack depth on WHEN to use them or what they return. Input schemas are present but sparse: get_current_time has empty input {}; get_day_name and calculate_days_between_dates have string parameters with format hints but no enum constraints, min/max, or error guidance. No output schemas documented. No error handling guidance (e.g., what if time format is invalid?). Tool names follow verb_noun convention (get_*, calculate_*) but are generic, no distinction from similar time utilities in other servers. No tool annotations (readOnlyHint, idempotentHint). Composition is sound (each tool does one thing), but descriptions are too terse to guide LLM selection effectively.

• Expand tool descriptions to 100 - 200 chars. Example for get_day_name: 'Returns the day of the week (Monday - Sunday) for a given timestamp. Use this to determine scheduling constraints or day-based filtering. Input must be ISO 8601 format (YYYY-MM-DD HH:MM:SS); invalid formats return an error with the expected format.'
• Add output schema documentation in docstrings. E.g., 'Returns: str, day name (e.g., "Monday"). Always one of: Monday, Tuesday, ..., Sunday.'
• Add format constraints and error guidance to parameter descriptions. E.g., 'time (str): ISO 8601 timestamp (YYYY-MM-DD HH:MM:SS). If format is invalid, returns error: "Invalid time format. Expected YYYY-MM-DD HH:MM:SS, got {input}."'
• Add tool annotations via FastMCP metadata. Mark all three tools with readOnlyHint=true and idempotentHint=true so LLMs know they are safe to retry.
• Document when to use each tool relative to others. E.g., 'Use get_current_time to establish a baseline; use get_day_name to determine day-of-week constraints; use calculate_days_between_dates for duration calculations.'