Skip to main content
Glama

Fetch a creator's latest posts (live)

get_creator_posts
Read-only

Fetches a creator's recent posts from TikTok right now, through our proxy network, and returns captions, hashtags and per-post stats.

This is the evidence tool. Use it when the cached profile is not enough to decide: the bio is vague, the niche match is uncertain, or you need to see what the creator actually posts about before putting them in front of a client.

It is expensive and slow relative to everything else here (25 credits per call, a live network fetch per creator), so use it on a shortlist, never on a search page. A good shape is: sweep with search_creators, rank on the row data, then spend this on the ten or twenty creators the decision actually turns on.

Post thumbnails are shown inline in the chat by default, so the user can see what the creator's feed actually looks like alongside the captions. Pass include_images: false if you only need the text.

If it returns "still working", the scrape was kicked off and you were not charged. Call again in a few seconds.

An empty posts list never means "ask again". It is always a finished answer, and scrape_status plus posts_note say which kind: a creator with nothing public to read, or a scrape whose state we could not determine. Read them before concluding an account is dead.

For recency read newest_post_at, never last_analyzed_at. The second is when we read the profile and moves on every call; the first is when the creator actually last posted. When the gap is large, recency_note says so.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "creator": "<creator>"
    },
    "name": "get_creator_posts"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPosts to fetch, 1-50. Default 24.
creatorYesA tkc_* creator id or a TikTok username.
include_imagesNoShow each post's cover image inline in the chat. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare read-only/open-world/non-idempotent; the description goes far beyond by disclosing cost per call, latency, and a proxy network fetch. It documents the 'still working' partial response and that it is free, the meaning of an empty posts list via scrape_status and posts_note, and the newest_post_at vs last_analyzed_at distinction — exactly the non-obvious behavior an agent needs.

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?

Front-loaded with purpose, then cost, then workflow, then failure-mode handling — a logical order with no filler sentences. It runs long and repeats the cost/latency point across two paragraphs, which keeps it just below top marks.

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

Completeness5/5

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

With no output schema, the description carries the full burden and does so: it names the returned fields, explains the scraping states, and warns about the recency-field pitfall. For a live, costly, non-idempotent fetch this is enough for an agent to call it correctly and interpret results.

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% and already documents creator, limit and include_images, so baseline 3 applies. The description only adds marginal meaning by giving a rationale for include_images: false ('if you only need the text'), and says nothing extra about limit or the accepted creator id format.

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 (fetches), resource (a creator's recent posts), source (TikTok, live, via proxy), and return payload (captions, hashtags, per-post stats). It also self-labels as 'the evidence tool' and implicitly contrasts with the cached profile fetched by get_creator, so an agent can distinguish it from siblings without opening schemas.

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?

Explicit when-to-use (cached profile insufficient, vague bio, uncertain niche), explicit when-not (never on a search page, only on a shortlist), and a concrete alternative workflow: sweep with search_creators, rank on row data, then spend this on ten or twenty creators. Cost framing (25 credits) reinforces the routing decision.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.