Skip to main content
Glama

AgentIQ

by io.github.chrisgu

search_tiktok_products

[Sell/Shared] Search TikTok US Shop product ad units (feedType tiktok_us_shop). US-only inventory — pass country=US (or omit); non-US country returns empty. Returns ProductRecord[] with image.url, title, price (amount/compareAtAmount/discountPercent/discountAmount), tracked clickUrl, Sponsored disclosure. Chat clients: limit<=20 (default 6). Empty/feed_pending -> no-fill. Also: GET /api/public/tiktok-products?q=&page=&pageSize=. Never invent SKUs or deep links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoAlias for query.
geoNoAlias for country (ISO-3166-1 alpha-2).
pageNo1-based page (default 1).
limitNoMax products (chat cap 20; default 6). Site explorer uses pageSize up to 48 via HTTP.
queryNoKeyword search over title/brand/description (alias: q).
countryNoEnd-user ISO-3166-1 alpha-2. TikTok Shop is US-only — non-US returns empty. Alias: geo.
inStockOnlyNoWhen true, only in_stock rows.
minDiscountPercentNoOptional minimum price.discountPercent filter.

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are provided, so the description carries full transparency burden. It thoroughly discloses: geographic restriction (US-only), empty returns for non-US countries, the return structure (ProductRecord[] with specific fields), chat client limits, no-fill edge case, and a warning not to invent SKUs or deep links. This covers all key behavioral traits.

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?

The description is six sentences, each earning its place. It front-loads purpose and geographic constraint, then return structure, limits, edge cases, REST reference, and a warning. No redundancy or fluff. Excellent structure for quick agent parsing.

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?

Despite 8 optional parameters and no output schema, the description covers purpose, return fields, constraints, limits, and edge cases. It lacks pagination/sorting details and error handling, but given sibling complexity and schema richness, it is largely complete. Good, not perfect.

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 coverage is 100%, so baseline is 3. The description adds operational context (aliases, chat client limits, REST endpoint example) but does not elaborate on parameter formats or semantics beyond what the schema already provides. The added value is moderate, thus a 3 is appropriate.

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?

The description clearly states the tool searches 'TikTok US Shop product ad units', specifies the feed type ('feedType tiktok_us_shop'), and distinguishes it from siblings like 'search_affiliate_offers' (affiliate offers) and 'get_tiktok_product' (single product retrieval). The verb 'search' combined with the specific resource makes the purpose unambiguous.

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 gives explicit context: US-only inventory, non-US returns empty, chat client limit ≤20 (default 6), and empty/feed_pending yields no-fill. However, it does not explicitly state when to use this tool over siblings (e.g., 'search_affiliate_offers' vs. 'search_tiktok_products'), so it loses a point for excluding alternatives.

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

All AgentIQ toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.8/5.0
Disambiguation2/5

Multiple tools have overlapping or misleading purposes: buy_campaign and buy_placement are aliases of create_campaign, list_placement actually creates a placement, and get_attribution/get_campaign both provide campaign stats. The report_* tools are distinct but similarly named, increasing selection risk.

Naming Consistency3/5

Most tools follow a verb_noun snake_case pattern, but there are notable deviations: buy_campaign/buy_placement use 'buy' instead of 'create', list_placement is a creator not a lister, and simple nouns like 'wallet' and 'whoami' break the convention.

Tool Count2/5

At 31 tools, the server feels heavy. Several tools are redundant aliases (buy_campaign, buy_placement) or could be consolidated (multiple report_* and list_* variants), making the surface unnecessarily large for the ad marketplace domain.

Completeness3/5

The core lifecycle is covered: campaign/placement creation, delivery, reporting, attribution, refunds, and cashouts. However, there are gaps like no update_campaign, no true list_placements, and no get_placement, leaving some workflows incomplete.

Resources