Douyin API New MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation1/5
The tool set is highly ambiguous with numerous duplicate names (e.g., aweme repeated 6 times, detail repeated 8 times, list repeated 4 times) and vague single-word names (e.g., ab, index, item, social) that provide no clear distinction. An agent would struggle to differentiate between tools, leading to frequent misselection due to overlapping or indistinguishable purposes.
Naming Consistency2/5
Naming conventions are inconsistent, mixing camelCase (e.g., appointLiveList, brandBillboard) with snake_case (e.g., search_videolist is implied but not consistent) and single words (e.g., live, music). There is no predictable pattern across the set, with some tools using verbs (e.g., discover, follow) and others using nouns (e.g., channel, city), creating confusion.
Tool Count1/5
With 79 tools, the count is excessive for a typical MCP server, indicating poor scoping and likely redundancy. This overwhelms the surface area, making it difficult for agents to navigate and increasing the risk of tool misuse. Such a high number suggests fragmentation rather than a cohesive API coverage.
Completeness3/5
Inferring the domain as Douyin (TikTok) API, the tools cover various aspects like videos (aweme, detail), social features (follow, reply), search (searchlist, suggestwords), and content discovery (hotlist, recommend). However, the redundancy and vague naming make it hard to assess true coverage, but core areas seem represented albeit with potential gaps in specific operations like update or delete actions.
Average 1.6/5 across 79 of 79 tools scored.
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.json to 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 single word 'index' reveals nothing about whether this is a read/write operation, what resources it affects, potential side effects, or response format. This is completely inadequate for a tool with unknown 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective brevity. The description fails to convey any useful information, making it inefficient rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and a tool named 'index' among many similar-sounding siblings, the single-word description provides insufficient information for an agent to understand or use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter documented in the schema, so the baseline score is 3. The description adds no additional parameter information beyond what's already in the structured schema, which provides the parameter name, type, default value, and an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 many sibling tools present (including 'index_1' and 'index_2'), there's no indication of context, prerequisites, or differentiation, leaving the agent with no usage direction.
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, and the description adds no behavioral information. It does not disclose whether this is a read or write operation, what it returns, error conditions, rate limits, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient for an AI agent to understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with 3 parameters and no annotations or output schema. It provides no context on functionality, behavior, or usage, leaving critical gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters (id, offset, limit) are documented in the schema. The description adds no meaning beyond the schema, but the baseline is 3 since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'index' is a tautology that merely restates the tool name without specifying what it does. It provides no verb, resource, or purpose, failing to distinguish it from sibling tools like 'index' or 'index_1'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. With many sibling tools (e.g., 'list', 'searchlist', 'detail'), the description offers no 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. However, 'longVideoMeta' reveals nothing about what the tool does operationally—whether it reads, writes, modifies, or analyzes data; what permissions or rate limits apply; or what side effects might occur. This leaves the agent completely in the dark about 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is technically concise with a single word, it is severely under-specified rather than efficiently informative. Conciseness should not come at the expense of clarity; this description fails to convey any useful information, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema), the description is completely inadequate. It does not explain what the tool does, how to use it, what it returns, or how it differs from siblings. Without annotations or output schema, the description must compensate but fails to provide any contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters documented in the schema itself (episode_id_current, album_id, aweme_id_current). The description adds no additional meaning about these parameters, their relationships, or usage examples. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of appropriate contexts, prerequisites, or comparisons with sibling tools like 'detail', 'aweme', or 'video' variants. Without any usage instructions, an agent cannot determine when this tool is the correct choice.
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 single word 'nearby' reveals nothing about whether this is a read or write operation, what it returns, its side effects, rate limits, or authentication needs. This is completely inadequate for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (one word), it is under-specified rather than efficiently informative. Conciseness should not come at the cost of clarity; this description fails to communicate essential information, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 severely incomplete. It does not explain the tool's purpose, behavior, or output, leaving the agent with insufficient information to use it correctly. This is inadequate for a tool with parameters and many potential sibling alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('max_cursor' and 'city') documented in the schema. The description adds no additional meaning about these parameters, such as what 'city' represents (e.g., a city ID) or how 'max_cursor' affects results. However, with full schema coverage, 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.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools that might relate to location-based queries (e.g., 'city', 'poi', 'searchlist'), there is no context provided about appropriate use cases, prerequisites, or exclusions.
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 'poi' gives no information about the tool's behavior, such as whether it's read-only or destructive, its rate limits, authentication needs, or output format. It fails to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, the description is under-specified rather than efficiently informative. It lacks any structure or front-loaded information, failing to convey purpose or usage in a meaningful way, which is not true conciseness but insufficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 3-parameter tool with no annotations and no output schema, the description 'poi' is completely inadequate. It provides no context on what the tool does, how to use it, or what to expect, leaving significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (id, cursor, count) documented in the schema. The description adds no additional meaning or context about these parameters, so it meets the baseline score of 3 where the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'poi' is a tautology that merely repeats the tool name without any meaningful explanation of what the tool does. It provides no verb, resource, or purpose statement, making it impossible to understand the tool's function or distinguish it from sibling tools like 'poi' (without suffix).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparisons with sibling tools, leaving the agent with no usage direction.
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 must fully disclose behavioral traits, but it gives no information about the tool's behavior—whether it's a read-only query, if it requires authentication, its rate limits, error conditions, or what it returns. The description is entirely silent on these critical aspects, leaving the agent with no understanding of how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise with just one word, this is due to under-specification rather than effective brevity. It lacks any structure or front-loading of key information, failing to convey purpose or usage in a meaningful way. Every sentence should earn its place, but here the single 'sentence' provides no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a query with one parameter) and the absence of annotations and output schema, the description is completely inadequate. It does not explain what the tool does, when to use it, behavioral traits, or return values, leaving the agent unable to understand or correctly invoke the tool in context with its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter 'sec_user_id', providing an example value. The description adds no additional meaning about parameters, such as explaining what 'sec_user_id' represents or its relationship to querying account types. Since schema coverage is high, the baseline score of 3 applies, as the schema adequately documents the parameter without help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, such as its intended context, prerequisites, or alternatives. With no usage instructions, an agent cannot determine if this is the appropriate tool for a given scenario compared to the many sibling tools listed, like 'profile', 'info', or 'detail'.
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 must fully disclose behavioral traits. 'searchList' gives no information about whether this is a read-only operation, if it has side effects, rate limits, authentication requirements, or what the output looks like. This leaves critical behavioral aspects completely undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise with just one word, it is under-specified rather than efficiently informative. It fails to convey essential details, making it ineffective despite its brevity. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a vague purpose, the description is completely inadequate. It does not explain what the tool does, when to use it, what behavior to expect, or how to interpret results. This leaves the agent unable to effectively select or invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'detail_list' documented in the schema as a number with default value 1. The description adds no additional meaning about this parameter, such as what it controls or its impact on results. Given the high schema coverage, 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.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools like 'searchvideolist', 'hotlist', and 'list', there is no indication of what makes 'searchlist' unique or appropriate for specific contexts. Users are left with no usage instructions.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure but fails entirely. It doesn't indicate whether this is a read or write operation, what permissions might be needed, what side effects occur, or any rate limits. The description provides zero 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective brevity. The description fails to convey any useful information, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a completely inadequate description, this is severely incomplete. The description provides no context about what the tool does, how it behaves, or what results to expect, making it impossible for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with one parameter documented, so the baseline score is 3. The description adds no additional parameter information beyond what's already in the schema, but doesn't need to compensate for gaps since coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what context it applies to, or how it differs from alternatives like 'seoinnerlink' or 'suggestwords' among the many sibling tools. There is complete absence of usage instructions or prerequisites.
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 responsibility for behavioral disclosure. The single word 'sug' reveals nothing about whether this is a read/write operation, what permissions are required, what side effects might occur, or how results are returned. This leaves the agent completely in the dark about 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, this is not effective conciseness but rather severe under-specification. A single word description fails to communicate essential information that would help an agent use the tool correctly. The description doesn't earn its place through meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a single parameter, the description 'sug' is completely inadequate. It provides no context about what the tool does, how to use it, or what to expect from it. The agent would be operating blindly with only the parameter schema as guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'keyword' documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'sug' is a tautology that merely restates the tool name without any meaningful explanation of what the tool does. It provides no verb, resource, or purpose statement, making it impossible to understand the tool's function or distinguish it from sibling tools like 'suggestwords' or 'seokeywordrelated'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, when not to use it, or what alternatives exist. With no contextual information provided, an AI agent cannot determine appropriate usage scenarios or differentiate this tool from similar-sounding siblings in the 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 the full burden of behavioral disclosure. 'suggestWords' gives no indication of whether this is a read or write operation, what permissions might be required, whether it has side effects, rate limits, or any other behavioral characteristics. The description fails completely to inform the agent about how this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this is an example of harmful under-specification rather than effective conciseness. The single word 'suggestWords' doesn't provide enough information to be useful, making this inefficient communication rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is completely inadequate. It provides no information about what the tool does, when to use it, what behavior to expect, or what results it returns. The agent would be operating blindly with this level of documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with example values. The description adds zero additional information about parameter semantics, purpose, or relationships. However, with complete schema coverage, the baseline score is 3 even when the description provides no parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With 83 sibling tools on the server including similar-sounding tools like 'sug', 'sug_1', and 'susggestwords', the agent has no information about when this specific tool is appropriate versus those other 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, and the description 'ab' offers zero behavioral information. It doesn't indicate whether this is a read or write operation, what permissions might be required, what side effects exist, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, this is under-specification rather than appropriate conciseness. A two-character description for a tool with 75+ siblings fails to provide the minimal information needed for an agent to understand when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the complexity implied by having 75+ sibling tools and no output schema. It provides no meaningful information about what the tool does, when to use it, or what behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the parameter situation. The description doesn't need to compensate for any parameter documentation gaps, though it also adds no value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool, what context it applies to, or how it differs from alternatives. With 75+ sibling tools, this lack of guidance is particularly problematic.
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, it reveals nothing about the tool's behavior—whether it's read-only or mutative, what it returns, rate limits, or side effects. This leaves the agent with no operational understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, this is under-specification rather than effective brevity. The description fails to convey essential information, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 severely incomplete. It provides no insight into the tool's function, behavior, or output, leaving the agent unable to use it effectively in any context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of inputs, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what context it applies to, or how it differs from alternatives. With no usage instructions, an AI agent cannot determine appropriate scenarios for invocation.
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 responsibility for behavioral disclosure. It fails to describe any behavioral traits such as whether it's a read or write operation, authentication needs, rate limits, or side effects. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise with just one word, this brevity results in under-specification rather than effective communication. It fails to convey any meaningful information, making it inefficient for the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools and the lack of annotations or output schema, the description is completely inadequate. It provides no information on functionality, behavior, or use cases, failing to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so there is no need for parameter documentation in the description. The baseline for this scenario is 4, as the absence of parameters is adequately covered by the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are no guidelines on when to use this tool versus alternatives. The description offers no context, prerequisites, or comparisons to sibling tools, leaving the agent with no basis for selection among the many available 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 must fully disclose behavioral traits. The single-word description 'aweme' reveals nothing about the tool's behavior, such as whether it performs read/write operations, requires authentication, has side effects, or handles errors. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, this is an example of under-specification rather than effective brevity. The description fails to convey any meaningful information, making it inefficient and poorly structured for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools and the lack of annotations or output schema, the description is completely inadequate. It provides no context on functionality, behavior, or output, failing to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the absence of parameters, warranting a baseline score of 4 as it doesn't detract from understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'aweme' is a tautology that merely repeats the tool name without stating what the tool does. It provides no verb, resource, or purpose, making it impossible to understand the tool's function or distinguish it from sibling tools like 'aweme', 'aweme_2', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With multiple sibling tools (e.g., 'aweme', 'aweme_2' through 'aweme_5'), there is no indication of context, prerequisites, or differentiation, leaving usage entirely ambiguous.
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 single-word description 'aweme' reveals nothing about whether this is a read or write operation, what permissions might be required, rate limits, side effects, or expected behavior. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to convey any useful information and doesn't follow the principle that every sentence should earn its place—here, the single word doesn't earn its place at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name suggests it's part of a family of similar tools (aweme_1 through aweme_5) and the complete absence of annotations and output schema, the description is woefully incomplete. It provides no context about what differentiates this tool from its siblings or what operation it performs, making it impossible for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. A baseline score of 4 is appropriate since there are no parameters requiring semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'aweme' is a tautology that merely repeats the tool name without explaining what the tool does. It provides no verb or resource specification, and fails to distinguish this tool from its many siblings (aweme, aweme_1, aweme_3, etc.). This leaves the agent completely guessing about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With multiple aweme-related tools in the sibling list (aweme, aweme_1 through aweme_5), the absence of any context or differentiation makes it impossible for an agent to determine appropriate usage scenarios.
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, it adds nothing about what the tool does, its effects (e.g., read vs. write), permissions, rate limits, or any other behavioral traits. This leaves the agent completely in the dark about the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (just one word), it is under-specified rather than efficiently informative. It fails to convey any useful information, making it ineffective despite its brevity. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a description that provides zero context, this tool definition is completely inadequate. The agent cannot understand the tool's purpose, behavior, or usage, making it impossible to invoke correctly in any meaningful scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so there are no parameters to document. The description does not need to compensate for any gaps, and it appropriately avoids discussing parameters. A baseline of 4 is assigned since no parameter information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'aweme' is a tautology that merely repeats the tool name without adding any meaningful context. It provides no verb, resource, or action specification, making it impossible to understand what this tool does or how it differs from its siblings (aweme, aweme_1, aweme_2, aweme_4, aweme_5).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus its sibling tools. There is no mention of context, prerequisites, alternatives, or any usage scenarios, leaving the agent with no information to make an informed selection among similar-sounding tools.
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 single-word description 'aweme' reveals nothing about the tool's behavior - whether it's a read or write operation, what permissions are needed, what side effects occur, or what the response contains. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective brevity. The description fails to communicate any meaningful information, so its conciseness is detrimental rather than helpful. Every description should earn its place, and this one doesn't.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and a tool name that suggests it's part of a family of similar tools (aweme_1 through aweme_5), the single-word description provides no information about what this specific tool does, how it differs from siblings, or what behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't need to compensate for any parameter gaps, and the empty schema is fully self-documenting in this case. A baseline of 4 is appropriate since no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'aweme' is a tautology that merely restates the tool name without any explanation of what the tool does. It provides no verb, resource, or functional context, making it impossible to understand the tool's purpose or distinguish it from sibling tools like 'aweme', 'aweme_1', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios or how this tool relates to other tools in the 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 must fully disclose behavioral traits. The single word 'aweme' reveals nothing about whether it's a read/write operation, authentication needs, rate limits, side effects, or output format. It fails to provide any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with one word, it is under-specified rather than efficiently informative. The description lacks essential content, making it ineffective despite its brevity—it doesn't earn its place by conveying useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 vague description, the tool's complexity is unclear, but the description is completely inadequate. It fails to provide any meaningful context about functionality, behavior, or usage, leaving the agent with insufficient information to operate the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'aweme' is a tautology that merely repeats the tool name without explaining what the tool does. It provides no verb, resource, or functional context, making it impossible to understand the tool's purpose or distinguish it from sibling tools like 'aweme', 'aweme_1', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With multiple similar-named tools (e.g., 'aweme', 'aweme_1' through 'aweme_5'), there is no indication of context, prerequisites, or differentiation, leaving usage entirely ambiguous.
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 must fully disclose behavioral traits. However, it gives no information about whether this tool performs read or write operations, its side effects, authentication needs, rate limits, or expected outputs. The single-word description fails to provide any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise with just one word, it is under-specified rather than efficiently informative. Conciseness should not come at the cost of clarity; this description fails to communicate essential information, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 provides no insight into the tool's functionality, behavior, or output, leaving the agent unable to understand or use it effectively. The context signals do not compensate for this deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description does not add parameter semantics, but this is acceptable since there are no parameters to explain. A baseline score of 4 is appropriate as the schema fully covers the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With sibling tools like 'aweme', 'brandbillboard', 'hotlist', and 'chart' that might serve related functions, there is no indication of context, prerequisites, or differentiation. This leaves the agent with no usage information.
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 responsibility for behavioral disclosure. 'brandBillboard' reveals nothing about whether this is a read or write operation, what data it accesses, what permissions are needed, rate limits, or expected behavior. This complete lack of transparency warrants a score of 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this is under-specification rather than effective brevity. The description fails to convey any useful information and doesn't follow a structured format. It earns a low score because conciseness should not come at the cost of complete information omission.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's unknown complexity (no output schema, no annotations, no parameters), the description is completely inadequate. It provides no information about what the tool does, when to use it, or what it returns. For any non-trivial tool, this level of incompleteness is unacceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, meaning the schema fully documents the absence of parameters. The description doesn't need to compensate for any parameter gaps. While it adds no parameter information beyond the schema, the baseline for zero parameters with complete schema coverage is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers absolutely no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparison to sibling tools like 'billboardaweme' or 'brandweeklylist'. Without any usage information, this score must be 1.
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 responsibility for behavioral disclosure. The description 'brandCategory' reveals nothing about the tool's behavior - whether it's a read or write operation, what permissions are needed, what side effects exist, or what the response format might be. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (just one word), this represents under-specification rather than effective conciseness. The single word 'brandCategory' fails to communicate essential information about the tool's purpose or usage, making it inefficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and 75+ sibling tools, the description provides no information about what this tool does, when to use it, what it returns, or how it differs from similar tools. This leaves the agent unable to make informed decisions about tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so there are no parameters to document. The baseline for zero parameters is 4, as there's no parameter information that needs to be explained beyond what the schema already provides (which is that there are no parameters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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, when not to use it, or what alternatives exist among the many sibling tools. Without any context or usage instructions, the agent has no basis for selecting this tool appropriately.
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, it fails to describe any behavioral traits such as whether it's a read or write operation, what data it returns, potential side effects, rate limits, or authentication requirements. The single-word description provides zero 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (one word), it is under-specified rather than efficiently informative. Conciseness should not come at the cost of clarity; this description fails to convey purpose or usage, making it ineffective despite its brevity. It does not front-load critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools (e.g., data retrieval or listing operations) and the absence of both annotations and an output schema, the description is completely inadequate. It provides no information about what the tool does, what it returns, or how to use it, leaving the agent unable to understand or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, meaning the schema fully documents the absence of inputs. The description does not add parameter information, but since there are no parameters to explain, this is acceptable. A baseline score of 4 reflects that the description doesn't need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it reference sibling tools for comparison. This leaves the agent with no information to make an informed selection among the many similar-sounding tools on the server.
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 single-word description 'challenge' reveals nothing about whether this is a read/write operation, what it affects, authentication needs, rate limits, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this is an example of harmful under-specification rather than effective brevity. The description fails to provide any useful information that would help an agent understand or use the tool. Every sentence (or word) should earn its place, and this single word doesn't earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description should at minimum explain what the tool does and what it returns. The single-word description 'challenge' provides neither functional explanation nor return value information. This is completely inadequate for even the simplest tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. While the description doesn't add parameter semantics (since there are none), the baseline for this situation is 4 as the schema fully covers the non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 0 parameters and no context about its function, there is no indication of appropriate use cases, prerequisites, or exclusions. The agent would have no basis for selecting this tool over others.
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, placing full burden on the description to disclose behavioral traits. The single-word description 'channel' reveals nothing about whether this is a read or write operation, authentication requirements, rate limits, side effects, or expected output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to communicate essential information that would help an AI agent understand and invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's unknown complexity, lack of annotations, and absence of an output schema, the description is completely inadequate. A single-word description provides insufficient information for an AI agent to determine when and how to use this tool among dozens of alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline score is 4. The description doesn't need to compensate for missing parameter documentation since there are no parameters to document, though it also adds no value beyond what the empty schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 80+ sibling tools including various detail, list, and search functions, there is no indication of context, prerequisites, or exclusions for this tool's application.
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 single word 'chart' reveals nothing about whether this is a read/write operation, authentication requirements, rate limits, side effects, or expected behavior. This is completely inadequate for a tool with unknown functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to convey any meaningful information about the tool's purpose or usage, making it functionally useless despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero functional information, this is completely inadequate. The tool's purpose, behavior, and usage remain entirely mysterious despite having 78 sibling tools that could provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. A baseline of 4 is assigned since no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers absolutely no guidance on when to use this tool versus alternatives. With 78 sibling tools and no context provided, there is no indication of appropriate use cases, prerequisites, or differentiation from other tools.
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 single word 'city' reveals nothing about whether this tool performs read or write operations, what permissions it requires, what side effects it might have, or what kind of response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective brevity. The description fails to convey any useful information, making it inefficient rather than appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero meaningful information, this is completely inadequate. The tool's purpose, behavior, and usage context remain entirely opaque despite the simple parameter structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps, though it also adds no value beyond what the schema provides. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers absolutely no guidance on when to use this tool versus alternatives. With 84 sibling tools on the server, this lack of context makes it impossible for an agent to determine appropriate usage scenarios or distinguish this tool from others.
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 must fully disclose behavioral traits. The single word 'detail' gives no insight into whether this is a read or write operation, what resources it accesses, potential side effects, rate limits, or authentication needs. It fails to convey any behavioral characteristics beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (one word), it is under-specified rather than efficiently informative. Conciseness should not come at the cost of clarity; here, the brevity results in a lack of useful content. It fails to front-load essential information, making it ineffective despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by many sibling tools and the lack of annotations and output schema, the description is completely inadequate. It provides no context about functionality, behavior, or use cases, leaving the agent unable to understand or invoke the tool effectively. This is insufficient for any meaningful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, meaning no parameters need documentation. The description does not add parameter semantics, but this is acceptable given the absence of parameters. A baseline score of 4 reflects that the description need not compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With numerous sibling tools present (e.g., detail variants, list tools, search tools), there is no indication of context, prerequisites, or distinctions. This leaves the agent with no actionable information for tool selection.
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 must fully disclose behavioral traits. 'detail' gives no information about whether this is a read or write operation, what resources it affects, authentication needs, rate limits, or side effects. It fails to meet the burden of behavioral transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'detail' is extremely brief, this is under-specification rather than effective conciseness. A single word fails to convey necessary information, making it inefficient for the agent's understanding. It does not front-load key details or structure content helpfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and a vague description, the tool is severely incomplete. The description does not compensate for missing structured data, leaving the agent unable to understand the tool's purpose, behavior, or usage in a context with many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, meaning the schema fully documents the absence of inputs. The description adds no parameter information, but with no parameters, a baseline score of 4 is appropriate as there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name without specifying what it does. It provides no verb, resource, or scope, and fails to distinguish it from sibling tools like 'detail_2' through 'detail_7' or 'detailid' and 'detailurl'. This offers no meaningful guidance on the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 many similar-sounding sibling tools (e.g., 'detail_2' to 'detail_7'), there is no indication of context, prerequisites, or differentiation, leaving the agent with no usage direction.
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 single word 'detail' reveals nothing about whether this is a read or write operation, what permissions might be required, rate limits, side effects, or any other behavioral characteristics. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'detail' is certainly concise, this represents under-specification rather than effective conciseness. The single word fails to convey necessary information about the tool's purpose or usage. True conciseness requires conveying essential information efficiently, not omitting it entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and many similar sibling tools, the single word 'detail' fails to provide the minimal information needed for an agent to understand what this tool does or when to use it. This is especially problematic given the crowded namespace of detail-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). With no parameters to document, the description doesn't need to provide parameter semantics. The baseline for zero parameters is 4, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name 'detail_2', providing no meaningful information about what the tool actually does. It doesn't specify any verb or resource, nor does it differentiate from sibling tools like 'detail', 'detail_1', 'detail_3', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With many similar-sounding sibling tools (detail, detail_1, detail_3, etc.), the lack of any context or differentiation makes it impossible for an agent to determine appropriate usage scenarios.
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 must fully disclose behavioral traits. The single word 'detail' gives no information about whether this is a read or write operation, what data it accesses, potential side effects, rate limits, or authentication needs. It fails to convey any behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, this is under-specification rather than effective brevity. The description lacks necessary structure and fails to front-load essential information, making it inefficient for an agent to understand the tool's role without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools (e.g., multiple 'detail' variants) and the absence of annotations and output schema, the description is completely inadequate. It provides no information about what the tool does, how it behaves, or what it returns, failing to meet minimal contextual needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description does not need to compensate for any parameter documentation gaps. A baseline score of 4 is appropriate since there are no parameters to explain, and the description does not introduce confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name 'detail_3' without specifying what resource it details or what action it performs. It provides no verb or object to clarify the tool's function, making it impossible to understand its purpose or distinguish it from sibling tools like 'detail', 'detail_1', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. With multiple similar tools (e.g., 'detail', 'detail_1', 'detail_2'), the description offers no context, prerequisites, or distinctions to inform selection, leaving usage entirely ambiguous.
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 single word 'detail' reveals nothing about whether this is a read/write operation, what permissions are needed, what data it returns, or any side effects. This provides zero behavioral transparency for a tool with unknown functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents under-specification rather than effective conciseness. The description fails to provide necessary information about the tool's purpose or behavior. In the context of tool documentation, this level of brevity is inadequate rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides only the tool name repeated, this description is completely inadequate. Even with zero parameters, the tool's purpose, behavior, and differentiation from similar tools remain completely undocumented, making it impossible for an agent to understand when or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (parameter count: 0) with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. While it doesn't add any parameter information, the baseline for zero parameters is appropriately set at 4 since no parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name without specifying what resource it details or what action it performs. It provides no verb+resource combination and doesn't distinguish from sibling tools like 'detail', 'detail_1', 'detail_2', etc. This fails to communicate any meaningful 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With multiple similar tools in the sibling list (detail, detail_1, detail_2, detail_3, detail_5, etc.), there's no indication of what differentiates this specific tool or when it should be selected over others. This leaves the agent with no usage context.
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 must fully disclose behavioral traits. 'detail' gives no information about whether this is a read or write operation, what permissions are needed, rate limits, or any other behavioral characteristics. It fails to provide any context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'detail' is extremely concise, it is under-specified rather than appropriately sized. A single word fails to convey necessary information, making it inefficient in communicating the tool's function—it's brevity without substance, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by many sibling tools and the lack of annotations or output schema, the description is completely inadequate. It provides no context about what the tool does, how it behaves, or what it returns, failing to compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name without specifying what resource it details or what action it performs. It provides no meaningful information about the tool's purpose, making it impossible to distinguish from sibling tools like 'detail', 'detail_1', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools having similar names (e.g., 'detail', 'detail_1'), there is no indication of context, prerequisites, or differentiation, leaving usage entirely ambiguous.
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 must fully disclose behavioral traits. The single word 'detail' reveals nothing about whether this is a read/write operation, its side effects, authentication needs, rate limits, or output format. It fails to provide any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'detail' is extremely brief, this is under-specification rather than effective conciseness. The single word fails to convey necessary information, making it inefficient rather than well-structured. It doesn't front-load key details because it provides none.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and multiple sibling tools with similar names, the description should explain the tool's role, behavior, and differentiation. 'detail' alone provides none of this, leaving the agent unable to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain parameters, but it also doesn't add any semantic context. Given the absence of parameters, a baseline of 4 is appropriate as there's no parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name without specifying what action it performs or what resource it operates on. It provides no meaningful information about the tool's function, making it impossible to understand its purpose or distinguish it from sibling tools like 'detail', 'detail_1', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With multiple similar tools (e.g., 'detail', 'detail_1', 'detail_2'), there is no indication of context, prerequisites, or differentiation, leaving the agent with no basis for selection.
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 must fully disclose behavioral traits, but 'detail' gives no information about what the tool does, its effects, permissions, rate limits, or output. This leaves the agent with no understanding of the tool's behavior beyond its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'detail' is extremely concise, it is under-specified rather than efficiently structured. The single word fails to convey any meaningful information, making it ineffective as a description despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and a vague description, this tool is completely inadequate for an AI agent. The description does not compensate for the missing context, leaving the tool's functionality and use cases entirely unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add any param details, but since there are no parameters, this is acceptable, and the baseline score is 4 as per the rules for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detail' is a tautology that merely restates the tool name, providing no specific verb or resource to clarify what the tool does. It fails to distinguish this tool from its many siblings (e.g., detail, detail_1, detail_2, etc.), leaving 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/5
Does 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, such as other 'detail' siblings or related tools like 'info' or 'item'. The description offers no context, exclusions, or implied usage scenarios, making it impossible for an agent to make an informed selection.
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. 'detailId' reveals nothing about whether this is a read or write operation, what permissions are required, what side effects might occur, or what the tool actually does behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective conciseness. The description fails to communicate any meaningful information despite the minimal word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is completely inadequate. It provides no information about what the tool does, what it returns, or how it differs from sibling tools, leaving the agent with no useful guidance for tool selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so there are no parameters needing documentation. The description doesn't need to compensate for any parameter gaps, though it also adds no value regarding parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With many sibling tools present (including multiple 'detail' variants), there's no indication of context, prerequisites, or differentiation from related tools.
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. 'detailUrl' gives no information about whether this is a read or write operation, what it returns, any side effects, rate limits, or authentication needs. It fails to describe any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, 'detailUrl' is under-specified rather than efficiently informative. It lacks any structure or front-loaded information, failing to convey purpose or usage in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 does not explain what the tool does, how it behaves, or what it returns, leaving the agent with insufficient information to use the tool effectively in a complex sibling tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the absence of parameters, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 'detail', 'detailid', or 'detailurl_1' among the many sibling tools. The description offers no 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.
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 but offers zero behavioral disclosure. It doesn't indicate if this is a read/write operation, what it returns, error conditions, or any system constraints. The single-word description fails to add any meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with one word, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient despite its short length—it doesn't earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and many similar sibling tools, a single-word description provides insufficient information for an agent to understand or use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, the baseline is appropriately high as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'detailUrl' is a tautology that merely restates the tool name without any verb or action. It provides no information about what the tool does, what resource it operates on, or how it differs from sibling tools like 'detail' or 'detailurl'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. With many sibling tools (e.g., 'detail', 'detailurl', 'detail_1' through 'detail_7'), the description offers no context, prerequisites, or distinctions to inform selection.
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 single word 'discover' gives no indication of whether this is a read or write operation, what resources it accesses, what permissions might be required, or any behavioral characteristics. This provides zero transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an agent understand or use the tool. Every sentence should earn its place, but this has no sentences at all - just a single unhelpful word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and 78 sibling tools, the description 'discover' is completely inadequate. It provides no information about what the tool discovers, how it works, what it returns, or why an agent would choose it over other tools. This fails to provide even basic contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. While the description doesn't discuss parameters (because there are none), this is appropriate for a zero-parameter tool, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With 78 sibling tools on the server, the lack of any contextual information about appropriate use cases leaves the agent completely without direction for selecting this specific tool among many 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 single-word description 'emojiList' reveals nothing about the tool's behavior - whether it's a read or write operation, what permissions it requires, whether it has side effects, rate limits, or any other behavioral characteristics. This represents a complete failure to inform the agent 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an agent understand or use the tool. A single word cannot be considered 'appropriately sized' for a tool that presumably has some function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero functional information, this description is completely inadequate. The agent cannot determine what the tool does, when to use it, how it behaves, or what it returns. This represents a severe failure of contextual completeness for any non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). With no parameters to document, the description doesn't need to compensate for any schema gaps. The baseline for zero parameters is 4, as there's no parameter information that could be missing or incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With 80+ sibling tools on the server, the agent receives no context about appropriate use cases, prerequisites, or distinctions from similar tools. This leaves the agent completely without direction for tool selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation, what permissions might be required, what side effects occur, or what the expected behavior is. The single word provides zero 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an agent understand or use the tool, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no annotations and no output schema. It provides no information about what the tool does, what it returns, or how it behaves. Given the complexity implied by the many sibling tools and the complete lack of structured metadata, this description fails to provide any meaningful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter information, but this is appropriate given the parameterless nature of the tool. A baseline of 4 is warranted since no parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios or relationships to other tools in the server.
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 single word 'follow' gives no information about whether this is a read or write operation, what permissions might be required, whether it has side effects, rate limits, or what the expected outcome is. For a tool with zero annotation coverage, this description is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an AI agent understand or use the tool. Every word should earn its place, but here the single word doesn't earn its place by providing useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools in what appears to be a social media/content platform context, and with no annotations and no output schema, the description is completely inadequate. A tool named 'follow' in this ecosystem likely has significant behavioral implications that need explanation, but the description provides none of the necessary context about what the tool does or returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage is 100%), so there are no parameters requiring semantic explanation in the description. The baseline for zero parameters is 4, as the description doesn't need to compensate for undocumented parameters. However, it doesn't get a perfect 5 because it could theoretically mention that no parameters are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With sibling tools like 'follower' and 'following' that seem related to social connections, there's no indication whether 'follow' is for initiating follows, checking follow status, or managing follows. No context, prerequisites, or exclusions 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 full responsibility for behavioral disclosure. The single-word description 'follower' reveals nothing about whether this tool performs read/write operations, requires authentication, has side effects, or any other behavioral traits. This is a complete failure to inform the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (one word), this is a case of under-specification rather than effective brevity. The single word 'follower' fails to convey necessary information, making it inefficient and unhelpful despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a completely inadequate description, this tool definition is severely incomplete. The agent cannot determine what the tool does, when to use it, or what behavior to expect, making it essentially unusable in any meaningful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation for a parameterless tool. However, it doesn't compensate for any gaps since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With numerous sibling tools present (e.g., 'follow', 'following', 'social'), there is no indication of how 'follower' differs from these related tools, leaving the agent with no usage context.
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, it offers no information about the tool's behavior, such as whether it performs read/write operations, requires authentication, has side effects, or handles errors. This is inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise with a single word, this brevity results in under-specification rather than effective communication. It fails to convey necessary information, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and a vague purpose, it provides insufficient information for an agent to understand or use the tool effectively, especially compared to the many sibling tools listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description does not add any parameter information, which is acceptable given the absence of parameters, aligning with the baseline score for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, exclusions, or references to sibling tools, leaving the agent with no basis for decision-making.
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. 'getPcBanner' implies a read operation but provides no information about what data is retrieved, format of response, error conditions, rate limits, authentication requirements, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents under-specification rather than effective brevity. The description fails to communicate essential information, making it inefficient for its intended purpose of helping an AI agent understand and use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no output schema and no annotations. It provides no information about what the tool returns, what it does, or how to use it effectively. Given the lack of structured information elsewhere, the description fails to provide necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage. The description doesn't need to explain parameters since none exist. This meets the baseline expectation for parameterless tools, though it doesn't add value beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what context it applies to, or how it differs from alternatives. With no usage context provided, an AI agent cannot determine appropriate scenarios for invoking this tool.
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 responsibility for behavioral disclosure. 'hotList' reveals nothing about whether this is a read or write operation, what data it returns, whether it requires authentication, has rate limits, or any other behavioral characteristics. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this is under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an agent understand or use the tool. Every word should earn its place, but this single word doesn't earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero operational context, this is completely inadequate. The agent cannot determine what this tool does, when to use it, what it returns, or how it behaves. The description fails to provide the minimal information needed for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the schema already fully documents the input requirements (none). The description doesn't need to compensate for any parameter gaps, so it meets the baseline expectation for a parameterless tool. However, it doesn't add any value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 70+ sibling tools including 'hotvideolist', 'list', 'recommend', and others that might serve similar purposes, there is zero context about appropriate usage scenarios, prerequisites, or exclusions.
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 single-word description 'hotvideolist' reveals nothing about whether this is a read or write operation, what data it returns, whether it has side effects, rate limits, authentication needs, or any other behavioral traits. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (one word), this is a case of harmful under-specification rather than effective brevity. The single word 'hotvideolist' fails to convey necessary information, making it inefficient rather than well-structured. True conciseness balances brevity with completeness, which this description does not achieve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations and no output schema, the description provides virtually no contextual information. For a tool that presumably returns some kind of video list data (inferred from the name only), the description fails to explain what 'hot' means, what format the results take, or any other operational context. This is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. According to the rules, 0 parameters earns a baseline score of 4, as the description cannot be faulted for missing parameter semantics when none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools that might handle video-related operations (e.g., 'searchvideolist', 'recommend', 'list'), there is no indication of context, prerequisites, or differentiation. This represents a complete lack of usage guidance.
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 single word 'index' reveals nothing about whether this is a read or write operation, what resources it affects, potential side effects, rate limits, or authentication requirements. This is completely inadequate for a tool with unknown 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, this is a case of severe under-specification rather than effective conciseness. The single word 'index' fails to convey necessary information, making it inefficient rather than well-structured. It doesn't front-load key details because there are none to present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a vague description, this tool definition is completely inadequate. The description provides no insight into what the tool does, how it behaves, or what it returns, leaving an agent with insufficient information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add any parameter information, but this is acceptable given the empty schema, warranting a baseline score of 4 as per the rules for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'index' is a tautology that merely restates the tool name without providing any meaningful information about what the tool does. It doesn't specify any verb or resource, nor does it differentiate from sibling tools like 'index_2' or other similarly named tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 many sibling tools present (e.g., 'index_2', 'detail', 'list'), there is no indication of context, prerequisites, or distinctions that would help an agent choose appropriately.
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 single word 'info' reveals nothing about whether this is a read or write operation, what data it returns, any rate limits, authentication requirements, or other behavioral characteristics. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an agent understand or use the tool, making it ineffective despite its minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no annotations and no output schema. With zero behavioral information and no explanation of what 'info' means in this context, an agent cannot understand what the tool does, what it returns, or how to use it effectively among 82 sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate given the empty input schema. This earns a baseline score of 4 since the description doesn't need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 82 sibling tools on the server, including many that might retrieve information (e.g., 'detail', 'list', 'profile'), the lack of any context or differentiation makes it impossible for an agent to determine appropriate usage scenarios.
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 must fully disclose behavioral traits. 'item' gives no information about whether it's a read/write operation, its side effects, permissions, rate limits, or output format. It fails to compensate for the lack of structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, 'item' is under-specified rather than efficiently structured. It lacks front-loaded information and fails to convey essential details, making it ineffective despite its brevity. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by many sibling tools and the lack of annotations or output schema, the description is completely inadequate. It provides no context about functionality, behavior, or integration, leaving the agent unable to understand or use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, meaning the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, so it meets the baseline for a parameterless tool. No additional value is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With many sibling tools present (e.g., 'detail', 'list', 'item_1'), there is no indication of context, prerequisites, or distinctions. This leaves the agent with no usage direction.
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 single word 'item' reveals nothing about whether this is a read/write operation, what permissions are needed, what side effects occur, or how the tool behaves. This is completely inadequate for any tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, this is under-specification rather than true conciseness. A single word cannot convey necessary information, so it fails to be appropriately sized for its purpose despite minimal word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 provides no information about what the tool does, how it behaves, or what it returns, making it impossible for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate given the empty schema, earning a baseline score of 4 for not introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'item' is a tautology that merely restates the tool name without any meaningful explanation of what the tool does. It provides no verb, resource, or context, making it impossible to understand the tool's function or distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 description offers no context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios.
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 single word 'list' reveals nothing about whether this is a read-only operation, what permissions might be required, whether it's paginated, what format the results come in, or any other behavioral characteristics. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (one word), this represents under-specification rather than effective conciseness. A good description should be appropriately sized to convey necessary information - this single word fails to provide any meaningful context about the tool's purpose or usage, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero meaningful information, this description is completely inadequate. The tool exists among 89 sibling tools with similar naming patterns, yet the description gives no indication of what this specific tool does, making it impossible for an agent to understand when or how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though there are no parameters to describe). With no parameters to document, the description doesn't need to provide parameter semantics. The baseline for zero parameters is 4, as there's no parameter information that could be missing or incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With 89 sibling tools including several other list-related tools, there's no indication of what makes this specific 'list' tool appropriate for certain situations or what its scope or limitations might be.
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 single word 'list' gives no information about whether this is a read-only operation, what permissions might be required, whether it's paginated, what format the results take, or any rate limits or constraints. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'list' is certainly concise, this represents under-specification rather than effective brevity. A single word description fails to provide the necessary information for an AI agent to understand and use the tool correctly. Conciseness should not come at the expense of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides only the tool name repeated, this description is completely inadequate. The agent has no way to understand what this tool does, when to use it, what behavior to expect, or how it differs from numerous similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain any parameters, and the baseline for zero parameters with complete schema coverage is 4. The description doesn't contradict or add to the parameter information, which is appropriate given there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list' is a tautology that merely restates the tool name 'list_2', providing no meaningful information about what the tool actually does. It doesn't specify what resources are being listed, what scope is involved, or any distinguishing characteristics from sibling tools like 'list', 'list_1', or 'list_3'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With many similar-sounding sibling tools (list, list_1, list_3, and numerous other list-like tools), there's no indication of what makes this specific tool appropriate for certain situations or what distinguishes it from other 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 single word 'list' gives no information about whether this is a read-only operation, what permissions might be required, whether it's paginated, what format the results take, or any rate limits. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'list' is certainly concise, this represents under-specification rather than effective brevity. The single word fails to convey necessary information, making it inefficient rather than well-structured. Every sentence should earn its place, but here the lack of content is problematic, not virtuous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides only a single generic word, this description is woefully incomplete. The agent cannot understand what this tool does, when to use it, what behavior to expect, or what results it produces. This is inadequate even for a simple tool among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). With no parameters to document, the description doesn't need to provide parameter semantics. The baseline for zero parameters is 4, as there's nothing for the description to compensate for regarding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list' is a tautology that merely restates the tool name 'list_3', providing no meaningful information about what specific resource or data this tool retrieves. It fails to distinguish this tool from its many sibling tools (e.g., 'list', 'list_1', 'list_2', 'hotlist', 'searchlist'), leaving the agent completely in the dark about its actual 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With dozens of sibling tools that likely perform various listing operations, the agent has no indication of what makes 'list_3' unique or appropriate for specific scenarios. 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 full responsibility for behavioral disclosure. The single word 'live' gives no indication of whether this is a read or write operation, what data it accesses, what side effects it might have, or any performance characteristics. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an agent understand or use the tool, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by having 78 sibling tools and no output schema, the description is completely inadequate. A single word provides no information about what the tool does, when to use it, what it returns, or how it behaves. This fails to meet even minimal completeness standards for any non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. With no parameters to document, the description doesn't need to provide parameter semantics. The baseline score for zero parameters is 4, as there's no parameter information to add beyond what the schema already provides (which is complete).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 78 sibling tools on the server, the lack of any context about appropriate use cases or distinctions from similar tools (like 'aweme' or 'detail') leaves the agent with no basis for selection.
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 'lvideoTheater' reveals nothing about the tool's behavior - whether it's a read or write operation, what permissions are needed, what side effects might occur, or what the expected output looks like. This is completely inadequate for behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise (a single word), this represents under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an agent understand or use the tool. True conciseness balances brevity with information value, which this description completely lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero functional information, this is severely incomplete. The agent cannot determine what the tool does, when to use it, what behavior to expect, or what results it produces. This is inadequate for any tool, regardless of parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. Since there are no parameters to document, the description doesn't need to provide parameter semantics. The baseline for zero parameters is 4, as the absence of parameters means there's no parameter documentation burden on the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or comparison to sibling tools. With 78 sibling tools listed, the lack of any usage guidance makes it impossible for an agent to determine appropriate invocation scenarios.
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, 'mediumRelated' gives no information about what the tool does, whether it's read-only or mutative, what it returns, or any operational constraints like rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise with just one word, this represents under-specification rather than effective brevity. It lacks any structure or front-loading of critical information, making it unhelpful despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should fully explain what the tool does and returns. 'mediumRelated' provides none of this, leaving the agent completely in the dark about functionality, behavior, or output format in a context with many similar-sounding sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so there are no parameters to document. The baseline for zero parameters is 4, as the description doesn't need to compensate for any parameter documentation gaps, though it fails to provide other necessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, when not to use it, or what alternatives might exist among the many sibling tools. There is no mention of context, prerequisites, or comparison with similar tools like 'related' or 'recommend'.
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 single-word description 'module' reveals nothing about whether this is a read or write operation, what resources it affects, what permissions are needed, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to provide any meaningful information that would help an agent understand or use the tool, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no annotations and no output schema. It provides no information about what the tool does, what it returns, or how it behaves, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is appropriate given the empty input schema, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios among the many sibling tools listed.
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, and the description adds no behavioral information. It does not disclose whether the tool performs read/write operations, requires authentication, has side effects, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with a single word, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no annotations and no output schema. It provides no context about functionality, behavior, or output, leaving the agent unable to understand or use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add any parameter details, but this is acceptable given the lack of parameters, aligning with the baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, or exclusions, leaving the agent with no usage direction.
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 must fully disclose behavioral traits. However, it gives no information about whether this is a read/write operation, its effects, permissions needed, rate limits, or output format. The single-word description fails to provide any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely concise with just one word, this is under-specification rather than effective brevity. The description lacks any structure or front-loaded information, failing to communicate essential details. Conciseness should not come at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 should compensate by being comprehensive. However, it provides no context about the tool's function, behavior, or results. This is completely inadequate for a tool that likely performs some operation (given sibling tools include various data retrieval and processing functions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description doesn't add parameter details, but this is acceptable since there are no parameters to explain. A baseline score of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what context it applies to, or alternatives among the many sibling tools. It lacks any usage instructions, prerequisites, or exclusions, leaving the agent with no actionable information.
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 single word 'post' gives no information about whether this is a read or write operation, what permissions are required, what side effects occur, or what the response format might be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents under-specification rather than effective brevity. The description fails to communicate essential information and doesn't follow the principle that every sentence should earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with no annotations and no output schema. A single word provides insufficient context for an AI agent to understand what the tool does, when to use it, or what behavior to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so there are no parameters needing semantic explanation. The baseline for zero parameters is 4, as there's nothing for the description to compensate for regarding parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 sibling tools like 'post_1' available, there's no indication of what distinguishes this tool or when it should be selected over other 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation, what permissions might be needed, or any side effects, making it completely inadequate for understanding tool 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single word 'post' is technically concise, it represents severe under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given 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 provides no context about what the tool does, how it behaves, or what it returns, failing to compensate for the missing structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'post' is a tautology that merely restates the tool name without any meaningful elaboration. It provides no specific verb or resource context, fails to distinguish from sibling tools like 'post' in the list, and offers no indication of what this tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. There is no mention of context, prerequisites, or comparisons with sibling tools, leaving the agent with no usage direction.
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 single word 'profile' reveals nothing about whether this is a read or write operation, what data it accesses, authentication requirements, rate limits, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents severe under-specification rather than effective brevity. The description fails to convey necessary information, making it ineffective despite its minimal length. Every word should earn its place, but this word provides almost no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 80+ sibling tools, the description is completely inadequate. It provides no information about what the tool returns, how it behaves, or how it differs from related tools. The context demands much more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate given the empty schema. This meets the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers absolutely no guidance on when to use this tool versus alternatives. With no context about purpose or behavior, there is no basis for understanding appropriate usage scenarios or distinguishing it from other tools like 'info', 'self', or 'detail'.
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. 'recommend' gives no indication of whether this is a read or write operation, what permissions might be needed, what side effects exist, or how the tool behaves. It fails to provide any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient rather than appropriately sized. Every sentence should earn its place, but here the single word doesn't earn its place by being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a vague description, this is completely inadequate. The tool name 'recommend' could mean anything from content recommendations to system suggestions, but the description provides no context about what's being recommended, to whom, or with what criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and while it doesn't provide any semantic context about what 'recommend' means in terms of inputs, the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is absolutely no guidance on when to use this tool, what context it applies to, or when to choose alternatives. The description offers no information about usage scenarios, prerequisites, or exclusions.
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 single word 'related' reveals nothing about whether this is a read/write operation, what resources it affects, authentication requirements, rate limits, or expected behavior. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective brevity. The description fails to convey necessary information about the tool's function. True conciseness balances brevity with completeness, which this description does not achieve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by having 70+ sibling tools and no output schema, the description is completely inadequate. A single word cannot provide sufficient context for an agent to understand when and how to use this tool effectively. The description fails to compensate for the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter documentation gaps. While the description doesn't add parameter semantics (since there are none), this is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 70+ sibling tools including various list, detail, search, and discovery tools, there is no context about appropriate use cases, prerequisites, or exclusions. The single-word description fails to provide any usage direction.
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 single word 'reply' gives no information about whether this is a read or write operation, what permissions are required, whether it's destructive, what rate limits apply, or what the expected behavior is. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this is under-specification rather than effective conciseness. The description fails to provide any useful information that would help an AI agent understand or use the tool. Every sentence should earn its place, and this single word 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/5
Given 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 a completely inadequate description, the contextual completeness is extremely poor. The description fails to provide any meaningful information about what the tool does, when to use it, or how it behaves, making it impossible for an AI agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (though there are no parameters to describe). The description doesn't need to explain any parameters, so a baseline score of 4 is appropriate since there's no parameter information to provide beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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 sibling tools including 'reply_1' and various communication-related tools like 'post' and 'comment', there's no indication of when 'reply' is appropriate versus when other tools should be used instead.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states 'reply', which gives no insight into traits like read/write nature, side effects, permissions, or response format. It lacks any behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word 'reply', which is overly terse and under-specified rather than concise. It lacks any structure or front-loaded information, failing to provide meaningful content in an efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a vague description, this tool is inadequately documented. The description does not compensate for the missing structured data, leaving the agent with insufficient information to understand or use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter details are needed. The description does not add semantics, but this is acceptable as the schema fully documents the absence of inputs, meeting the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'reply' is a tautology that merely restates the tool name, providing no specific verb, resource, or action details. It fails to distinguish this tool from its sibling 'reply' in the list, leaving the purpose unclear 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/5
Does 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, what context it applies to, or how it differs from alternatives like 'reply' in the sibling list. The description offers no usage instructions, making it impossible for an agent to determine appropriate invocation.
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 single-word description gives no information about whether this is a read or write operation, what permissions might be required, whether it has rate limits, what format results are returned in, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective conciseness. A single word cannot provide the necessary context for tool selection and invocation, making this inefficient communication rather than well-structured brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and dozens of sibling tools, the single-word description is completely inadequate. It doesn't explain what the tool returns, how results are structured, what search capabilities it offers, or how it differs from related tools like 'searchlist' or 'hotvideolist'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% schema description coverage, so there are no parameters to document. The baseline for zero parameters is 4, as there's no need for the description to compensate for undocumented parameters. The description doesn't need to explain parameters that don't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus the many sibling tools available. With dozens of sibling tools including other search-related tools like 'searchlist' and 'suggestwords', there's no indication of what distinguishes this particular video search functionality.
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, and the description 'self' gives no behavioral information about what the tool does, its effects, permissions needed, rate limits, or return format. It fails to carry the burden of behavioral disclosure that annotations would normally provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, 'self' represents severe under-specification rather than effective brevity. The description fails to communicate essential information, making it inefficient despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's unknown complexity (no output schema, no annotations, no purpose explanation) and rich sibling tool environment, the description is completely inadequate. It provides no information to help an agent understand when or how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is appropriate given the absence of parameters, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 78 sibling tools and no context provided, there is complete absence of usage instructions, prerequisites, or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers nothing. It does not indicate whether this is a read or write operation, what effects it might have, any authentication requirements, rate limits, or expected outputs. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (one word), it is under-specified rather than efficiently informative. Conciseness should not come at the cost of clarity; here, the brevity fails to convey any useful information, making it ineffective despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a description that provides no meaningful content, this is completely inadequate. Even with 0 parameters, the tool's purpose, behavior, and usage remain entirely unexplained, failing to meet basic informational needs for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description does not need to add parameter semantics, so a baseline score of 4 is appropriate as it avoids unnecessary complexity. No additional value is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what context it applies to, or alternatives among the many sibling tools. There is no mention of prerequisites, conditions, or comparisons, leaving the agent with no information to make an informed selection decision.
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, and the description 'single' offers no behavioral information. It doesn't indicate whether this is a read or write operation, what permissions might be required, what side effects exist, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective conciseness. The single word 'single' fails to communicate any meaningful information about the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for understanding this tool. With no annotations, no output schema, and a meaningless description, the agent has insufficient information to determine when or how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter information, but this is appropriate given the empty parameter set, meeting the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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. The description offers no context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read or write operation, what permissions might be required, what side effects occur, or what the tool actually does beyond its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective conciseness. The description fails to provide any meaningful information that would help an AI agent understand or use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a completely uninformative description, this is completely inadequate. The description provides no information about what the tool does, how it behaves, or what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter information, but this is appropriate given the complete absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'single' is a tautology that merely restates the tool name without providing any meaningful information about what the tool does. It doesn't specify any verb, resource, or purpose, and offers no distinction from the numerous sibling tools listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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, when not to use it, or what alternatives might exist. There's no context about appropriate scenarios or prerequisites for invoking this tool.
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 single word 'social' reveals nothing about whether this is a read or write operation, what permissions might be required, rate limits, side effects, or any behavioral characteristics. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'social' is extremely brief, this represents under-specification rather than effective conciseness. A single word cannot convey the necessary information about a tool's purpose and behavior. The description fails to be appropriately sized for the complexity of the tool (which appears to be part of a large social media/data platform based on sibling names).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 70+ sibling tools in what appears to be a social media/data platform, and with no annotations, no output schema, and a completely inadequate description, this tool definition is severely incomplete. An AI agent would have no idea what this tool does or how to use it appropriately in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage is 100% with no properties), so there are no parameters to document. The description doesn't need to explain any parameters, which meets the baseline expectation for a parameterless tool. No points are deducted for not discussing nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool, when not to use it, or what alternatives might exist. With 70+ sibling tools and no context about this tool's purpose, there's zero usage guidance 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.
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 'sug' offers no information about what the tool does, its effects, permissions, rate limits, or any behavioral traits. This is a complete failure to provide necessary 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (just one word), it is under-specified rather than efficiently informative. Conciseness should not come at the cost of clarity; here, the brevity fails to convey any useful information, making it ineffective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a description that provides no meaningful content, the description is completely inadequate. It fails to explain what the tool does, how it behaves, or what to expect, making it insufficient for an AI agent to understand or use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, meaning the schema fully documents the lack of parameters. The description adds no parameter information, but since there are no parameters to explain, this is acceptable. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does 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, when not to use it, or what alternatives might exist. There is no context or prerequisites mentioned, leaving the agent with no usage instructions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers zero information about what the tool does, how it behaves, what it returns, or any operational characteristics. The single-word description fails to disclose any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents severe under-specification rather than effective brevity. The description fails to communicate essential information, making its conciseness detrimental rather than helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a description that provides zero functional information, this is completely inadequate. The tool name suggests word suggestion functionality, but the description offers no confirmation or elaboration, leaving the agent with no useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of parameters. The description doesn't need to compensate for any parameter gaps, and while it doesn't add semantic value, the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison to sibling tools like 'suggestwords' or 'sug' that appear related.
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 single word 'tab' reveals nothing about whether this is a read/write operation, its side effects, permissions needed, or response format. It fails to provide any 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely brief, this is under-specification rather than effective conciseness. A single word without context doesn't help an AI agent understand the tool, so it fails to earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and minimal description, this is completely inadequate. The description provides no meaningful information about what the tool does, how to use it, or what to expect, failing to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the empty schema, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With 80+ sibling tools available, there is no indication of context, prerequisites, or distinctions from other tools like 'list', 'detail', or 'index'.
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, and the description offers zero information about behavioral traits. It doesn't indicate whether this is a read or write operation, what permissions might be required, what side effects might occur, or any rate limits. The single-word description fails to carry the burden of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents under-specification rather than effective conciseness. The description is too brief to be useful, failing to provide any meaningful information that would help an AI agent understand or use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, no output schema, and a meaningless description, this tool definition is completely inadequate. The description fails to provide any context about what 'trans' means or does, leaving the AI agent with no useful information to work with.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description doesn't need to compensate for any parameter documentation gaps, though it also doesn't add any value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With 85 sibling tools on the server, this lack of context makes it impossible for an AI agent to determine appropriate usage scenarios or prerequisites.
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 responsibility for behavioral disclosure. The single-word description 'wallpaper' reveals nothing about whether this is a read or write operation, what permissions are needed, what side effects occur, or what the tool actually does behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents under-specification rather than effective brevity. The description fails to communicate essential information and doesn't earn its place as a helpful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a completely opaque purpose, the description is wholly inadequate. It provides no meaningful context about what the tool does, how it behaves, or what results to expect, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline score is 4. The description doesn't need to compensate for any parameter documentation gaps since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, when not to use it, or what alternatives might exist. With no context provided, an agent cannot determine appropriate usage scenarios or differentiate from the many sibling tools listed.
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 description 'webShorten' gives no indication of whether this is a read or write operation, what side effects it might have, authentication requirements, rate limits, or any other behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just one word, this represents under-specification rather than effective conciseness. The description fails to provide any meaningful information about the tool's purpose or usage, making it inadequate despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a completely opaque purpose, the description provides virtually no useful context. The agent would have no idea what this tool does, when to use it, or what to expect from it, making the description completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so there are no parameters requiring semantic explanation in the description. The baseline for zero parameters is 4, as the description cannot reasonably be expected to explain non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what context it's appropriate for, or how it differs from the many sibling tools listed. There is no mention of alternatives, prerequisites, or any usage context whatsoever.
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 single word 'list' gives no indication of what the tool actually does operationally - whether it's a read-only query, what data it returns, if there are rate limits, authentication requirements, or any side effects. This is completely inadequate for a tool with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with a single word, this represents under-specification rather than effective brevity. The description fails to convey any meaningful information about the tool's function, making it inefficient for agent comprehension despite its minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the context. With no annotations, no output schema, and numerous sibling tools that likely overlap in function, a single word 'list' provides insufficient information for an agent to understand what this tool does, how it differs from alternatives, or what to expect from its operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't need to compensate for any parameter gaps, and the empty input schema is self-explanatory. A baseline of 4 is appropriate since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list' is a tautology that merely restates the tool name 'list_1', providing no additional information about what specific resources or data are being listed. It fails to distinguish this tool from its many sibling tools (like 'list', 'list_2', 'list_3', 'hotlist', etc.), leaving the purpose completely ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools that likely perform similar listing operations (e.g., 'list', 'list_2', 'hotlist', 'searchlist'), the absence of any context or differentiation makes it impossible for an agent to determine appropriate usage scenarios.
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:

[![bachai-douyin-api-new MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-douyin-api-new/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-douyin-api-new)

Score Badge

Copy to your README.md:

[![bachai-douyin-api-new MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-douyin-api-new/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-douyin-api-new)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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-douyin-api-new'

If you have feedback or need assistance with the MCP directory API, please join our Discord server