Scored across 23 tools
Descriptions aggressively cross-reference each other, explicitly steering the agent between near-neighbors: diagnose_check vs get_check vs list_checks vs list_results, validate_check vs probe vs run_check, and internal incidents (list_incidents/get_incident) vs customer-facing publications (manage_status_page_incident). The four status-page tools (page CRUD, section, resource, incident) each target a distinct resource. No two tools share a purpose.
The dominant pattern is a clean verb_noun convention (list_checks, get_check, create_check, update_check, delete_check, create_status_page, list_regions, etc.). Deviations are limited: three multi-action tools use a manage_status_page_* prefix instead of create/update/delete triples, and `probe` stands alone as a bare verb. Readable and predictable overall, with one structural inconsistency.
23 tools is at the upper end of reasonable, but the server covers six distinct sub-domains (checks, results, incidents, status pages with sections/resources/publications, check groups, regions, plus a probe sandbox). Consolidating the three non-page status-page editors into multi-action tools already trims the surface. Slightly heavy but each tool earns its place.
The check lifecycle is fully covered (list types, validate, create, get, update, delete, run, diagnose) and status pages have full CRUD plus section/resource/incident management. However, check groups are read-only — only list_check_groups exists, with no create/update/delete or membership handling — and there is no write path for incidents (no resolve/acknowledge) and no events tool despite incidents/events being referenced in descriptions.
