TikTok Ads by Get MCP Ads

tiktok get report raw

tiktok_get_report_raw

Read-onlyIdempotent

Run native TikTok BASIC or AUDIENCE reports with custom dimensions and metrics, providing direct access to current API fields even when they are missing from tiktok://metrics.

Instructions

Run a native TikTok BASIC or AUDIENCE synchronous report with caller-selected dimensions and metrics. AUDIENCE supports demographics such as age/gender at campaign/adgroup levels; tiktok_get_audience_report provides a guided path. Use when a current API field is not yet in tiktok://metrics; unlike tiktok_get_insights, this tool does not calculate aliases or auto-split incompatible selections.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No	Page number to request, starting at 1.
`endDate`	No	Last date of the reporting period, in YYYY-MM-DD format, on or after startDate.
`metrics`	Yes	Native or documented calculated metric names to request. Check compatibility with the selected dimensions.
`pageSize`	No	Maximum items requested per page. Follow the returned pagination information for remaining results.
`dataLevel`	Yes	TikTok reporting aggregation level. Metrics and dimensions must be compatible with this level.
`filtering`	No	Native provider filter expressions; credentials and account overrides are not allowed.
`orderType`	No	Sort direction for the selected ordering field.
`startDate`	No	First date of the reporting period, in YYYY-MM-DD format.
`dimensions`	Yes	Native reporting dimensions. Validate compatibility with the selected metrics.
`orderField`	No	Provider field used to order report rows.
`reportType`	No	Native provider report type; determines supported metrics and dimensions.	BASIC
`serviceType`	No	TikTok report service category.	AUCTION
`advertiserId`	Yes	TikTok advertiser account ID as a string.
`queryLifetime`	No	Request lifetime reporting instead of the explicit reporting period where TikTok supports it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Original 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.

First observedv2.0.1Sep 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already carry readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false. The description adds real behavioral limits beyond those: the report is synchronous, it does not calculate aliases, and it does not auto-split incompatible selections. No contradiction with 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?

Three sentences, front-loaded with the core purpose, then audience scope, then routing guidance. No filler, though the second sentence packs two ideas (demographic support plus the guided alternative) into one sentence, making it slightly denser than ideal.

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

Completeness4/5

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

For a 14-parameter raw report tool, the description covers purpose, when-to-use, alternatives, and behavioral limits. Schema at 100% coverage, annotations, and an output schema carry the remaining load (pagination is already explained in the pageSize description). Nothing needed for correct invocation is missing.

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%, so baseline 3 applies. The description adds modest parameter meaning ('AUDIENCE supports demographics such as age/gender at campaign/adgroup levels'), but compatibility constraints are already documented in the schema property descriptions, so added value is marginal.

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 specific verb+resource ('Run a native TikTok BASIC or AUDIENCE synchronous report') with caller-selected dimensions/metrics. Explicitly distinguishes from siblings: 'unlike tiktok_get_insights, this tool does not calculate aliases or auto-split incompatible selections' and points to tiktok_get_audience_report as the guided path.

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?

'Use when a current API field is not yet in tiktok://metrics' gives an explicit trigger condition. It also states when not to use: tiktok_get_insights handles aliases/auto-splitting, and tiktok_get_audience_report is the guided audience path — clear alternatives with selection criteria.

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

Deploy Server