Skip to main content
Glama

marketing_utilities

Read-onlyIdempotent

Free marketing utilities: no Supermetrics subscription or connected data source needed.

Actions:

  • utm_build: tag each of the urls with source/medium/campaign/term/content, correctly encoded (macros like {campaignid} kept), validated against your team's conventions.

  • utm_parse: check the urls against your team's conventions and GA4 channel rules. For one campaign used in several places (an event's booth QR code, printed cards, follow-up email, social post), build one link per placement with a different utm_content, so reports show which placement worked. utm_build and utm_parse return suggested_url (the link with casing/separator fixed), fixed (what changed in it) and unresolved (issues that need a decision, e.g. an unapproved source). Show suggested_url and fixed in the same reply as the check, then ask only about unresolved; never wait to be asked for a fixed link.

  • pagespeed_check: PageSpeed Insights for up to 10 urls (run in parallel; 30s-2min): scores, lab and field vitals, top fixes; detail="full" for every finding. Returns within ~45s; if checks are still running it returns status="running" and a job_id: poll with {"action":"pagespeed_check","job_id":...} about every 30s. Results are cached for 24h (cached=true, checked_at); pass refresh=true only after the page has changed.

  • link_check: follow up to 50 urls through redirects; do UTM and click-id params (gclid, fbclid...) reach the landing page, and at which hop are they lost. Also broken pages, loops, tagging mistakes.

  • web_vitals_trend: ~6 months of real-user LCP/INP/CLS/FCP/TTFB for up to 50 sites (bare domain) or pages.

  • safety_check: up to 50 urls, domains or email addresses (e.g. a cold-pitch sender) and every host they redirect through: Web Risk malware/phishing flags, invalid or expiring certificates, domains expiring soon or registered in the last 30 days, and senders with no working website.

  • link_preview: how up to 50 urls render when shared on LinkedIn, Facebook, X and Slack; flags missing or small og:image, missing description, truncated titles.

  • email_dns: SPF, DKIM, DMARC, MX and BIMI for up to 50 domains (urls may be domains, emails or URLs).

  • char_limits: exact lengths of up to 200 texts against Google Ads, Meta, LinkedIn and X limits (counted as each platform counts). Use it whenever copy must fit a limit; do not count characters yourself. Google asset fields (path, long_headline, business_name, callout, sitelink_text, sitelink_description) are checked only when named in field.

Results: every result has input (as sent), url, status (ok|warning|critical|unknown) and findings[] of {code, severity, message, suggestion?, ...extras}; unknown results carry error {code, message} (e.g. quota_exhausted, daily_limit, no_data, url_throttled). Each batch has a summary of counts.

UTM conventions come from business context (tags='utm-conventions'). A JSON object is enforced; every key is optional; lists are exact, case-sensitive matches: {"approved_sources":[...],"approved_mediums":[...],"blocklist":{"utm_campaign":["test"]}, "regex":{"utm_campaign":"\d{4}"},"max_length":{"utm_campaign":60},"casing":"lowercase"|"as_is", "separator":"-"|"_","require_all_core":true} When utm_source is a known ad network (google, bing, facebook/instagram, tiktok, linkedin, snapchat, pinterest), utm_build returns network {medium, campaign_macro, id_macro, click_id} and both actions flag macros written in another network's syntax, which that network would leave unfilled. utm results report conventions_source: team (JSON enforced), team_free_text (returned as team_conventions for you to apply) or defaults (lowercase, hyphens).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "marketing_utilities"
  }
}

Input Schema

NameRequiredDescriptionDefault
termNoutm_term value (utm_build)
urlsNoURLs to act on (every action except char_limits). Max 10 for pagespeed_check, 50 otherwise. web_vitals_trend: a bare domain = whole site. email_dns: domains, e.g. example.com
fieldNochar_limits: check only this field (e.g. rsa_headline for Google headlines, primary_text for Meta, post for X). Default: every field of each platform
textsNochar_limits: the headlines/captions to measure
actionYesutm_build (tag urls), utm_parse (check urls), pagespeed_check, link_check (tracking survives redirects), web_vitals_trend (real-user history), safety_check (malware/phishing, certificate and domain expiry), link_preview (how a shared link renders), email_dns (SPF/DKIM/DMARC), char_limits (ad/social copy lengths)
detailNopagespeed_check: summary (scores, vitals, top 3 fixes) or full (all findings)
job_idNopagespeed_check: poll a check that was still running (returned when it took over 45s)
mediumNoutm_medium value (utm_build)
sourceNoutm_source value (utm_build)
contentNoutm_content value (utm_build)
refreshNopagespeed_check: ignore cached results (kept 24h) and re-test; use only after the page changed
campaignNoutm_campaign value (utm_build)
strategyNopagespeed_check device: MOBILE or DESKTOP
platformsNochar_limits: platforms to check against (default: all)
dkim_selectorNoemail_dns: your DKIM selector if it is custom (common ones are probed automatically)

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNo
notesNo
successYes
business_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, and the description still adds substantial operational context: 30s-2min runtimes, a ~45s synchronous cutoff that returns status='running' plus a job_id, 30s poll cadence, 24h caching with refresh semantics, and per-batch limits (10 URLs for pagespeed_check, 50 otherwise, 200 texts). It also enumerates the status vocabulary and error codes (quota_exhausted, daily_limit, no_data, url_throttled), which is exactly the context an agent needs to handle results.

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

Conciseness4/5

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

Front-loaded with the value proposition, then an action list, then a shared Results contract, then the conventions block — a sensible order for a nine-action dispatcher. It is dense and long, and the wrapped bullet lines are a bit awkward, but nearly every sentence carries actionable detail rather than filler.

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?

For a nine-action, 15-parameter tool this is close to complete: every action, every limit, the polling path, the shared findings/status envelope, and the conventions resolution order are covered. Return values are also restated even though an output schema exists, which is redundant but not harmful given the heterogeneous per-action payloads.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: the UTM conventions JSON contract (approved_sources, regex, casing, separator, require_all_core), the network-macro behaviour for known ad networks, and conventions_source values. It also clarifies dkim_selector auto-probing and the char_limits field scoping. Minor gap: it does not explain how detail/strategy/platforms interact beyond restating them.

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?

Opens with a precise framing ('Free marketing utilities: no Supermetrics subscription or connected data source needed') and then names each of the nine actions with a specific verb+resource (utm_build tags URLs, link_check follows redirects, email_dns checks SPF/DKIM/DMARC). An agent can pick the right action without opening the enum schema.

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

Usage Guidelines4/5

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

Gives explicit when-to-use cues for most actions, including the utm_build vs utm_parse split and a directive ('Use it whenever copy must fit a limit; do not count characters yourself'). It also prescribes workflow for pagespeed_check polling and refresh. It does not say when to reach for this tool instead of sibling tools such as data_query or manage_audits_and_monitors, so routing from outside the tool is left implicit.

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