Skip to main content
Glama

Honeyfield Marketing MCP

Anomaly check

anomaly_check
Read-only

Anomalie-Check der letzten N Tage über alle verbundenen Quellen des Workspace: Google Ads, GA4, Search Console und (nur mit include_clarity=True) Clarity — läuft auch ohne Google-Ads-Konto. Rückgabe: findings[{severity critical|warn|info, check, source google_ads|ga4|search_console|clarity, message}], ok, daily (Google-Ads- Tagesreihe [{date, cost_eur, clicks, conversions}]; [] ohne Google Ads), sources{: {status checked|not_connected|not_permitted|skipped|error, days_with_data, last_data_date, daily, note, …}}. ok = kein warn-/critical-Finding UND mindestens eine Quelle checked (info-Findings lassen ok unberührt). Keine Quelle verbunden → {error: no_sources, hint}. Zugänge mit eingeschränkten Datenquellen bekommen nur freigeschaltete Quellen ausgewertet (übrige: not_permitted). Fällt eine Quelle aus (API-Fehler, Verbindung abgelaufen, unerwarteter Fehler), laufen die anderen weiter: sources..status=error mit Fehler-Dict der Quelle plus Finding sources_unavailable (warn) — nie ein Fehler-Dict fürs ganze Tool, solange eine Quelle verbunden ist. Google Ads (Fenster bis gestern, heute nicht enthalten): conversions_zero (≥3 Tage mit Kosten seit der letzten Conversion; Tage ohne Kosten unterbrechen die Serie nicht, critical), cost_spike (gestern >2,5× Ø der Vortage), cost_drop_to_zero (gestern 0 trotz sonst täglicher Ausgaben), clicks_no_conversions (≥50 Klicks, 0 Conversions), ctr_drop (CTR letzte 3 Tage <50 % der Vorperiode), ads_no_data (info: keine Tageszeile). Conversions = primäre Aktionen — Konten mit nur sekundären Aktionen lösen conversions_zero aus (ads_conversion_performance). GA4 (sessions + keyEvents je Tag, Fenster bis gestern; GA4 liefert keine Zeilen für Tage ohne Sitzungen): sessions_drop_to_zero (Kalender-Gestern ohne Sitzungen, obwohl an mehr als der Hälfte der Tage davor Sitzungen liefen — warn, wenn nur gestern fehlt: GA4 verarbeitet bis zu 24–48 h nach, morgen erneut prüfen; critical ab 2 Tagen Lücke oder bei ausdrücklich 0 Sitzungen), sessions_drop (Ø letzte 3 Datentage <50 % der Datentage davor, erst ab Ø 5 Sitzungen/Tag; entfällt neben sessions_drop_to_zero), key_events_zero (≥3 Datentage in Folge Sitzungen ohne Key Event, davor gab es welche), key_events_none (info: im ganzen Fenster keine Key Events), sessions_spike (info: letzter Datentag >2,5× Ø), ga4_no_data (keine Sitzungen im Fenster). Findings nennen das Datum bzw. den letzten Datentag. Search Console (clicks + impressions je Datentag; Daten kommen 2–3 Tage verzögert, Fenster days+3; fehlende letzte Tage sind NICHT 0 und werden nicht bewertet, nur vorhandene Datentage): sc_clicks_drop / sc_impressions_drop (Ø letzte 3 Datentage <50 % der Vorperiode; Impressionen = Indexierungs-/Sichtbarkeitsproblem), sc_no_recent_data (letzter Datentag >5 Tage her oder keine Daten). „Gestern" ist bei Google Ads und GA4-sessions_drop_to_zero das Kalender-Gestern (fehlende Tage = 0 — morgens kann das der noch unverarbeitete Vortag sein); alle übrigen GA4- und Search-Console-Checks rechnen mit Datentagen, der letzte Datentag steht im Finding. Clarity (nur include_clarity=True, weil Clarity 10 Aufrufe je Projekt und Tag erlaubt; letzte 72 h, unabhängig von days): info-Findings js_errors_high (>5 % der Sitzungen mit JavaScript-Fehler), dead_clicks_high (>20 %), rage_clicks_high (>5 %) — Heuristik-Schwellen; warn-Findings clarity_no_data (keine einzige Sitzung in 72 h: Snippet prüfen) und clarity_metrics_unreadable (Kennzahl ohne lesbaren Anteil, steht in unreadable_metrics — nichts gilt still als 0). sources.clarity.metrics zeigt je Kennzahl Anteil (_pct), betroffene Sitzungen (_sessions) und Vorkommen (_count). Dieses Tool bewertet nur; Gesamtzahlen liefern ads_campaign_performance, ga4_report und sc_performance(dimensions=[]). days: Fensterlänge in Tagen (Default 14; Mindestlänge für 3-Tage-Vergleiche: 6). include_clarity: Clarity-Abfrage einschließen (verbraucht 1 der 10 Tagesaufrufe). workspace: Slug des Kunden-Workspace (optional bei nur einem Workspace).

Input Schema

NameRequiredDescriptionDefault
daysNo
workspaceNo
include_clarityNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say readOnly/openWorld; the description goes far beyond by disclosing partial-failure semantics (per-source status=error plus a sources_unavailable warning, never a whole-tool error while one source is connected), permission-scoped sources reporting not_permitted, and the no-sources error shape. It also defines exactly when `ok` is true (no warn/critical AND at least one source checked, info findings neutral).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and return shape are front-loaded, but the body is a dense multi-hundred-word run-on without headings or line breaks, cataloguing every individual check and threshold. Much of it is genuinely useful for interpreting findings, but the volume and lack of structure make it hard to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description covers the return contract (findings fields, ok, daily, per-source status enum incl. not_connected/not_permitted/skipped/error), time-window caveats (lagging Search Console data, GA4 24–48h processing), and the evaluation thresholds. Nothing an agent needs in order to call and interpret it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema carries only types/defaults, yet the description documents all three parameters: days (default 14, minimum 6 for the 3-day comparisons), include_clarity (costs one of ten daily Clarity calls), and workspace (slug, optional when only one workspace exists). This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: an anomaly check over the last N days across all connected workspace sources (Google Ads, GA4, Search Console, optionally Clarity), including the notable case that it works without a Google Ads account. It explicitly distinguishes itself from siblings: "Dieses Tool bewertet nur; Gesamtzahlen liefern ads_campaign_performance, ga4_report und sc_performance(dimensions=[])."

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternatives (ads_campaign_performance, ga4_report, sc_performance) and the condition separating them (raw totals vs. evaluation), and explains when to set include_clarity (rate-limited budget of 10 calls/project/day). It also gives the minimum window needed for 3-day comparisons (days ≥ 6), which is real usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources