Skip to content
Monita Docs

Monita MCP server

Monita ships a hosted MCP (Model Context Protocol) server, so any MCP-capable assistant can work with your monitoring directly: ask “which tags broke overnight?”, have an agent triage issues, run an audit from a chat, or wire Monita checks into agentic CI.

https://api.monita.ai/mcp

Transport is Streamable HTTP. No software to install or host.

Choosing an auth method

Section titled “Choosing an auth method”
OAuth (recommended) API key
Best for Interactive clients: Claude, ChatGPT, desktop apps Headless agents, CI, IDE configs
Setup Add the server URL; the client walks you through sign-in and consent Create a key at Settings → API keys, send Authorization: Bearer ak_…
Organizations You pick which orgs to grant during consent Key’s org, or X-Org-Id header; multi-org users can specify the org per tool call
Rotation Tokens refresh automatically Revoke and reissue in the app

Monita’s OAuth supports discovery and dynamic client registration, so clients that speak MCP OAuth connect with no client IDs or manual configuration: paste the URL, sign in, approve the organizations you want the assistant to see.

Client guides

Section titled “Client guides”

What the assistant can do

Section titled “What the assistant can do”

Call list_organizations first. It reports each account’s plan, enabled features, properties and current usage (events this billing period against the limit, the annual contract position where one exists, audit pages, users and properties) and the contract terms shown on the Billing page (start, term, renewal date and payment schedule, never prices), so the client knows which of the tools below will answer before it calls them.

Read tools:

Tool What it returns
list_organizations Organizations the connection can access, with each one’s plan, features, properties and current usage
get_worst_issues The issues most worth attention right now
list_issues Filterable issue list
get_tag_health Health summary per vendor/tag, read from the property’s promoted signal configuration
get_tag_uptime Hourly uptime scoring
get_signal_catalog The signals (vendor x event) Monita knows for a property
get_anomaly_series Anomaly scores over time for a signal
get_traffic_geography Where traffic originates
get_compliance_posture Consent, PII and vendor-policy standing
list_alerts Configured alerts
list_audits / get_audit_report Past audits and their findings
list_flow_tests / get_flow_run Flow tests and run results
search_docs The documentation sections that answer a “how does Monita work” question, with links

Tag manager tools (read the container Monita has connected to the property):

Tool What it returns
list_tms_connections The containers connected to the organisation, or to one property, with sync state and latest synced version
get_container_inventory What the latest synced container version declares: counts plus its tags, triggers and variables
query_container Structural questions over a synced container: tags by type or by trigger, variables by dataLayer key, one tag’s detail, or which tags read a variable
resolve_signal_source Traces a monitored vendor signal on a property back to the container tag that fires it, with the evidence, its triggers and recent container changes touching it
get_container_drift What changed between two synced container versions: tags, triggers and variables added, removed, renamed, paused or modified

Tag manager operations (these act as you, through your own Google account, so they need connect_google_tag_manager first):

Tool What it does
connect_google_tag_manager Returns the Google sign-in link that connects your account for the gtm_* tools
gtm_browse Lists the Tag Manager accounts your account can reach, or the containers inside one
gtm_workspace Lists, creates or inspects workspaces in a container; every edit lands in a workspace, never in the live version
gtm_upsert_entity Creates or updates one tag, trigger or variable in a workspace
gtm_remove_entity Removes one tag, trigger or variable from a workspace
gtm_validate_change Checks a workspace’s pending changes against live monitoring: which monitored vendors they touch and how much traffic those carry
gtm_release Lists versions or creates one from a workspace; publish and rollback hand you the review link to finish in Tag Manager
gtm_watch_publish After a publish, compares each mapped vendor’s event rate against its pre-publish baseline

Action tools (require a role with the matching permission, see Team & roles):

Tool What it does
create_alert / update_alerts / delete_alerts Manage alerts
resolve_issue / bulk_update_issues Triage issues
run_audit Kick off a browser audit
run_flow_test Run a flow test
set_vendor_policy Allow/deny a vendor, or set its consent expectation
set_auto_alert_destinations Lists, adds, removes or tests where the organization’s Auto Alerts are also sent: shared inboxes, other addresses, Slack or Teams channels, webhooks. Anyone can list them; changes need an organization admin
set_my_notifications Reads or changes your own Notify me emails and briefing subscription. Only your settings change, and it needs a personal sign in rather than an organization API key

Every tool takes an optional org parameter for multi-organization accounts.

The server also briefs the assistant when it connects: Auto Alerts already watch every signal, so asking to be told about anomalies leads to set_my_notifications (for yourself) or set_auto_alert_destinations (for other people, shared inboxes and channels) rather than a new custom alert, and product questions are answered from search_docs with a link to the page.

What each tool needs

Section titled “What each tool needs”

Not every tool answers on every account. Check list_organizations before planning a sequence of calls.

  • Tag manager tools (list_tms_connections, get_container_inventory, query_container, resolve_signal_source, get_container_drift, and the gtm_* operations) need a connected Google Tag Manager container on the property. See Tag manager connections.
  • Flow tools (list_flow_tests, run_flow_test, get_flow_run) need Flow tests enabled for the organisation. Flow tests are in beta.
  • get_compliance_posture and get_traffic_geography need the Compliance suite enabled.
  • list_organizations reports the account’s plan, features, properties and current usage against its limits, so a client should call it first and read the answer before choosing tools.

Two reading notes:

  • get_tag_health reads the property’s promoted signal configuration, the one live in production. Signals that exist only in the dev environment are not part of the comparison. See dev and prod script environments.
  • get_audit_report marks a tag as self-hosted when it is served from your own domain rather than the vendor’s. In the same report, direct is a placement label (the page loaded the tag itself, rather than another vendor’s script), not a consent verdict. Consent verdicts come from consent settings and get_compliance_posture.

Good first prompts

Section titled “Good first prompts”
  • “Check Monita for my worst issues this week and summarize them for a standup update.”
  • “Any volume anomalies on Meta Pixel in the last 48 hours? Show the series.”
  • “Run an audit on www.example.com and tell me which vendors set cookies before consent.”
  • “Email me whenever a tag stops firing or drops on any of my properties.”
  • “Send volume Auto Alerts, medium severity and up, to analytics@company.com and test it.”
  • “Create a realtime alert: notify #web-analytics in Slack if GA4 purchase events drop more than usual.”