TikTok Unauthorized API Scraper
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation3/5
The tools have overlapping purposes that could cause confusion, such as multiple tools for finding users (e.g., find_user_by_sec_user_id_fetch_profile_info_fetch_user_p, find_user_by_username_fetch_profile_info_fetch_user_post, and find_user_by_username_fetch_profile_info_fetch_user_post_2) with unclear distinctions. However, descriptions help differentiate some tools, like find_liked_posts_by_sec_user_id for liked posts versus find_post_by_link_or_aweme_id_fetch_cover_links_metrics_ for post data.
Naming Consistency2/5Naming is inconsistent with mixed conventions: some tools use snake_case with verbs like 'find' or 'get' (e.g., find_user_by_username_fetch_profile_info_fetch_user_post), while others have overly verbose names that deviate from a clear pattern (e.g., build_request_to_find_post_by_link_or_aweme_id). There is no uniform verb_noun structure, making the set chaotic and hard to predict.
Tool Count5/5With 10 tools, the count is well-scoped for a TikTok scraper, covering key areas like user lookup, post retrieval, trending content, and liked posts. Each tool appears to serve a distinct purpose in the domain, making the number appropriate without being excessive or insufficient.
Completeness4/5The tool surface covers core scraping functionalities for TikTok, including user and post lookup, trending data, and liked posts, with minor gaps such as potential missing operations for comment retrieval or direct messaging. Agents can likely work around these gaps, as the set supports essential workflows for data extraction.
Average 2.3/5 across 10 of 10 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description offers zero information about what the tool actually does, whether it's a read or write operation, what permissions might be needed, or any behavioral characteristics. The truncated note about endpoints provides no useful 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is incomplete and truncated, showing only a note about endpoints ending with a quote mark. While technically concise, this represents under-specification rather than effective brevity. The content doesn't form a coherent description, making it impossible to evaluate proper structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for understanding the tool. With no annotations, no output schema, and a tool name suggesting it finds posts by link or aweme_id, the description fails to explain what the tool does, how it behaves, or what it returns. The truncated note provides no meaningful context for a tool that presumably interacts with some API endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'X-Fields', which is documented as 'An optional fields mask'. The description adds no additional parameter information beyond what's already in the schema. With high schema coverage and only one parameter, the baseline score of 3 is appropriate since the schema adequately documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is completely missing - it only contains a truncated note about endpoints ending with a quote mark, which provides no information about what the tool does. There's no verb, resource, or purpose stated, making it impossible to understand the tool's function. This is worse than a tautology as it's essentially empty content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool. The description doesn't mention any context, prerequisites, or alternatives among the sibling tools. The tool name suggests it finds posts by link or aweme_id, but the description offers no help in determining when this is the appropriate choice versus other post-finding tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description is essentially empty, providing no information about whether this is a read/write operation, what permissions are needed, rate limits, error behavior, or any other behavioral traits. This leaves the agent completely in the dark about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (just a truncated note), this is under-specification rather than effective conciseness. The description doesn't communicate the tool's purpose or usage, so it fails at its fundamental job. The structure is broken (truncated text) and doesn't front-load essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a tool with no annotations, no output schema, and sibling tools that suggest complex user/post finding functionality, the description is completely inadequate. It provides no information about what the tool returns, how it differs from similar tools, or what context it operates in. The agent would have to guess based on the tool name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'X-Fields', which is documented as 'An optional fields mask'. The description adds nothing beyond what the schema provides, but with high schema coverage and only one parameter, the baseline is 3. The description doesn't compensate or add value, but doesn't need to given the schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is completely missing - it only contains a truncated note about endpoints ending with a backslash, which doesn't state what the tool does at all. There's no verb+resource description, no indication of functionality, and no differentiation from sibling tools. This is worse than tautology - it's essentially empty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool, what problem it solves, or how it differs from the many sibling tools listed (like find_user_by_sec_user_id_fetch_profile_info_fetch_user_p). No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description offers no information about what the tool does beyond its name—no details about permissions needed, rate limits, response format, or whether it performs read/write operations. This leaves the agent with no understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not concise in a helpful way—it's under-specified rather than efficiently informative. A single sentence that merely repeats the tool name without adding value doesn't earn its place, making this poor structure despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is completely inadequate. It fails to explain what the tool returns, how it behaves, or its purpose relative to siblings. For a tool with no structured support, the description should provide much more context to be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one optional parameter ('X-Fields') clearly documented as 'An optional fields mask'. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology that merely restates the tool name ('build request to find user and his info by sec user id'), providing no additional clarity about what the tool actually does. It doesn't specify what 'build request' means in practice or what 'his info' includes, making the purpose vague and unhelpful for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools available (like 'find_user_by_sec_user_id_fetch_profile_info_fetch_user_p'), there's no indication of how this tool differs or when it should be selected over similar options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The incomplete description fails to reveal any behavioral traits—such as whether this is a read/write operation, authentication needs, rate limits, side effects, or what the sequence of actions entails. It offers no useful context beyond the truncated hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is incomplete and poorly structured—it's a single truncated sentence that fails to convey useful information. While it's brief, this is due to under-specification rather than effective conciseness. It lacks front-loaded clarity and doesn't earn its place as a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (implied sequence of actions), lack of annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, how it behaves, or its purpose relative to siblings. This is inadequate for a tool that likely involves multiple steps and user data retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with one parameter ('X-Fields') fully documented in the schema. The description adds no information about parameters, as it's cut off before mentioning any. With high schema coverage, the baseline is 3, but the description doesn't compensate or add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts to explain the tool's purpose ('finds user by') but is cut off mid-sentence, making it incomplete and vague. It hints at a multi-step process but fails to specify what resource is being retrieved or what the tool actually does. This is a tautology that mostly restates the tool name without adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It doesn't mention alternatives like 'find_user_by_sec_user_id_fetch_profile_info_fetch_user_p' or 'find_user_by_username_fetch_profile_info_fetch_user_post_2', nor does it specify any context, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 hints at a multi-step process ('does a sequence of actions under the hood') but doesn't disclose what those actions are, what data is returned, or any behavioral traits like error handling or performance. This leaves the agent with minimal insight into how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is incomplete and poorly structured, ending abruptly mid-sentence. It fails to convey essential information efficiently. While it's brief, this is due to under-specification rather than effective conciseness, making it unhelpful for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name suggests complexity (finding user by username, fetching profile info, and fetching user posts), the description is severely incomplete. With no annotations, no output schema, and a truncated description, it fails to provide enough context for the agent to understand what the tool does or returns, making it inadequate for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'X-Fields' documented as 'An optional fields mask'. The description adds no information about parameters, as it's cut off before mentioning any. With high schema coverage and no parameter details in the description, 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.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts to explain what the tool does ('finds user by...') but is incomplete and cut off mid-sentence. It mentions a sequence of actions but doesn't specify the full purpose. This is more than a tautology but remains vague and unfinished, failing to clearly state the complete tool purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions. Given the sibling tools include similar user-finding tools (e.g., 'find_user_by_sec_user_id_fetch_profile_info_fetch_user_p'), the lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions fetching actions without disclosing behavioral traits like rate limits, authentication needs, or error handling. It hints at a multi-step process but lacks details on what gets returned or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but incomplete, ending abruptly with 'fetch "'. It front-loads the purpose but wastes space on an unfinished sentence, reducing effectiveness. Structure is minimal but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that performs multiple actions (fetching stats and profile info), the description is incomplete. It doesn't explain return values, error cases, or the scope of 'etc.', leaving significant gaps for an AI agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'X-Fields', so the schema adequately documents it. The description adds no parameter information, but with 0 required parameters and high schema coverage, a baseline of 4 is appropriate as the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fetches user stats and profile info, which indicates a read operation, but it's vague about the specific resource (user) and doesn't clearly distinguish from siblings like 'find_user_by_username_fetch_profile_info_fetch_user_post'. It mentions a sequence of actions but lacks specificity on what 'etc.' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. Sibling tools like 'find_user_by_username_fetch_profile_info_fetch_user_post' suggest similar functionality, but the description doesn't clarify differences or prerequisites, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only search operation but lacks details on behavioral traits such as rate limits, authentication needs, response format, or error handling. The mention of a parameter contradicts the schema (which has zero parameters), adding confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it's poorly structured and confusing due to the parameter contradiction. It front-loads the purpose but wastes words on an inaccurate detail, reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It fails to explain how the country is specified, what data is returned, or any limitations, leaving significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the baseline is 4. The description mentions a 'specific country passed as the parameter', but since there are no parameters, this adds minimal value and could be misleading, though it doesn't significantly detract from the high baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches for trending hashtags for a specific country, which provides a basic purpose. However, it's vague about the scope (e.g., platform, time frame) and doesn't distinguish it from sibling tools like 'get_trending_users_in_specific_country', which serves a similar function but for users instead of hashtags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions a 'specific country passed as the parameter', but with zero parameters in the schema, this is confusing and doesn't help the agent understand context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a privacy dependency but doesn't cover other critical aspects: whether this is a read-only operation, potential rate limits, authentication needs, error handling for privacy restrictions, or response format. The description is insufficient for a tool that likely involves user data access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, reasonably concise sentence that communicates the core purpose upfront. However, it could be slightly more structured by separating the main action from the privacy condition, and it contains a minor grammatical error ('it' instead of 'if').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of searching user-liked posts (which involves privacy considerations and user data), no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It should explain more about what the tool returns, how privacy restrictions manifest, and any other constraints beyond the single mentioned condition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one optional parameter 'X-Fields' documented as 'An optional fields mask'. The description adds no parameter information beyond what the schema provides. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for post user previously liked' specifies the action (search) and resource (liked posts). It distinguishes from siblings by focusing on liked posts rather than general posts or user info. However, it doesn't explicitly contrast with all sibling tools, missing some differentiation nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'only if the target user allowed this feature in privacy settings' indicates a prerequisite condition. However, it lacks explicit guidance on when to use this tool versus alternatives like 'find_users_posts_by_sec_user_id' or other user/post search tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 mentions that mixing link types causes incorrect endpoint behavior, which is a useful behavioral warning. However, it lacks details on permissions, rate limits, error handling, or what 'post data' specifically includes (beyond 'cover links, metrics, download links, etc.'), leaving significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose. Both sentences earn their place: the first defines the tool's function and inputs, and the second provides a critical warning. There's no unnecessary fluff, making it efficient, though it could be slightly more structured (e.g., bullet points for identifiers).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It covers the purpose and input identifiers but lacks details on behavioral traits (e.g., auth needs, rate limits), output format, or error handling. For a tool that fetches post data with implied complexity, this leaves the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage ('X-Fields: An optional fields mask'), so the schema does the heavy lifting. The description adds value by explaining the post identifiers (aweme_id, share_link, web_link, short_link) and warning about mixing types, but these aren't parameters in the schema—they're implied inputs. Since schema coverage is high, the baseline is 3, and the description provides some additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find post data (cover links, metrics, download links, etc.) by post identifier.' It specifies the verb ('find') and resource ('post data'), and lists the types of identifiers accepted. However, it doesn't explicitly differentiate from sibling tools like 'find_liked_posts_by_sec_user_id' or 'find_user_by_username_fetch_profile_info_fetch_user_post', which focus on different resources (liked posts, user info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Takes any of the following post identifiers' and warns 'If you mix up link type endpoint will work incorrectly!', which provides some guidance on correct input. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., vs. sibling tools for user data) or mention any prerequisites or exclusions, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 mentions fetching data but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what 'trending' means (e.g., based on time frame or metrics). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resource. It avoids unnecessary words and gets straight to the point. However, it could be slightly improved by clarifying the parameter discrepancy or adding a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching trending users with posts), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'trending' entails, the format of returned data (e.g., user details, post content), or any limitations. While it states the purpose, more context is needed for an AI agent to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so there's no parameter information to add. The description mentions 'target country passed as parameter', which might confuse an agent since the schema indicates no parameters. However, this could imply the country is inferred from context or hardcoded, but it doesn't clarify. Given the baseline of 4 for 0 parameters, the score is 4, but the ambiguity slightly detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('trending users and their most popular post'), with the specific scope 'for target country passed as parameter'. It distinguishes from sibling tools like 'get_trending_hashtags_for_specific_country' by focusing on users rather than hashtags. However, it doesn't explicitly differentiate from other user-related tools (e.g., 'find_user_by_username'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it implies usage when you want trending users in a specific country. It doesn't specify when to use this tool versus alternatives like 'find_user_by_username' or 'get_trending_hashtags_for_specific_country', nor does it mention prerequisites or exclusions. This lack of explicit comparison reduces its helpfulness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bachai-tiktok-unauthorized-api-scraper-no-watermark-analytics-feed'
If you have feedback or need assistance with the MCP directory API, please join our Discord server