Server defines 7 tools with explicit schemas and descriptions. Tool naming follows verb_noun pattern (listMonitors, getMonitor, createMonitor, etc.). Most tools have basic descriptions (10-60 chars). All tools declare input schemas with type and property definitions. However, descriptions are minimal and lack context about when to use each tool or what they return. Parameter descriptions are present but terse. No output schemas documented. No error handling guidance visible. Security: authentication token appears to be handled server-side (good), but no explicit secret-injection pattern documented. Composition: tools are well-separated by concern (read vs write, monitor vs incident), but relationships between tools (e.g., createMonitor returns a monitor ID that getMonitor accepts) are not documented in descriptions.

• Expand tool descriptions to 100-200 characters explaining WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'listMonitors: Retrieve all monitors for your authenticated team. Call this first to discover available monitors before viewing details with getMonitor. Returns list of monitor objects with id, name, url, status.'
• Document output schemas for all tools. Specify the structure of returned objects (e.g., 'Returns: {id: string, name: string, url: string, status: string, created_at: ISO8601}'). This enables LLMs to plan chained calls.
• Add pagination to listMonitors and listIncidents. Include 'limit' (default 20, max 100) and 'offset' (default 0) parameters. Return 'total_count' in response. Add language to descriptions: 'For large result sets, use limit and offset parameters to paginate through results.'
• Document idempotency for createMonitor and createAnonymousTracking. If retrying a creation with identical parameters returns the existing resource rather than duplicating, state this clearly: 'Idempotent: calling with the same url and name returns the existing monitor if already created.'
• Add per-parameter constraints to createMonitor description. Example: 'check_frequency: How often to check the monitor in seconds (minimum 30, maximum 3600). timeout: Timeout in seconds (minimum 5, maximum 120).'
• Add error guidance. For write tools, document expected errors: 'createMonitor may fail with: invalid_url (URL is malformed), auth_failed (API key invalid), duplicate_name (monitor with this name already exists). If auth_failed, verify your API key.'