Related Servers

Most tools target a clearly distinct resource+action (run_audit vs get_changes vs compare_competitors vs get_benchmark vs track_site), and descriptions explicitly cross-reference each other to steer selection. However, several boundaries blur: get_ai_visibility vs run_audit (which also returns an AI-visibility score), get_changes vs get_monitoring_status (which embeds the same change logic), and generate_schema vs get_fix (both emit structured data, one draft, one served). The extreme verbosity of each description mitigates but does not fully eliminate the risk of misselection.

All 20 tools are snake_case with a predictable verb_noun structure (get_report, run_audit, compare_competitors, list_tracked_sites, check_fix, confirm_facts). Even the paired lifecycle tools follow the pattern (track_site/untrack_site, get_fix_facts/confirm_facts). There is no mixing of conventions or vague un-prefixed names.

Twenty tools is heavy for a single auditing product; the surface spans audits, monitoring, fixes, facts confirmation and billing. Each has a plausible role, but the fixes cluster (list_fixes, get_fix, check_fix, get_fix_facts, confirm_facts) plus monitoring pair (list_tracked_sites, get_monitoring_status) pushes beyond what most agents need in one call path. It is defensible but on the crowded side rather than tightly scoped.

Coverage is broad and coherent: one-off audit, AI visibility breakdown, change tracking, competitor and industry benchmarks, recommendations, a full fix request/confirm/verify loop, monitoring lifecycle (track/untrack/list/status), report sharing, sample, and subscription status. Minor gaps remain — no way to browse stored audit history beyond get_changes, and no tool to manage the queries/business-name context an audit is measured against beyond re-running. Agents can work around both.