AdsAgent — TikTok Ads MCP

Read cached business asset links

assets_lookup_business_links

Read-only

Read the authenticated tenant's cached TikTok asset topology. Provide exactly one native ID selector: bc_id, advertiser_id, app_id, pixel_id, identity_id, or connection_id. Names are not selectors. BC/account/connection selectors inspect forward relationships; app/pixel/identity selectors inspect exact advertiser links and BC context. This is the TikTok counterpart of Meta assets_lookup_business_links; use TikTok selectors, not Meta business_id/page_id or FB user identifiers. Returns bounded nodes and edges with per-connection evidence and source fields. Do not merge identity observations across identity_type/authorized BC. Cached owner_bc_id and observation edges do not prove ownership, current permissions or create eligibility. Shared BC membership is never an advertiser asset link. Missing matches do not prove no relationship exists. Optional limit=1..50 (default 20) and cursor. Follow next_cursor serially with identical selector and limit; complete means result pagination only. Inspect coverage for source read limits and non-atomic cache reads. Local creative upload/mapping is separate: use creatives_list and create prepare. No source refresh or provider write occurs. EXAMPLE: assets_lookup_business_links({"advertiser_id": "<advertiser_id>"})

Input Schema

TableJSON Schema

Name	Required	Description	Default
`bc_id`	No
`limit`	No
`app_id`	No
`cursor`	No
`pixel_id`	No
`identity_id`	No
`advertiser_id`	No
`connection_id`	No
`connection_context`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026
- addedInput schema / properties / connection_context
```
Added value: +{
+  "pattern": "^mctx_v1_[0-9a-f]{64}$",
+  "type": "string"
+}
```
First observedSep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover readOnly/openWorld/destructive, but the description adds substantial context: results are cached (not atomic), no refresh or provider write occurs, cache evidence does not prove ownership/permissions/create eligibility, shared BC membership is not an asset link, and missing matches are inconclusive. That is genuinely beyond what the annotations provide.

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?

Purpose is front-loaded and every sentence carries operational weight, but the block is dense and packed with caveats that could be grouped more tightly. Still appropriately sized for a high-complexity, 9-parameter lookup.

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 no output schema and nine parameters, the description supplies the return shape (bounded nodes/edges with per-connection evidence), pagination semantics, and a long list of interpretive caveats. The only real gap is the unexplained connection_context parameter.

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 carry the load. It documents the selector semantics (which of bc_id/advertiser_id/app_id/pixel_id/identity_id/connection_id to use and what each reveals), the exactly-one rule, and limit=1..50 default 20 plus cursor. It does not explain connection_context (the mctx_v1_ token), leaving one parameter 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?

States a specific verb+resource: reading the authenticated tenant's cached TikTok asset topology. It explicitly differentiates itself from the Meta counterpart (assets_lookup_business_links with Meta IDs) and from local creative tooling (creatives_list, create prepare), so an agent can place it precisely among siblings.

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?

Gives explicit selection rules: exactly one native ID selector, which selector family maps to which relationship type (BC/account/connection = forward; app/pixel/identity = exact advertiser links), plus hard exclusions ('use TikTok selectors, not Meta business_id/page_id'). It also names the alternative tool for the separate creative-upload case.

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

All AdsAgent — TikTok Ads MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?