mureo exposes 203 tools via the Model Context Protocol (MCP): 182 advertising and SEO operation tools across Google Ads (86), Meta Ads (86), and Search Console (10), 2 rollback tools, 1 cross-platform anomaly-detection tool, 9 mureo-context tools (strategy / state / reports / outcome evaluation), 2 analytics-registry tools, 2 learning tools (mureo_learning_insights_get for the operator’s local /learn history and mureo_consult_advisor for federated retrieval against external advisor MCP servers — see docs/insight-federation.md), and 5 Creative Studio tools (text-free key-visual generation + banner composition). Any MCP-compatible client can connect and call these tools over stdio. Re-check this count when MCP tools are added or removed (test_list_tools_returns_all_tools pins the exact number).
The server communicates over stdin/stdout using the MCP JSON-RPC protocol. It is not meant to be run interactively — it should be launched by an MCP client.
Codex reads MCP servers from ~/.codex/config.toml (TOML, not JSON) — shared
across the Codex CLI, IDE extension, and desktop app. The easiest path is
mureo setup codex (or mureo configure → pick the OpenAI Codex host),
which writes a tagged [mcp_servers.mureo] block and preserves the rest of the
file. To wire it by hand:
Search Console tools reuse the same Google OAuth2 credentials as Google Ads — no additional authentication is required.
site_url is an optional parameter on every tool below, not a schema-required one. It is resolved (and tenant-scoped) at runtime: in standalone use you pass it explicitly; under a multi-account backend it is bound to the active client’s configured property (and a single-property client may omit it). The “Required Parameters” column lists only the schema-required fields.
Cross-platform tools for inspecting and applying the reversal of a previously-recorded action_log entry. rollback_apply re-dispatches through the same MCP handler used for forward actions, so the reversal re-enters the full policy gate (auth, rate-limit, GAQL validation, planner allow-list).
Tool
Description
Required Parameters
rollback_plan_get
Inspect the reversal plan for an action_log entry (supported / partial / not_supported), its operation + params, and any caveats. Read-only.
index
rollback_apply
Execute the reversal plan for action_log[index]. Requires confirm=true as a literal boolean. Appends a new log entry tagged rollback_of=<index>.
index, confirm
Both tools accept an optional state_file argument (default STATE.json), which is resolved strictly inside the MCP server’s current working directory. Path traversal, symlink escape, and rollback.* self-recursion are all refused. A second apply of the same index is refused (idempotency is enforced by scanning later log entries for a matching rollback_of marker). Downstream SDK exceptions are logged server-side only; the MCP response returns a generic message so tokens and account identifiers cannot leak into model context.
Cross-platform anomaly detection that operates on STATE.json’s action_log history rather than a platform API directly.
Tool
Description
Required Parameters
analysis_anomalies_check
Compare a campaign’s current metrics against a median-based baseline built from action_log history. Returns severity-ordered anomalies — zero spend (CRITICAL), CPA spike (HIGH/CRITICAL, gated by 30+ conversions), CTR drop (HIGH/CRITICAL, gated by 1000+ impressions).
current (current.campaign_id and current.cost required)
had_prior_spend (default true) suppresses the zero-spend alert for fresh campaigns. min_baseline_entries (default 7) controls how many history entries are required before a baseline is built; below this, baseline is null and only zero-spend is evaluated. Numeric fields accept int / float / numeric-string and reject "N/A" or booleans. state_file is sandboxed the same way as for the rollback tools. A parseable-but-corrupt STATE.json produces a baseline_warning in the response without silencing live zero-spend detection.
Read and write the strategy context files (STRATEGY.md, STATE.json) directly through the MCP server. These tools exist for hosts that have no direct filesystem access (Claude Desktop chat, web, remote MCP); every write is atomic and validated before it replaces the file.
Tool
Description
Required Parameters
mureo_strategy_get
Read STRATEGY.md — raw markdown plus an exists flag (empty markdown when absent)
(none)
mureo_strategy_set
Atomically replace STRATEGY.md (parsed for well-formedness before writing)
markdown
mureo_state_get
Read STATE.json as a parsed v2 document (version, platforms, campaigns, action_log)
(none)
mureo_state_action_log_append
Atomically append a single action_log entry for later evaluation
entry
mureo_state_upsert_campaign
Upsert a CampaignSnapshot (with optional performance metrics) into STATE.json
campaign
mureo_state_report_set
Persist a structured daily / weekly / goal report summary for the read-only dashboard
report, summary
mureo_state_platform_metrics_set
Set a platform-level metric rollup (feeds the YESTERDAY / LAST_30_DAYS dashboard toggle)
platform, account_id
mureo_state_set_conversion_events
Declare which Meta Insights action_type rows count as this account’s conversions
platform, account_id
mureo_outcome_evaluate
Deterministically score a logged action’s outcome (improved / regressed / inconclusive) from before/after metrics
Discover and invoke the analytics modules registered for each platform (built-in google_ads / meta_ads, plus any supplied by provider plugins via the mureo.analytics entry-point group). Both tools are read-only diagnostics and route through the standard analysis dispatcher (#440).
Tool
Description
Required Parameters
mureo_analytics_modules_list
List analytics modules per platform and the capabilities each advertises (detect_anomalies, diagnose_performance, audit_creative, analyze_budget_efficiency)
(none)
mureo_analytics_run
Run one capability of a platform’s analytics module and return its structured result; degrades to a structured status (no_analytics_module / capability_not_available / error) instead of failing the workflow
Retrieve accumulated practitioner know-how before drawing diagnostic conclusions — the operator’s own /learn history and, optionally, federated retrieval against external advisor MCP servers (see insight-federation.md).
Tool
Description
Required Parameters
mureo_learning_insights_get
Load every insight previously saved via /learn as raw Markdown
(none)
mureo_consult_advisor
Query external advisor MCP servers (vector search) enriched with local campaign state; advisor responses are treated as untrusted external content
Generate creator-quality ad creatives — text-free key visuals plus copy composed over them into per-format banners. Image generation runs through configured providers; banner composition renders HTML/CSS with headless Chromium and requires the creative extra (pip install 'mureo[creative]'). See creative-studio.md.
Tool
Description
Required Parameters
creative_studio_providers_list
List image-generation providers, whether each has an API key configured, its capabilities, and model ids
(none)
creative_studio_generate_visual
Generate text-free key-visual PNGs from a visual-only prompt (a hard no-text constraint is appended)
prompt
creative_studio_brand_kit_get
Return the loaded brand kit (colours, fonts, logo, clear-space) or tasteful defaults
(none)
creative_studio_edit_visual
Refine an existing key visual through a provider’s edit path (art-direction loop)
path, instruction
creative_studio_compose
Composite ad copy + brand kit over a key visual into per-format banner PNGs
Beyond the built-in platforms above, the server also exposes tools from
third-party provider plugins discovered via the mureo.providers
entry-point group. A plugin opts in by implementing the
MCPToolProvider Protocol (mcp_tools() + async handle_mcp_tool());
see plugin-authoring.md §3.
Server behaviour:
Additive. Plugin tools are appended after all built-in tools.
With no third-party plugins installed, the tool list is identical to
before — built-in behaviour is unchanged.
Built-ins win on name collision. A plugin tool whose name matches
any built-in tool is dropped (a PluginToolWarning is emitted); the
built-in keeps the name. Plugin authors should namespace tool names
with their provider name (e.g. acme_ads_list_campaigns).
First plugin wins when two plugins contribute the same tool name.
Fault-isolated. A plugin that fails to construct, whose
mcp_tools() raises, or whose handle_mcp_tool is not async, is
skipped with a PluginToolWarning — it can never crash the server or
block other plugins. Discovery itself failing wholesale yields zero
plugin tools rather than a startup error.
Discovered once at server start, like the env-var gates below.
Plugin tools obey the same MUREO_DISABLE_* reasoning only insofar as
the plugin chooses; the disable env vars gate the built-in families,
not third-party plugins.
Beyond individual MCP tools, mureo provides higher-level operational workflows via Claude Code slash commands. These commands orchestrate multiple MCP tools in sequence, guided by the strategy context defined in STRATEGY.md.
Each command reads strategy context (Operation Mode, Persona, USP, Brand Voice, Market Context) from STRATEGY.md and campaign state from STATE.json, then selects and invokes the appropriate MCP tools. For example, /daily-check adapts its monitoring focus based on the current Operation Mode — an EFFICIENCY_STABILIZE mode prioritizes CPA and budget efficiency, while a GROWTH_SCALE mode focuses on impression share and conversion volume.
Operational skill definitions live under skills/ (daily-check, budget-rebalance, etc.). See strategy-context.md for the strategy file format and Operation Mode reference.
mureo is designed to work alongside other MCP servers in the same client session. For example, you can configure a GA4 MCP server next to mureo so that workflow commands like /daily-check and /budget-rebalance can incorporate analytics data into their analysis.
mureo’s workflow commands check for external tool availability opportunistically — if a GA4 or other MCP server responds, the agent uses that data; if not, the command proceeds with mureo’s own data. There is no hard dependency on any external MCP server.
For detailed setup instructions, supported platforms, and configuration examples, see integrations.md.
The target ad group must belong to a DISPLAY campaign (mureo verifies this before any upload)
If image upload fails partway through or the ad creation fails after all uploads succeed, an RDAUploadError is raised that includes the resource names of any orphaned uploaded assets so they can be cleaned up.
Google Ads: Uses gRPC with automatic retry built into the SDK.
Meta Ads: mureo monitors the x-business-use-case-usage response header and automatically retries on HTTP 429 with exponential backoff (up to 3 attempts).
AI agents can issue tool calls at high speed, which risks hitting API rate limits and triggering temporary bans. mureo includes a built-in throttling layer (mureo/throttle.py) that transparently rate-limits all outgoing API requests.
The throttler uses a token bucket algorithm combined with a rolling hourly cap (Meta Ads only). When the bucket is empty, the request awaits until a token becomes available — no errors are raised and no tool calls are dropped.
Each platform has a module-level singleton throttler that is shared across all MCP tool calls in the same server process. No user configuration is required; throttling is always active.