Skip to main content
Glama

AdsAgent — TikTok Ads MCP

Read attribution connection status

mmp_get_state
Read-only

Summarise MMP connections and synced apps for the current user (one row per app: name, platform, source refs, event count, whether a cohort config exists), paged with limit/cursor. Pass connection_id (and optionally app_ref) to expand one connection/app into {connections, metadata_by_connection, cohort_configs_by_connection} with full event mappings. TikTok and Meta share the same MMP connections for a user, so this returns the same data the user would see on adsagent.md/dashboard/mmp. Mirror of Meta MCP mmp_get_state.

Call this BEFORE mmp_save_cohort_config or mmp_fetch_cohorts to discover valid connection_id + app_ref + kpi event names. Typing a kpi that the AppsFlyer app doesn't send silently returns zero rows.

REQUIRED: nothing. Optional: connection_id, app_ref (expand), limit (1..100, default 50), cursor. EXAMPLE: mmp_get_state({}) then mmp_get_state({"connection_id": "", "app_ref": "<app_ref>"})

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
cursorNo
app_refNo
connection_idNo
connection_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / app_ref
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "App Ref"
      +}
    • addedInput schema / properties / connection_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Connection Id"
      +}
    • addedInput schema / properties / cursor
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Cursor"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 50,
      +  "maximum": 100,
      +  "minimum": 1,
      +  "title": "Limit",
      +  "type": "integer"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / connection_context
      Added value: +{
      +  "pattern": "^mctx_v1_[0-9a-f]{64}$",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds valuable behavioral context: pagination via limit/cursor, the two response shapes (summary vs expanded mappings), and the silent-zero-rows failure mode. It does not state cursor expiry or auth requirements, keeping it below 5.

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?

Well front-loaded: what it returns, then expansion, then call-ordering guidance, then parameter summary and example. Slightly long but nearly every sentence carries useful information; the 'Mirror of Meta MCP' and dashboard parity notes are marginal but harmless.

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 zero-required-param read tool with no output schema, the description fully specifies both response shapes, pagination, expansion semantics, and the critical ordering relative to sibling cohort tools. An agent has everything needed to call it correctly.

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 0%, so the description must compensate. It explains connection_id and app_ref as expansion selectors, limit as 1..100 default 50, cursor for paging, and required/optional status. It omits any explanation of the connection_context parameter (the mctx_v1 token), leaving one of five params undocumented.

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 states a specific verb (summarise) and resource (MMP connections and synced apps), and describes the exact row shape (name, platform, source refs, event count, cohort config existence). It clearly distinguishes its summary mode from its expand mode and from sibling cohort tools.

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?

Explicitly instructs to call this BEFORE mmp_save_cohort_config or mmp_fetch_cohorts to discover valid connection_id, app_ref, and kpi event names, and warns that invalid kpis silently return zero rows. This is near-ideal when/why guidance with a named failure mode.

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