13 TikTok endpoints. Pay per call in USDC via x402.
Scored across 15 tools
Most endpoints are separated by resource (hashtag, user, music, location), but tiktok_post and tiktok_post_id have identical descriptions and appear to duplicate the "Post — TikTok" action. Without additional qualifiers, an agent cannot reliably choose between them.
The tiktok_<entity>_<detail> pattern is used consistently across most data tools, and the billing tools check_balance/topup_credits use a different verb/noun style. tiktok_post and tiktok_post_id also break the pattern by mixing a bare resource with an ID-suffixed variant.
15 tools is at the upper end of a reasonable scope for a TikTok data API, covering posts, users, comments, search, and several discovery surfaces. The redundant post/post_id pair makes the count feel slightly padded, but it is not excessive.
The set covers the major TikTok lookup and search surfaces: hashtags, locations, music, posts, comments/replies, users, followers/followings, and user posts. Missing search-by-user and metadata endpoints for music/location are minor gaps for a read-only data server.
Free. Show the remaining credit balance for the API key sent in this connection's Authorization header. Call this before a long run of paid requests.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral disclosure burden. It discloses that the call is free, that it checks the balance associated with the connection's Authorization header, and implies it is a read-only informational operation. This is good coverage for such a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundancy. It front-loads the key value ('Free'), states the action, and then provides a practical usage hint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema utility tool, the description covers what the tool does, its cost implication, the authentication context, and when to call it. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to describe. The baseline for zero parameters is 4, and the description adds relevant context by clarifying that the balance is tied to the Authorization header rather than to an explicit parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Show') and resource ('remaining credit balance for the API key'), making the tool's purpose unambiguous. It also distinguishes itself from likely siblings like topup_credits by focusing on balance checking rather than purchasing credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit timing recommendation: 'Call this before a long run of paid requests.' It does not state when not to use the tool or name alternatives, but the guidance is useful and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Hashtag handle — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Required. Path parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the endpoint is paid ($0.004), how to pay (x402 or Bearer bby_live_... credits key), and that it returns live JSON data. However, it does not state whether it is read-only, what happens on insufficient credits, or any rate limits, leaving the behavioral profile only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and mostly front-loaded, with no excessive prose. Yet part of it, "Hashtag handle — TikTok," merely restates the tool name and adds no value, while the genuinely useful pricing and authentication details are packed into later fragments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is incomplete. It never explains what data is returned, how the `name` parameter maps to a hashtag handle, or what a successful response looks like. The pricing and auth details are helpful but do not make the tool safely and correctly invokable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the lone parameter `name` is already documented as a required path parameter. The description adds no further meaning about the expected format, such as whether a hashtag symbol should be included, so it stays at the baseline for fully schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a fragment: "Hashtag handle — TikTok" restates the tool name/resource without any verb. "Live data as JSON" hints that it is a data retrieval operation, but the description never explicitly states what is fetched or returned for a hashtag handle, and it does not differentiate this from tiktok_hashtag_posts beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like tiktok_hashtag_posts or tiktok_user_handle. There are no conditions, exclusions, or use-case hints, only a price and an authentication note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Hashtag posts — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. | |
| region | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the tool is paid, specifies the cost, mentions payment via x402 or a Bearer credits key, and says data is returned as live JSON. However, it omits operational details like authentication failures, rate limits, pagination behavior, or whether a credit balance is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the most actionable fact—the cost. There is no wasted text, though the main purpose could be stated more explicitly with a verb rather than the fragment 'Hashtag posts — TikTok.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid tool with three parameters and no output schema, this description is incomplete. It does not explain what the returned JSON looks like beyond 'JSON', how cursor pagination works, how region affects results, or exactly what identifier is expected. The payment information is helpful but leaves significant operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the tool description adds no parameter-level details. The description does not clarify that 'id' refers to a hashtag ID or explain what 'cursor' and 'region' control, but the schema already documents these parameters as required/optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'hashtag posts' on TikTok, which distinguishes it from sibling tools like tiktok_music_posts and tiktok_user_posts. However, it lacks an explicit verb like 'get' or 'list', so it reads as a noun-phrase fragment rather than a full statement of action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as tiktok_hashtag_handle or other post-listing tools. It only notes pricing and payment methods, which is contextual but does not help an agent decide which sibling is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Location posts — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Optional. | |
| region | No | Optional. | |
| locationId | Yes | Required. Path parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does a solid job: it discloses that the tool is paid ($0.004), returns live data as JSON, and requires payment via x402 or an Authorization Bearer credits key. This gives the agent important operational context beyond the schema, even though it does not discuss rate limits or pagination details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and every fragment adds value: cost, resource, output format, and payment method. It is slightly choppy because the pricing/payment information is split across the beginning and end, but overall it is efficient and front-loaded with the most decision-relevant fact (the cost).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers payment, authentication, and output format, which are essential for calling this paid API. However, it does not explain what locationId should look like, how cursor pagination works, or what the returned JSON represents beyond 'live data', leaving some gaps for a tool with no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning about locationId, cursor, or region beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: TikTok posts for a location. It distinguishes this tool from sibling tools like tiktok_hashtag_posts and tiktok_music_posts via the 'location' qualifier, but it lacks an explicit verb such as 'list' or 'fetch', so the action is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Location posts — TikTok' implies that this tool should be used when retrieving TikTok posts tied to a location, which is reasonable context. However, it does not explicitly say when to prefer this over alternatives or when not to use it, and no sibling tools are named as alternates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Music posts — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. | |
| region | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses useful behavioral traits: the call costs $0.004, it returns live JSON data, and it requires x402 payment or a bearer credits key. However, with no annotations available, the description does not explicitly state that the operation is read-only, explain pagination behavior, or describe failure modes such as insufficient credits or invalid ids.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loads the most decision-relevant fact, the cost. Every clause carries some information and there is no filler. However, the purpose clause reads as a fragment and omits a verb, so brevity comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal parameter semantics, the description is not complete enough to invoke reliably. The required id is unexplained, region and cursor have no format or meaning, and there is no description of return fields or pagination. The payment details are the only context-rich part.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the schema entries are mostly structural: 'Required. Path parameter.' and 'Optional.' The tool description adds no explanation of what id represents, so an agent cannot tell whether it is a music track ID, post ID, or account ID. Cursor and region also remain semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the domain as TikTok music posts and implies data retrieval with 'Live data as JSON', but it never states an actual verb such as 'get', 'list', or 'search'. It is closer to a category label than a functional definition, and it does not specify whether the tool returns posts for a music track, a single post, or a feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools like tiktok_hashtag_posts, tiktok_user_posts, or tiktok_location_posts. The only differentiator is the word 'music', which is implied by the tool name rather than explained by the description. No alternatives, exclusions, or selection conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Post — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose cost ($0.004), live data behavior, JSON response format, and payment options. However, it never explicitly states whether this is a read-only operation or what side effects, if any, occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and contains no fluff, but information is not well structured: pricing is front-loaded ahead of the core purpose, and the main phrase 'Post — TikTok' is ambiguous. It is concise but at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description is incomplete for correct invocation. It fails to clearly specify that the tool fetches a TikTok post from a URL, and it does not describe what the returned JSON contains beyond 'live data.' An agent would struggle to understand the exact behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'url', with description 'Required.' — coverage is 100%, so the baseline is 3. The description does not add any semantic detail about the URL (e.g., that it should be a TikTok post URL), but the tool name and 'Post — TikTok' provide weak context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Post — TikTok' which identifies the resource but lacks a clear verb like 'get' or 'fetch.' The phrase 'Live data as JSON' hints that this retrieves data, but it's not explicit whether the tool creates a post or returns one. It is distinguishable from siblings only by name, not by a stated action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like tiktok_post_id or tiktok_post_comments. The description only mentions pricing and payment methods, not selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Post comments — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful details about cost, live JSON output, and authentication, but it leaves the core behavior ambiguous and never clarifies whether this is a read operation or a write operation. No output format details, pagination behavior, or side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loads the cost and payment requirement, but 'Post comments — TikTok' largely restates the tool name and does not earn its place. Brevity here contributes to under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain what the call returns, what the id refers to, and how the cursor works. It only states 'Live data as JSON' and payment details, which is insufficient for an agent to confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents that 'id' is a required path parameter and 'cursor' is optional. The description adds no extra meaning about what the id represents, and it does not clarify whether the cursor is pagination-related, so it provides the baseline value only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description mostly restates the tool name ('Post comments — TikTok') without a clear verb: an agent cannot tell whether this retrieves the comments on a TikTok post or publishes a comment. It also does not differentiate this tool from the closely related sibling tiktok_post_comments_replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage context given is cost and payment method ('Paid ($0.004)', 'Pay with x402 or an Authorization: Bearer bby_live_... credits key'). There is no guidance about when to choose this tool instead of tiktok_post_comments_replies or tiktok_post, nor any stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Post comments replies — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. | |
| commentId | Yes | Required. Path parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does add genuine behavioral context: per-call cost ($0.004), the payment method (x402 or Bearer bby_live_... credits key), and 'Live data as JSON' indicating fresh, readable output. However, it never clarifies whether this is a read or write operation, which is the most fundamental behavior, and the ambiguous 'Post' wording makes this a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and each fragment (cost, purpose, format, payment) earns some space. However, the purpose statement is an awkward, ambiguous fragment rather than a clear front-loaded sentence, and placing cost before purpose reduces clarity rather than aiding it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations to compensate, so the description must stand alone — and it does not. It fails to state the operation type, explain what the two required parameters (id, commentId) refer to, or describe cursor-based pagination. An agent could easily misuse this tool or call the wrong sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description adds nothing about id, commentId, or cursor; the schema documents them only as 'Path parameter' and 'Optional' with no semantic depth. Parameter names are reasonably self-explanatory, but the role of cursor in pagination is left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads 'Post comments replies — TikTok,' a telegraphic fragment that essentially restates the tool name without a clear verb. 'Post' is ambiguous — it could mean fetching replies on a post or publishing replies — so an agent cannot confidently know what action this tool performs. 'Live data as JSON' hints at a read operation but does not rescue the missing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus its siblings, notably tiktok_post_comments, which presumably handles the parent comments of these replies. The only usage cue is the tool name itself. There are no exclusions, alternatives, or context conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Post — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| region | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention the cost, the JSON format, and payment methods, which is useful context, but it fails to state the core operation (e.g., that this is a read-only lookup by post ID), any side effects, or error behavior. The vague 'Post — TikTok' does not clarify whether this is a mutating or read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of filler, but the structure is fragmented and telegraphic. The payment information is front-loaded rather than a clear statement of purpose, and the grammar ('Post — TikTok') undermines readability. It is compact, but not well-structured for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description is still incomplete. It lacks an explicit operation, usage context, and any mention of expected output beyond 'JSON.' With no output schema and no annotations, an agent has insufficient information to confidently invoke the tool and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since both 'id' and 'region' have descriptions in the schema. The description adds no additional meaning beyond the schema, such as ID format, region semantics, or how they interact. Baseline of 3 applies because the schema already documents the parameters adequately, albeit minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a resource (TikTok post) and mentions 'Live data as JSON,' which implies retrieval, but it lacks an explicit verb like 'get' or 'fetch.' The fragment 'Post — TikTok' is ambiguous and could be misread as an action to create a post. It also does not distinguish this tool from the sibling 'tiktok_post,' leaving an agent uncertain about which one to select.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as tiktok_post or tiktok_post_search. The description only adds payment details and a JSON return type; it does not mention conditions, exclusions, or context that would help an agent choose correctly among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). Post search — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Optional. | |
| region | No | Optional. | |
| keyword | Yes | Required. | |
| sortType | No | Optional. One of: RELEVANCE, MOST_LIKED, DATE_POSTED. | |
| dateRange | No | Optional. One of: ALL_TIME, YESTERDAY, THIS_WEEK, THIS_MONTH, LAST_THREE_MONTHS, LAST_SIX_MONTHS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description surfaces important non-obvious behaviors: the call costs $0.004, returns live data as JSON, and requires payment via x402 or a bearer credits key. This is significant operational context beyond what the schema provides, though it does not discuss rate limits, result limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the most critical operational facts: cost, purpose, output format, and authorization. It contains no filler sentences, though the payment information appears twice in slightly different forms, which is mildly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter paid search endpoint with no output schema, the description covers pricing, live JSON output, and auth, but leaves out expected response shape, pagination behavior, and what search criteria beyond keyword are supported. The schema fills most parameter gaps, so this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter and its optional/required status. The description adds no parameter-level meaning, so the baseline 3 applies; it neither clarifies the semantics of cursor/region nor needs to given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Post search — TikTok', identifying the resource and operation clearly enough to distinguish from sibling tools like twitter_search and youtube_search_video. It lacks a full verb phrase and details like whether it returns only posts or comments, but the platform and core function are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over the many sibling search tools, and it names no alternatives or exclusions. It only indicates the platform and pricing, leaving the agent to infer the appropriate use case from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). User followers — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does disclose meaningful operational traits: the operation costs $0.004, returns live data as JSON, and requires payment via x402 or a Bearer credits key. However, it does not mention side effects, pagination behavior, or what the response contains beyond being JSON.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and every fragment earns its place: cost, resource, data format, and payment method. It is front-loaded with the most decision-relevant fact (paid) before the resource itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and two parameters, the description is incomplete. It does not clarify what 'id' should be, how pagination via 'cursor' works, or how to obtain a valid credential beyond showing a partial Bearer key format. An agent would likely need to open sibling tools or guess at the required identifier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning; 'id' remains ambiguous (TikTok user ID vs. handle vs. username), and 'cursor' is only stated as optional in the schema. The description does not compensate for that ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource clearly: 'User followers — TikTok' implies retrieving the followers of a TikTok user. However, it uses no explicit verb like 'list' or 'fetch,' and it does not distinguish itself from the closely named sibling tiktok_user_followings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The near-identical sibling tiktok_user_followings is not mentioned, and no conditions or exclusions are provided. The only usage-related information is the payment method, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). User followings — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the operation is paid, the cost, acceptable payment methods, and that output is live JSON. However, it does not mention pagination via cursor, error behavior, rate limits, or confirm it is read-only, which are left to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and scannable, with cost and payment instructions front-loaded. The phrase 'User followings — TikTok' is redundant with the tool name, but no words are wasted overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must explain both inputs and expected outputs. It covers payment and JSON format but not what 'id' identifies, what data the followings result contains, or how cursor pagination works. This is not complete enough for reliable invocation without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds nothing about the parameters: 'id' remains ambiguous as a path parameter and 'cursor' is only labeled optional, so the agent gains no extra semantic understanding from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'User followings — TikTok' but lacks an explicit verb such as 'List' or 'Retrieve.' It mostly restates the tool name and implies data output via 'Live data as JSON,' but it does not clearly state that the tool returns the list of accounts a user follows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus similar siblings like tiktok_user_followers or tiktok_user_posts. The description only covers payment, data freshness, and format, leaving any usage context to be inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). User handle — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Required. Path parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose non-obvious operational facts: the call is paid ($0.004), returns live data as JSON, and requires payment via x402 or a bby_live_... Bearer key. However, it does not state whether the operation is read-only, what exactly it does, or what the JSON contains. Since annotations are absent, the description carries the full burden and only partially meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is admirably short and front-loads cost, but the core purpose is a fragment ('User handle — TikTok') that conveys little. While every clause adds some detail (payment, live data, format), the absence of a clear verb makes it under-specified rather than concise in the helpful sense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the bar is low, yet the description still fails to state the basic operation and return contents. 'Live data as JSON' is the only return hint; a caller cannot know what fields to expect or how this tool differs from the many sibling TikTok tools. This is not enough for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents username as a required path parameter with 100% coverage, so the description does not need to repeat it. The description adds no further semantic detail about username format (e.g., '@' symbol, normalization, length), so it sits at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says only 'User handle — TikTok,' a noun phrase that restates the tool name rather than stating an action. There is no verb like 'get' or 'resolve,' so an agent cannot tell whether this tool fetches user details, resolves handles to IDs, or performs some other operation. It does not differentiate from siblings such as tiktok_user_posts or tiktok_post_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is present. The description mentions payment and live data but never identifies the scenario for choosing this tool over siblings like tiktok_user_followers or tiktok_post_id. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid ($0.004). User posts — TikTok. Live data as JSON. Pay with x402 or an Authorization: Bearer bby_live_... credits key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Required. Path parameter. | |
| cursor | No | Optional. | |
| region | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add valuable operational context: cost per call ($0.004), live data, and the two accepted payment/auth methods. However, it omits important behavior like whether the call is read-only, how pagination works, rate limits, and what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and fluff-free, giving cost, purpose, data format, and auth in four fragments. It is not beautifully structured and redundantly repeats 'TikTok' from the tool name, but it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid tool with no annotations and no output schema, the description is insufficient. It never explains what value to pass as 'id', how 'cursor' or 'region' influence results, or what the returned JSON contains, so an agent cannot reliably invoke it without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but each parameter has only minimal description ('Required. Path parameter.', 'Optional.'). The tool description adds no meaning about what 'id' should contain (user ID? username?), what 'cursor' controls, or what 'region' affects, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'User posts — TikTok', which identifies the resource but lacks an explicit verb like 'list' or 'fetch'. It distinguishes from sibling tools like tiktok_user_followers, but only weakly; the tool name itself does most of the clarifying work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of a sibling such as tiktok_post_search or tiktok_user_handle. No exclusions, prerequisites, or alternative routes are mentioned, leaving the choice entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid (the amount you choose, minimum $1). Buy prepaid credits with x402 so later calls skip the per-call payment round trip. With an Authorization: Bearer bby_live_... header on this connection it recharges that key. Without one, the paying wallet becomes the account and a new API key is minted and returned once — store it as a secret, it cannot be recovered.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to add, in USD. Minimum 1. | |
| rotate | No | Mint a replacement key for the paying wallet, invalidating the old one immediately. Only valid when no Authorization header is sent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the payment requirement, the recharge versus new-key behavior, the one-time key return, and the critical caveat that the key cannot be recovered. This is rich, honest behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, with every sentence contributing essential details. The key caveat about key recovery is front-loaded near the end, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description provides enough context to invoke it correctly: payment amount, minimum, auth modes, and outcome. It does not describe error cases or the exact response format beyond key return, but the critical operational details are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining how the amount ties to prepaid credits, how the Authorization header changes the effect of the call, and that a new key is returned only once and must be stored as a secret. This enhances the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Buy prepaid credits with x402') and a specific resource, making the tool's purpose immediately identifiable. It also explains the benefit ('later calls skip the per-call payment round trip'), which helps distinguish it from the other listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions for two use cases: with an Authorization header it recharges the key, and without one it mints a new API key. It does not explicitly compare against sibling tools, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
describe_endpointfetch_datasearch_endpointstiktok_hashtag_handletiktok_hashtag_poststiktok_location_poststiktok_music_poststiktok_posttiktok_post_commentstiktok_post_comments_repliestiktok_post_idtiktok_user_followerstiktok_user_followingstiktok_user_handletiktok_user_postsappstore_appsfetch_data1 field changedInput schema / properties / path / descriptionPrevious value: -"Endpoint path from search_endpoints, e.g. /api/twitter/search"New value: +"Endpoint path from search_endpoints, e.g. /api/tiktok/post/search"google_maps_place_searchgoogle_news_searchgoogle_searchgoogleplay_appsinstagram_user_handlereddit_search_postsearch_endpoints1 field changedInput schema / properties / serviceRemoved value: -{
- "description": "Restrict to one service slug, e.g. 'twitter'",
- "type": "string"
-}twitter_searchyelp_searchyoutube_search_videoappstore_appsfetch_data1 field changedInput schema / properties / path / descriptionPrevious value: -"Endpoint path from search_endpoints, e.g. /api/tiktok/post/search"New value: +"Endpoint path from search_endpoints, e.g. /api/twitter/search"google_maps_place_searchgoogle_news_searchgoogle_searchgoogleplay_appsinstagram_user_handlereddit_search_postsearch_endpoints1 field changedInput schema / properties / serviceAdded value: +{
+ "description": "Restrict to one service slug, e.g. 'twitter'",
+ "type": "string"
+}twitter_searchyelp_searchyoutube_search_videocheck_balancedescribe_endpointfetch_datasearch_endpointstiktok_post_searchtopup_credits15 Twitter / X endpoints. Pay per call in USDC via x402.
15 YouTube endpoints. Pay per call in USDC via x402.
15 Reddit endpoints. Pay per call in USDC via x402.
16 Instagram endpoints. Pay per call in USDC via x402.
Add one secure layer between your agents and this server.