Skip to main content
Glama
get-mcp-ads

TikTok Ads by Get MCP Ads

tiktok get asset urls

tiktok_get_asset_urls
Read-onlyIdempotent

Refresh expired TikTok media URLs for image and video assets by calling at display time to get publicly fetchable links.

Instructions

Re-resolve fresh, publicly fetchable URLs for specific TikTok library assets (file/video/ad/info and file/image/ad/info). Call at display or download time: every TikTok media URL is signed and expires.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
imageIdsNoImage IDs to refresh
videoIdsNoVideo IDs to refresh (at most 60 per call, TikTok's documented cap)
advertiserIdYesTikTok advertiser ID

Output Schema

TableJSON 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. First observedv2.0.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable context about URL expiry and the need to re-resolve, which is not covered by annotations. It doesn't contradict any annotation.

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 with no fluff. The key action and rationale are front-loaded, and the structure is clean and efficient.

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?

With an output schema present and annotations covering safety/idempotency, the description covers the essential purpose and usage timing. The optional nature of imageIds/videoIds is implicit from the schema's required field list, and the video cap is noted in the schema. Nothing critical 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 all parameters are documented. The description adds minimal parameter info beyond the schema—it mentions the asset types but not specific parameter details. Baseline 3 is appropriate when schema carries the load.

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 states a specific action (re-resolve fresh URLs) on a specific resource (TikTok library assets) and lists the asset types (file/video/ad/info and file/image/ad/info). It is clear and not a tautology. It doesn't explicitly name an alternative sibling, but the purpose is distinct from listing or retrieving assets.

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

Usage Guidelines4/5

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

The description explicitly says to call at display or download time and explains why (URLs are signed and expire). This gives clear contextual guidance. It doesn't state when not to use or name alternatives, but the when-to-use is well-defined.

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