Metadata MCP Connector

Get Account UTM Defaults

get_account_utm_defaults

Read-only

Read the ACCOUNT-level UTM defaults - the tracking parameters every campaign channel inherits unless it stores its own.

            KEYWORDS: utm, utms, utm_source, utm_medium, utm_campaign, utm_term, utm_content, tracking parameters, account default, defaults, inherited, placeholder, UPDATE ME

            USE THIS TOOL WHEN THE USER ASKS:
            - "What are our default UTMs?" / "What UTM settings does the account use?"
            - "Which channels have customised UTM defaults?"
            - As the baseline before judging whether a campaign overrides anything.

            INHERITANCE RULE - READ BEFORE ANSWERING ANY UTM QUESTION:
            UTMs are inherited, never blank. A campaign channel with an empty stored
            mapping does NOT have "no UTMs" - it tracks with the account's UTM defaults,
            and where the account set nothing it tracks with the Metadata platform default.
            Roughly half of all channel rows in production are in that inherited state.
            NEVER report "no UTMs configured" from an empty stored field: report the
            resolved value and its origin.

            ORIGIN IS PER CHANNEL, not per key: a channel with an empty stored mapping
            inherits the account default whole, so a channel whose resolved mapping differs
            at all from that is stored on the campaign and every one of its values is an
            override. The per-key `same_as_default` flag says whether that one key happens
            to match the default anyway.

            ORIGIN VALUES:
            - campaign_override: stored on this campaign channel, differs from what it would inherit.
            - account_default: inherited from this account's UTM defaults.
            - platform_default: inherited from the Metadata-wide default (account set nothing).
            - not_set: the channel really has no UTM mapping (non-sponsored channels only).

            HONEST LIMIT: a campaign that stores a mapping identical to the default it
            would inherit is reported as inherited. The platform returns resolved values
            with no provenance, so that case cannot be distinguished - say so rather than
            claiming the campaign has no override.

            Takes no parameters - the account comes from the caller's credentials.
            There is no cross-account lookup.

            RESPONSE SHAPE:
            {
              "channels": {
                "LINKEDIN": {"origin": "account_default", "values": {"UTM_SOURCE": "Acme", ...}},
                "FACEBOOK": {"origin": "platform_default", "values": {"UTM_SOURCE": "Metadata", ...}}
              },
              "platform_default": {"UTM_SOURCE": "Metadata", "UTM_MEDIUM": "AD_CHANNEL", ...},
              "notes": ["..."]
            }

            A channel reported as platform_default was never customised on this account; the
            values shown are the ones campaigns actually inherit, not a blank.

            READ-ONLY. No tool here edits the defaults (set_campaign_utms edits ONE campaign
            channel's mapping, never the account defaults).

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: the inheritance rule (UTMs are never blank), the three origin values (campaign_override, account_default, platform_default, not_set), the honest limit about indistinguishable identical mappings, and the explicit READ-ONLY statement. It also clarifies that there is no cross-account lookup, which is not apparent from the schema or annotations.

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?

The description is long but well-structured with clear headers (KEYWORDS, USE THIS TOOL WHEN, INHERITANCE RULE, ORIGIN VALUES, HONEST LIMIT, RESPONSE SHAPE, READ-ONLY). It front-loads the core purpose and then provides necessary context for correct usage. While verbose, the complexity of the inheritance semantics justifies the length. Every section adds value, though it could be trimmed slightly without losing critical information.

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?

Given the tool has no parameters and no output schema, the description fully compensates by providing a concrete response shape example, detailed origin value definitions, and the inheritance rule that is essential for interpreting results. It also covers the edge case of identical mappings and clarifies that no tool edits defaults. Nothing an agent needs to call and interpret this tool correctly is missing.

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?

The input schema has zero parameters, so there is no parameter detail to explain. The description explicitly states 'Takes no parameters - the account comes from the caller's credentials,' which resolves any ambiguity about how the account is identified. Since there are no params, the baseline is 4, and the description adds this clarification, meriting a 4.

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?

The description opens with a precise statement of purpose: 'Read the ACCOUNT-level UTM defaults - the tracking parameters every campaign channel inherits unless it stores its own.' This clearly identifies the resource (account-level UTM defaults) and the action (read). It also distinguishes itself from sibling tools like get_campaign_utms and set_campaign_utms by naming them, making it easy for an agent to select the right one.

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?

The description explicitly lists when to use the tool with concrete user queries ('What are our default UTMs?', 'Which channels have customised UTM defaults?') and frames it as the baseline for judging campaign overrides. It also contrasts with set_campaign_utms ('edits ONE campaign channel's mapping, never the account defaults'), providing clear guidance on when not to use it.

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

All Metadata MCP Connector tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?