Skip to main content
Glama
dhawalshah

tiktok-ads-mcp

get_audience_reach_tool

Estimate audience reach for TikTok ads by specifying targeting criteria such as age, gender, location, and interests. Get upper and lower audience size estimates and reach trends to plan campaigns.

Instructions

Get estimated audience reach for given targeting criteria. NOTE: This endpoint requires allowlist access from TikTok. Contact TikTok support if you receive a 404 error. objective_type examples: 'TRAFFIC', 'CONVERSIONS', 'APP_INSTALL'. gender: 'GENDER_MALE' | 'GENDER_FEMALE' | 'GENDER_UNLIMITED'. Returns estimated_audience_size_lower, estimated_audience_size_upper, reach_trend.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageNo
genderNo
placementsNo
location_idsNo
advertiser_idYes
objective_typeYes
interest_category_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the allowlist requirement and the 404 error possibility, which is useful behavioral context. It also lists the return fields (estimated_audience_size_lower, estimated_audience_size_upper, reach_trend). However, it doesn't mention rate limits, pagination, or what happens with invalid targeting criteria. The description adds some value but not rich behavioral detail.

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 compact and front-loaded with the core purpose. The additional notes on allowlist access and parameter formats are useful and not redundant. It's a bit dense with multiple notes in one paragraph, but each sentence earns its place. No wasted words.

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

Completeness3/5

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

The tool has 7 parameters, no annotations, and an output schema exists. The description covers the return fields and two parameter formats, but leaves several parameters unexplained. The allowlist note is important context. For a tool with this complexity, the description is adequate but not complete—an agent might still be unsure about how to format location_ids or interest_category_ids.

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 0%, so the description must compensate. It explains objective_type and gender formats, which adds meaning beyond the schema. However, it doesn't explain age, placements, location_ids, interest_category_ids, or advertiser_id. With 7 parameters and only 2 explained, the compensation is partial. Baseline 3 is appropriate because the description does add some value but leaves gaps.

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?

The description clearly states the tool's purpose: 'Get estimated audience reach for given targeting criteria.' This is a specific verb ('Get') and resource ('estimated audience reach'), and it distinguishes itself from sibling tools like get_targeting_options_tool (which likely returns targeting options rather than reach estimates). It doesn't explicitly name a sibling, but the purpose is clear enough.

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?

The description provides some usage context: it notes the endpoint requires allowlist access and gives examples for objective_type and gender. However, it doesn't explicitly state when to use this tool versus alternatives like get_targeting_options_tool or get_reports_tool. The allowlist note is useful but not a full usage guideline.

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