The server implements a single tool 'add_heartbeat' with reasonable naming and parameter documentation. The tool name follows verb_noun convention (add_heartbeat), which is clear and actionable. The description is detailed (252 chars) and explains the tool's purpose, handling of RFC 3339 vs cron schedules, timezone inference, and return value. Parameters (schedule, timezone, message) all have type definitions and descriptions. However, there is no documented output schema, the description mentions 'Returns the created heartbeat including its ID' but does not specify what fields the response object contains (e.g., does it return {id, schedule, timezone, message, created_at}?). This is a critical gap for tool composition, downstream tools cannot know what fields to extract. Additionally, there is no evidence of error handling guidance (what if the schedule is invalid? what if timezone doesn't exist?). The tool performs a write operation (WRITE risk) but there is no confirmation or dry-run pattern documented. Schema validation (enums for timezone, format validation for schedule) is not visible in the tool definition itself, it likely exists at runtime but the schema should declare these constraints.

• Document the complete output schema. Specify: 'Returns a JSON object with fields: {id (string, UUID), schedule (string), timezone (string or null), message (string), created_at (ISO 8601 string), next_trigger (ISO 8601 string)}' or similar. This allows agents to chain calls and extract the heartbeat ID.
• Add error handling guidance in the tool description. Example: 'If the schedule is invalid (malformed cron or RFC 3339), returns error with the problematic expression. If timezone is not a valid IANA name, suggests available options. Cron schedules without timezone default to UTC.'
• Consider adding an optional 'dry_run' boolean parameter (defaults to false) to show what the schedule would trigger without persisting it. This prevents accidental scheduling errors.
• Add JSON Schema pattern constraints to the schedule and timezone parameters. For schedule: use a pattern like '^((@(reboot|yearly|annually|monthly|weekly|daily|midnight|hourly))|([0-9]*\s[0-9]*\s[0-9]*\s[0-9]*\s[0-9]*)|([0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|[+-][0-9]{2}:[0-9]{2})))$' or reference a formal definition. For timezone: provide an enum of common IANA zone names or document the constraint clearly.