Skip to main content
Glama
TikTok Ads by Get MCP Ads

TikTok Ads by Get MCP Ads

tiktok validate query

tiktok_validate_query
Read-onlyIdempotent

Validates TikTok Ads metric and dimension combinations before query execution, catching grouping, lifetime, and compatibility errors.

Instructions

Validate a TikTok metric/dimension combination BEFORE executing. Checks dimension grouping rules, lifetime compatibility, and metric/dimension compatibility.

Input Schema

NameRequiredDescriptionDefault
metricsYesMetric keys to validate
dataLevelNoTikTok reporting aggregation level. Metrics and dimensions must be compatible with this level.AUCTION_CAMPAIGN
dimensionsNoDimension keys to validate
reportTypeNoNative provider report type; determines supported metrics and dimensions.
queryLifetimeNoRequest lifetime reporting instead of the explicit reporting period where TikTok supports it.

Output Schema

NameRequiredDescriptionDefault
resultYesOriginal tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / properties / result / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": true,
      -    "properties": {},
      -    "type": "object"
      -  },
      -  {
      -    "items": {},
      -    "type": "array"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "boolean"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": {},
      +    "properties": {},
      +    "type": "object"
      +  },
      +  {
      +    "items": {},
      +    "type": "array"
      +  },
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "boolean"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. First observedv2.0.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value by disclosing the three validation rule sets this preflight applies. It stops short of saying whether violations surface as an error or as a warnings payload — though the output schema may cover that.

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

Conciseness5/5

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

Two sentences, zero waste, with the preflight timing front-loaded before the list of checks. Nothing repeats the name or title.

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?

An output schema exists and annotations cover the read-only profile, so the description only needs to explain scope and purpose — which it does. For a 5-param, fully documented validation tool this is sufficient to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, including enum documentation for dataLevel and reportType, so the schema carries the semantics. The description only loosely echoes metrics/dimensions and 'lifetime compatibility' (queryLifetime) without adding format or constraint detail beyond the schema.

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

Purpose4/5

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

States a specific verb (Validate) and a specific resource (TikTok metric/dimension combination), and enumerates the rule classes checked (dimension grouping, lifetime compatibility, metric/dimension compatibility). It clearly is not a data-fetching sibling like tiktok_get_insights, though it never names the execution tool it gates.

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

Usage Guidelines3/5

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

'BEFORE executing' establishes timing relative to a query run, which is better than pure implication. But it does not name the sibling to run afterward (presumably tiktok_get_insights), nor state what to do when validation fails, so the guidance stays implicit.

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