redfox-mcp

Official

by redfox-data

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clear and distinct purpose, organized by platform (Douyin, Xiaohongshu, etc.) and action (search, get user, get work, generate). Even within similar functions across platforms, the names and descriptions make them unambiguous. The result-query tools are explicitly paired with their generation counterparts.
Naming Consistency5/5
All tool names follow a consistent pattern: platform_or_service_action, using snake_case (e.g., douyin_search_articles, ai_search_kimi, doubao_image_pro_generate). The naming is predictable and intuitive, with no mixing of conventions or cryptic abbreviations.
Tool Count4/5
At 40 tools, the count is high, but it is justified by the server's broad scope covering multiple social media platforms and AI generation services. Each tool earns its place, though the sheer number could be slightly overwhelming. Still, it remains well-scoped for its intended use case.
Completeness5/5
For the server's stated purpose—searching and retrieving content from various social media platforms plus generating images/videos and performing AI searches—the tool surface is comprehensive. Each platform includes search, user info, works list, and detail retrieval. AI generation and search workflows are fully covered with both submission and result query tools.
Average 3.5/5 across 40 of 40 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'get metadata' which implies a read operation, but does not disclose idempotency, potential side effects, required permissions, or data freshness. The 'high-quality library' hint is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it could include more contextual information without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 parameter descriptions, the description provides insufficient context for correct invocation. It does not explain what the output schema contains, error behavior, or the meaning of 'high-quality library'. The agent is left to infer the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the parameter `work_uuid` has no schema-level description. The tool description merely repeats 'work UUID' without adding format, source, validation, or examples. It fails to compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves WeChat public account article metadata by work UUID, and adds 'high-quality library' context. While the verb and resource are specific, it does not explicitly differentiate from sibling tools like wechat_get_article_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as wechat_get_article_detail or wechat_search_articles. The description omits prerequisites, common use cases, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions pagination via offset but does not disclose how the '优质库' selection works, rate limits, authentication requirements, or whether search results include full profiles. For a search tool, critical behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that get to the point. The key constraint (keyword required) and pagination detail are front-loaded. No filler or duplication of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, and an output schema is present but the description is minimal. Given the sibling landscape with many search tools and the lack of guidance on 'sort_type' or result format, the description is not complete enough for a reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'keyword' is required and that 'offset' starts at 0, but does not clarify the purpose or valid values of 'sort_type'. With 3 parameters and only partial explanation of two, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource '抖音账号', and distinguishes its scope from siblings like 'douyin_get_user' (single user retrieval) and 'douyin_search_articles'. The mention '优质库' implies a curated user database, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that 'keyword' is required and gives the offset behavior, but it does not explain when to use this tool over alternatives like 'douyin_get_user' (for known user details) or when to choose different sort types. No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose important behavioral traits such as whether the tool works for all WeChat articles, what happens if the URL is invalid or behind a paywall, or if there are any rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that get to the point. It could be slightly improved by removing the vague '优质库' qualifier or explaining it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, but does have an output schema, the description should cover what the tool returns or any prerequisites. It does not mention output format or any limitations, leaving gaps for a single-parameter 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?
There is only one parameter (url), and the description adds context by specifying the expected URL format and that it is for a WeChat article. With 0% schema coverage, this is valuable, but the description could further clarify what kind of URLs are supported (e.g., only mp.weixin.qq.com).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a WeChat public account article, including full content, given a URL. The URL format is exemplified. However, '优质库' is a bit vague and could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wechat_get_work or wechat_search_articles. The context of '优质库' suggests a curated subset, but this is not explicitly communicated as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the 'account' field is required and explains sort_type and date format, but does not state whether the operation is read-only, if pagination is supported (offset is there but not explained), or if there are any rate limits or safety concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains useful detail. It front-loads the main purpose and explains key parameters. However, it mixes Chinese and English, and could be more structured (e.g., grouping optional params).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter input, no annotations, and an output schema present, the description provides enough to get started but omits details on 'offset', 'account_name', and return value expectations. It is adequate but not thorough.
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 0%, so the description must compensate. It adds meaning for 'account', 'sort_type', and date parameters, but does not describe 'offset' or 'account_name'. With 6 parameters and only 3 explained, it partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取公众号文章列表（优质库）' which translates to 'get WeChat official account article list (quality library)' and specifies that 'account' is required. This is a specific verb+resource combo, but it does not distinguish itself from siblings like 'wechat_get_work' or 'wechat_search_articles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameter choices (e.g., sort_type values, date format) but does not provide guidance on when to use this tool versus alternatives like 'wechat_search_articles' or 'wechat_get_work'. No 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states keyword is required and offset for pagination. It does not mention authentication needs, rate limits, whether the operation is read-only, or what 'quality library' implies. The usage of sort_type is entirely undiscussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loads purpose. Every sentence serves a point: purpose then parameter requirements. However, it is so brief that it sacrifices completeness, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, 1 required, and an output schema exists (so return values are covered), the description still omits sort_type, lacks behavioral context (e.g., pagination limits, authentication), and does not explain the 'quality library' qualifier. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains keyword (required) and offset (pagination), but completely ignores sort_type, which has no enum or description. Thus, only 2 of 3 parameters receive partial explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('搜索', search), resource ('小红书博主账号', Xiaohongshu blogger accounts), and a qualifier ('优质库', quality library). This distinguishes it from sibling tools like xiaohongshu_search_articles or xiaohongshu_get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., xiaohongshu_get_account for known accounts, xiaohongshu_search_articles for articles). There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only states the tool gets info from a 'quality library' and explains the parameter. It does not disclose whether the operation is read-only, if authentication is required, what fields are returned, or any rate limits. The term '优质库' is vague and could mislead about the data source. The description is insufficient for an agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the purpose and parameter explanation. Every sentence is necessary and informative. No fluff or redundancy. It is optimally sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema (which reduces the need to describe return values), the description lacks crucial context for decision-making. The ambiguous '优质库' is not explained. There is no guidance on when to use this tool over sibling tools like bilibili_search_users or bilibili_get_user_works. For a tool with multiple siblings in the same platform, the description should provide more contextual cues to help the agent select 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 input schema has one parameter 'mid' with no description in the schema itself (schema description coverage 0%). The description adds 'mid 为 B 站用户唯一 ID', which explains the semantic meaning of the parameter. This is valuable beyond the schema. However, it does not specify format, length, or constraints. Given the low schema coverage, the description compensates well but not exhaustively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting Bilibili UP master info. It specifies the resource ('UP主信息') and the required parameter ('mid'). While it doesn't explicitly distinguish from siblings like bilibili_search_users, the verb 'get' and the mention of 'mid' as a unique ID imply a direct lookup, not a search. The addition of '优质库' (quality library) suggests a specific dataset, adding some context but also potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. Sibling tools include bilibili_search_users (which might also return user info) and bilibili_get_user_works (which lists works for a user). No mention of prerequisites, limitations, or scenarios where this tool is preferred. The agent has no explicit criteria to choose 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It reveals that the tool accesses a '优质库' (quality library) but does not define that term, nor does it mention whether the operation is read-only, destructive, or subject to rate limits. Lacking these details, the transparency is insufficient for an agent to fully anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only two sentences—and front-loads the core purpose. Every word contributes essential information. It could be slightly improved by structuring the parameter notes more clearly, but overall it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description provides only a vague summary ('视频列表'). It does not explain pagination behavior, the meaning of '优质库', or what data is included for each video. For a tool with five parameters and a nontrivial domain, the description leaves too many gaps for an agent to use it reliably without additional context.
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?
With 0% schema description coverage, the description must compensate. It explains the relationship between 'mid' and 'account_url' (at least one required) and lists the possible values for 'order'. However, it omits any explanation of 'page' and 'page_size', leaving those parameters semantically opaque for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a video list for a Bilibili UP master (creator). It includes the verb '获取' (get) and the resource '视频列表' (video list), which is distinct from sibling tools like bilibili_get_work (single work) or bilibili_get_account (account info). However, it does not explicitly contrast with these siblings, so it is clear but not top-tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage rules: at least one of 'mid' or 'account_url' is required, and it explains the valid values for 'order' (time, play, like). It does not, however, offer guidance on when to prefer this tool over siblings (e.g., when to use bilibili_get_work instead) or any context-dependent recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It describes a search operation that likely involves network requests and potential rate limiting, but it does not mention any destructive or read-only behavior, data freshness, or pagination behavior. The note '（优质库）' hints at a curated dataset but lacks clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only two sentences with no extraneous fluff. Key information is front-loaded in the first sentence. It could be slightly more structured by separating the required/optional sections textually.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 5 parameters, the description is incomplete. It does not explain what the output contains (e.g., a list of articles, metadata), how pagination works, or how the time filters interact with the curated dataset. More detail is needed for effective use.
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 description adds value by specifying the keyword as required and illustrating the datetime format for start_time/end_time. However, with 0% schema description coverage, the meaning of page_num and page_size is left implicit, and the description does not explain the effect of these parameters for pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches for Douyin AI-related works using a keyword, which is a specific verb and resource. However, it does not distinguish itself from the closely related sibling 'douyin_search_articles', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by indicating that 'keyword' is required and specifies the date format for start_time and end_time. However, it does not explain when to use this tool versus alternatives like 'douyin_search_articles', 'xiaohongshu_search_ai_articles', or other platform-specific search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions keyword requirement and date format, but omits behavioral traits like pagination, sorting, rate limits, or any side effects. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences providing key information without filler. Purpose is front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema, the description is too sparse. It covers the required keyword and date format but leaves pagination behavior, result structure, and usage compared to sibling tools unaddressed. An agent would have gaps in effectively using this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It explains the keyword parameter and date format for start_time/end_time, but does not mention page_num or page_size parameters, nor explain the semantic meaning of the date range (e.g., filter by publication time).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (search) and resource (WeChat Official Account AI-related articles from a high-quality database). It clearly distinguishes from sibling tools like wechat_search_articles (general search) by narrowing to AI creations and using '优质库'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as wechat_search_articles. The description does not provide context for selection, it only gives required parameter and date format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the result comes from a '优质库' (quality database) and mentions pagination via 'offset', which adds behavioral context. However, it does not state whether the operation is read-only, if authentication is needed, or how results are sorted (sort_type is mentioned in schema but not explained).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two short sentences), which is concise but leaves out critical information (e.g., what the output contains, sort_type semantics). It is front-loaded with the core purpose but sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown in detail), the description does not need to explain return values. However, with 3 parameters (one undocumented) and no annotations, the description is incomplete for a search tool. It lacks guidance on sorting, result limits, and the nature of '优质库'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only elaborates on 'keyword' (required) and 'offset' (pagination). It does not explain 'sort_type' (default null, types string or null) – what sorting options exist or how it affects results. With 3 parameters and no schema descriptions, the description should provide more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Xiaohongshu notes ('搜索小红书笔记') and specifies it uses a '优质库' (quality database). The verb '搜索' and resource '笔记' are specific, and the description distinguishes this from sibling search tools like xiaohongshu_search_users or xiaohongshu_search_ai_articles by the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates 'keyword' is required and 'offset' is for pagination, implying usage for iterative searching. However, it does not explain when to use this tool versus the sibling xiaohongshu_search_ai_articles or other search tools, nor does it mention any prerequisites or limitations (e.g., rate limits or account requirements).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '优质库' but does not explain what this implies (e.g., curated, verified, or popular users). It also lacks disclosure on pagination behavior, result limits, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), front-loading the purpose and then parameter hints. No wasted words, but it could be more structured with clear sections for each parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (1 required), no annotations, and an output schema, the description is incomplete. It does not explain the '优质库' concept, page_size meaning, or how pagination works. The output schema exists but is not described; the description should at least hint at result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains keyword (required) and order (follower/like, default relevance), but does not mention page, page_size, or their defaults. This leaves half the parameters undocumented, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Bilibili UP主 (creators) in a '优质库' (quality library). The verb '搜索' (search) and resource 'UP主' are specific, and it distinguishes from sibling tools like bilibili_search_articles which search articles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that keyword is required and explains the order parameter values (follower/like, default relevance). However, it provides no guidance on when to use this tool versus alternatives like bilibili_get_account for specific user details, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior ('cursor 翻页游标第一页为 0、每页 +10；rid 为上一页数据返回的 rid，翻页时传入') and return fields ('返回含 cursor/hasMore/userList'). However, it does not specify any destructive/read-only nature, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main purpose. It packs pagination logic and return fields efficiently. Minor punctuation issues but still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and an output schema exists, the description covers pagination behavior adequately. However, without annotations, it could still benefit from additional behavioral context (e.g., whether the tool is read-only, any prerequisites). The output schema likely documents return values, so the description's mention of return fields is somewhat redundant but helpful for quick understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains keyword (required), cursor (starts at 0, increments by 10 per page), and rid (needs to be passed from previous page). However, it does not clarify default values or acceptable formats beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '搜索 TikTok 账号' (search TikTok accounts), using a specific verb and resource. However, it does not differentiate from sibling tools like 'douyin_search_users' or 'xiaohongshu_search_users', as they all search users on different platforms. The platform name in the tool name and description provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that 'keyword' is required and explains the cursor and rid parameters for pagination, implying how to use the tool for paginated searches. However, it does not provide guidance on when to use this tool versus alternatives (e.g., for TikTok-specific user searches) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions that keyword is required, time format, and optional source, but fails to disclose pagination behavior (page_num, page_size), the fact that it searches a curated 'high-quality library', or any read-only guarantee. The description is minimal and leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of one title sentence and three bullet-like statements. It front-loads the main purpose. Every sentence adds information, though it could be slightly more structured. No wasted words, but additional details would not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema, the description is incomplete. It does not explain the curation aspect ('优质库'), the output nature, or pagination. While output schema exists, the description lacks context about the search scope and limitations. It leaves the agent guessing about important details.
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 0%, so the description must compensate. It adds meaning for keyword (required), start_time/end_time (format example), and source (optional platform). However, it omits page_num and page_size entirely, and does not elaborate on the semantics of 'source' or the time parameters beyond format. It adds some value but not enough to fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Xiaohongshu AI creation related notes, specifically a 'high-quality library'. The name and scope differentiate it from sibling tools like xiaohongshu_search_articles (general search) and xiaohongshu_search_users, providing a specific verb (search) and resource (AI notes on Xiaohongshu).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for AI-themed content by specifying 'AI creation related notes', but it does not explicitly state when to use this tool over alternatives like xiaohongshu_search_articles. It provides format requirements for time parameters but lacks guidance on when to use or avoid the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool automatically waits for results and returns a taskId on timeout, which can be checked via 'doubao_image_pro_result'. It also mentions that 'optimize_prompt' enables prompt optimization. This gives agents a clear picture of the async lifecycle. However, it does not mention any rate limits, authentication requirements, or potential side effects (e.g., cost), but for a generation tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loads the core purpose. It uses a semi-bulleted structure to explain parameters. Every sentence adds information, though the parameter explanation could be more formally organized. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters and an output schema exists, the description covers the async behavior and the most important parameters (size, image, optimize_prompt). However, it neglects important parameters like prompt (the only required one!), watermark, output_format, and response_format. The output schema is not referenced, but since it exists, the description doesn't need to detail return values. The description is adequate for a quick understanding but not fully complete for complex usage.
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 0%, so the description must compensate. It explains 'size' (supports '1K'/'2K' or pixel values), 'image' (URL/Base64, single or list), and 'optimize_prompt' (but confusingly mentions 'standard/fast' which align with 'optimize_mode' in the schema, not the boolean 'optimize_prompt'). This leaves 6 out of 9 parameters (prompt, watermark, optimize_mode, output_format, response_format, timeout_seconds) unexplained. The description adds value for key parameters but has an ambiguity and incomplete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '豆包 Seedream 5.0 Pro 图片生成' (image generation) and '提交后自动等待结果' (automatically waits for results). It identifies the specific model version (Seedream 5.0 Pro), which helps distinguish it from siblings like 'doubao_image_lite_generate'. However, it does not explicitly contrast with other generation tools (e.g., gpt_image_generate), leaving some ambiguity about when to choose this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 sibling tools like 'doubao_image_lite_generate' or 'gpt_image_generate'. It only explains internal behavior (timeout handling and async retrieval) but does not compare capabilities, cost, or quality. The agent is left to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It reveals that the tool automatically waits for completion and returns imagePaths, and on timeout returns a taskId for later retrieval. This is decent disclosure, but it omits information about authorization requirements, rate limits, or potential side effects (though the tool is not destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose and then lists key parameters. It is concise with no redundant information. However, it could be slightly more structured (e.g., using bullet points) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, one required), the description covers the essential operations and return behavior, including timeout handling. The output schema exists, so return values need not be detailed. However, several parameters (size, n, output_compression) are left unexplained, which may cause confusion for an AI agent.
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 0%, so the description should compensate. It explains operation, images (with format), input_fidelity, quality, background, output_format, and timeout behavior. However, it does not explain n, size, model_name, timeout_seconds, or output_compression. The partial coverage is helpful but insufficient for all 12 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs GPT image generation (gpt-image-2) with two modes: generate (text-to-image) and edit (image-to-image). It also mentions returning imagePaths and timeout behavior, differentiating from the sibling gpt_image_result. However, it does not explicitly distinguish from other generation tools like doubao_image_pro_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context for the 'edit' operation (images required, format, input_fidelity) and timeout fallback (use gpt_image_result). It does not compare with other image generation tools or specify when to avoid this tool. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the real-time nature and pagination behavior (offset starts at 0, increments by 1 per page). However, with no annotations, it fails to disclose other important behavioral traits such as authentication requirements, rate limits, or whether the tool is read-only. The disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence plus parameter hints. There is no wasted text, and every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic usage and pagination, but lacks context about the scope of the search (e.g., what types of content are included), potential limitations, or how to interpret results. The existence of an output schema partially compensates for missing return value details, but the overall description feels sparse for a tool with many 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?
With 0% schema description coverage, the description provides essential meaning for both parameters: it clarifies that 'keyword' is required and 'offset' is a pagination offset starting at 0 and incrementing by 1 per page. This adds value beyond the raw schema, but does not elaborate on the format or expected values of the keyword.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '搜索今日头条内容（实时）' (Search Toutiao content (real-time)), clearly identifying the action (search) and resource (Toutiao content). It is not a tautology and distinguishes from sibling tools like toutiao_get_work, though it does not explicitly contrast with other platform search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 other search tools for different platforms. There is no mention of prerequisites, alternatives, or scenarios where this tool is preferred. This is a significant gap given the large number of sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. The description indicates a non-destructive read operation (get info), which is correct. However, it does not specify any behavioral details such as auth requirements, rate limits, or what happens if the account does not exist. The output schema exists but is not described here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded with the core purpose. Two sentences cover purpose and parameters without superfluous text. Could be improved with slightly more structure (e.g., bullet points for parameters), but currently efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, description does not need to detail return values. The tool has 2 parameters (1 required) and no complex nested objects, so completeness is modest. However, the description lacks guidance on error handling, data freshness, or curation criteria of '优质库', which would help the agent in edge cases.
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 0%, so description must compensate. The description explains that 'account' is the WeChat ID (微信号) and 'account_name' is the WeChat official account name (公众号名称), adding meaning beyond the schema's bare type definitions. This is helpful but minimal; no further detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves WeChat official account information, identifying the resource (WeChat official account) and action (get account info). The mention of '优质库' suggests a curated data source, which adds specificity. However, it does not explicitly distinguish from sibling tools like 'wechat_get_user_works' or 'wechat_get_work', which share the 'get' verb and WeChat context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks 'account' as required and 'account_name' as optional, providing basic input guidance. No guidance on when to use this tool versus alternatives (e.g., searching for accounts first via 'wechat_search_users'). No conditions or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals pagination behavior ('offset 从 0 开始、每页 +20') which is helpful. However, it doesn't disclose what '优质库' means, whether results are rate-limited, or if authentication is needed. The output schema exists but is not referenced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. Every word earns its place. The pagination rule is efficiently communicated in a parenthetical. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 params, an output schema, and no annotations, the description is minimally adequate but leaves gaps. The 'sort_type' parameter and the meaning of '优质库' are unexplained. However, with an output schema present, return values don't need 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 0%, so the description must compensate. It adds meaning for 'keyword' (required) and 'offset' (start 0, increment 20) which is not in the schema. However, 'sort_type' is not explained at all, and the description is minimal. Baseline 3 is appropriate given the partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches WeChat public account articles ('搜索公众号文章'), and adds '（优质库）' to hint at a quality filter, which differentiates it from siblings like 'wechat_search_ai_articles' and 'wechat_search_articles' (presumably a broader search). The verb 'search' and resource 'articles' are specific, though the '优质库' note is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides basic use context (keyword required, offset behavior) but no explicit when-to-use or when-not-to-use guidance. Sibling tools like 'wechat_search_ai_articles' exist but are not mentioned as alternatives. The guidance is implied through the '优质库' qualifier but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It clearly states the tool submits a generation job, automatically waits for the result, and on timeout returns a taskId for later retrieval. This covers the key behavioral trait (async behavior with fallback). It does not mention rate limits, permissions, or whether the operation is destructive, but for a generation tool, the mutation is expected and the description adequately explains the wait-timeout pattern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first line gives the core purpose. Parameter details are listed concisely. It could be improved by grouping optional parameters mentioned vs not mentioned, but overall it uses few words effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 parameters and an output schema (not inspected), the description covers the most important input parameter (content) well and explains the timeout behavior. But it misses many optional parameters and provides no guidance on output format (though the output schema exists). The tool has obvious siblings (doubao_video_result) and the description acknowledges that relationship. Overall, it's adequate but leaves optimization and edge-case handling to the 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?
Schema description coverage is 0%, meaning the description must explain all parameters. The description covers 'content' (required, with detailed format examples), 'resolution', 'ratio', and 'duration' with valid values. It also mentions the special duration value -1 for intelligent duration. However, it omits explanation for 'seed', 'model', 'watermark', 'generate_audio', 'timeout_seconds', and 'return_last_frame', which are left entirely to the schema (which has no descriptions). Given the low coverage, this is a significant gap, but the most critical parameter (content) is well-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for '豆包 Seedance 2.0 视频生成' (video generation) and that submission automatically waits for the result. It distinguishes from sibling result-fetching tools like 'doubao_video_result' and other image generation tools (gpt_image, doubao_image). However, it lacks an explicit verb like 'create' or 'generate' in the first sentence, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It only mentions that 'doubao_video_result' can be used to check results on timeout, but doesn't explain when to prefer this over other generation tools (e.g., doubao_image_pro_generate) or how to choose between them. Missing context like prerequisites (e.g., need for reference images/videos) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It only states what is returned (interaction data, author info, etc.) without mentioning any side effects, authentication needs, rate limits, or error behavior. For a data retrieval tool, more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The purpose and parameter condition are front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) which can define the return structure, so the description's high-level summary ('互动数据、作者信息等') is acceptable. However, it lacks coverage of error conditions, authentication context, or detailed scope explanation of '优质库'. Adequate but has gaps.
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?
Schema description coverage is 0%, but the description explicitly links both parameters to their real-world meaning: 'work_id' and 'work_url' (作品链接). It also states the constraint that at least one must be provided. This adds significant semantic value beyond the raw schema, though examples or formats would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the resource '抖音作品详情' (Douyin work details). It includes the scope '优质库' (premium library), which distinguishes it from other Douyin tools like 'douyin_get_user' or 'douyin_search_articles'. The requirement to provide either work_id or work_url further differentiates it as a detail retrieval for a single work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter usage guidance (at least one of work_id/work_url required) but no explicit advice on when to use this tool versus siblings like 'douyin_get_user_works' or 'douyin_search_articles'. No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It correctly reveals the auto-wait and async timeout behavior (returning taskId). However, it omits other behavioral traits such as whether the operation is read-only, any permission requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences. Every word carries meaning: the purpose, the auto-wait behavior, the parameter role, and the fallback mechanism. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow (submit, wait, receive results or taskId) and mentions the companion tool ai_search_deepseek_result. Given that an output schema exists (not shown), return details need not be described. It could be improved by explicitly stating the timeout_seconds parameter purpose and range, but overall it provides sufficient context for an agent to invoke the tool correctly.
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 0% description coverage, so the description must compensate. It explains inquiry_text as the search query text and implicitly describes timeout_seconds via the timeout behavior. However, it does not explicitly define timeout_seconds or its default value, leaving part of the parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a Deepseek AI search tool that submits and automatically waits for complete results. It mentions the async fallback with taskId, making the purpose specific. However, it does not differentiate this from sibling AI search tools like ai_search_kimi or ai_search_doubao, relying on the tool name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Deepseek search queries, and mentions the fallback to ai_search_deepseek_result on timeout, providing a usage path. However, it gives no explicit guidance on when to choose this tool over other AI search tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'query result' without explaining error behavior, idempotency, or what happens if the task is still pending. For a polling tool, expected details like 'returns status and result when ready' are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second defines usage condition. No extraneous words, front-loads the core function. Ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter and the presence of an output schema, the description is partially complete. It covers purpose and usage context but omits parameter explanation and behavioral nuances like error handling. The agent can infer the taskId source from the usage note but not explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema lacks any description for the 'task_id' parameter. The tool description does not mention the parameter or explain its expected format or source, failing to add any semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the result of a Seedream 5.0 Lite task. The verb '查询' (query) and resource '任务结果' (task result) are specific. It distinguishes itself from sibling tools like 'doubao_image_pro_result' and 'doubao_video_result' by referencing the specific model and generator tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: '仅在 doubao_image_lite_generate 超时返回 taskId 后使用' (only after doubao_image_lite_generate times out and returns a taskId). This provides clear context for invocation and implies not to use it before generation completes or for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. The description indicates a read operation ('获取信息'), which is consistent with the tool name. However, it does not disclose any potential rate limits, authentication requirements, or what happens if the account_id is invalid. The mention of '优质库' hints at data freshness or quality but lacks specifics, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus a clarification on the parameter). It is front-loaded with the main purpose and immediately follows with the key detail about id matching. Every part serves a purpose, though it could be slightly more structured with explicit labels.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is only one parameter and an output schema exists, the description covers the essential points: what the tool does and how to use the input. It doesn't explain the return format, but the presence of an output schema mitigates this need. It is complete enough for a simple lookup 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 input schema has only one parameter (account_id) with no description (coverage 0%). The description adds significant value by explaining that account_id can be a unique_id, short_id, or uid, and that any of these can be used to match. This goes well beyond the bare schema and compensates for the lack of schema-level documentation, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取抖音账号信息' (get Douyin account info) with a specific verb and resource. It also notes the data source is an '优质库' (high-quality database), which adds useful context. While it doesn't explicitly differentiate from siblings like 'xiaohongshu_get_account', the platform-specific name and description already signal this is for Douyin, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states that the tool is used to look up a user by account_id, and even clarifies the id matching options. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'douyin_search_users' or 'douyin_get_user_works', nor does it mention any prerequisites or exclusions. Thus, a 3 for implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that offset increments by 20 per page, and sort_type options (0=default, 2=newest, 4=hottest). It does not disclose rate limits, auth requirements, or result count limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 sentences covering purpose, prerequisites, and parameter details. No fluff. Could be slightly better structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, but description covers purpose, parameter usage, and pagination behavior. Has output schema so return values are covered. Missing info on rate limits, but adequate for a list 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?
Schema coverage is 0%, so description must compensate. It explains the meaning of all key parameters: account_id/author_url/sec_user_id (at least one), offset (pagination +20), sort_type (values 0,2,4). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取抖音账号作品列表' (get Douyin account works list), which is a specific verb and resource. It is clearly distinct from sibling tools like 'douyin_get_work' (single work) and 'douyin_search_users' (search users), though not explicitly differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage conditions: at least one of account_id/author_url/sec_user_id must be provided. It also hints at pagination with offset +20. However, it does not explain when to use this vs other tools like douyin_get_work or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that offset starts at 0 and increments by 20, explains sort_type default behavior, and mentions the return fields (total/hasMore/list). However, it does not describe mutation, rate limits, or authorization needs. The description is adequate given the absence 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three packed sentences. Each sentence adds distinct value: purpose, key parameter details, and return structure. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to detail return values. However, the tool lacks annotations, parameters have no schema descriptions, and the sibling tools suggest many search variants. The description covers basics but could better explain when 'sort_type' accepts specific values besides 'default' and whether the search is real-time or cached.
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 3 parameters with 0% description coverage, so each parameter has no JSON-schema-level explanation. The description compensates well by specifying that keyword is required, offset is pagination starting at 0 with +20 step, and sort_type uses 'default' string. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '搜索抖音作品（优质库）' meaning 'search Douyin works (high-quality library)', which identifies the tool's purpose. The differentiation from sibling tools is implied by the platform and content type (Douyin articles/works vs. users or other platforms).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates keyword is required and provides usage details for offset and sort_type, but it does not explain when to use this tool versus related tools like 'douyin_search_users' or 'douyin_search_ai_articles'. It gives pagination hints but lacks guidance about search context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It notes the source is a '优质库' (premium database), hinting at data quality. It does not disclose behavioral traits such as whether this makes network requests, whether it returns cached vs live data, authentication requirements, rate limits, or destructive behavior. For a read tool with no annotations, more behavioral detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two short sentences. Every part adds value: the purpose, the '优质库' qualifier, and the parameter semantics. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and an output schema exists (so return values are documented), the description is mostly adequate but missing usage guidelines and behavioral details. It identifies the '优质库' data source and explains parameters, but for a tool with no annotations, more behavioral transparency around safety and usage would improve completeness.
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?
Schema description coverage is 0%, so the description must compensate. It explains that account_id is the Xiaohongshu account number (required) and user_id is optional. The description adds meaning beyond the raw schema by clarifying that account_id is the '小红书号' (Xiaohongshu ID) and marking it as required, and that user_id is optional. However, it doesn't explain the difference between the two parameters or when to provide user_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Xiaohongshu account information, with a specific verb ('获取' meaning 'get') and resource ('小红书账号信息'). It distinguishes from siblings like 'xiaohongshu_search_users' (search) and 'xiaohongshu_get_work' (get a specific work), though it could more explicitly contrast with the search variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you need account info and know the account_id. It mentions '优质库' (premium database), suggesting higher quality data source. However, it provides no guidance on when not to use it, alternatives like xiaohongshu_search_users if you don't know the account ID, or prerequisites such as needing the correct account_id format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: auto-wait, timeout returns taskId for later query, and support for batch images via 'sequential' and 'max_images'. This goes beyond the schema defaults. It does not mention rate limits or authorization, but for a generation tool, the behavioral coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three sentences. The first sentence sets the purpose and primary behavior, followed by parameter specifics. Every sentence adds unique value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, an output schema, and no annotations, the description covers the core generation and batch functionality but omits details on many optional parameters. The output schema helps with return values, but settings like 'optimize_mode', 'watermark', and 'image' are left unclear.
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 0%, so the description must compensate. It adds meaning for three parameters (size values, sequential=auto for batch, max_images range 1–10) out of 11 total. It also indirectly clarifies timeout behavior. This aids core usage but leaves many parameters like 'image', 'watermark', 'optimize_mode', 'output_format', etc. unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for image generation using the Doubao Seedream 5.0 Lite model, with support for batch images and auto-wait. The name itself differentiates from sibling tools like 'doubao_image_pro_generate' and 'gpt_image_generate', but the description does not explicitly compare them, leaving mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains auto-wait behavior and timeout fallback with a reference to the result query tool, giving implicit guidance for synchronous vs async usage. However, it does not state when to use this Lite version over the Pro version or other image tools, and lacks explicit 'when-not-to-use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly states the tool auto-waits and returns a complete result, and that on timeout it returns a taskId for retry. This provides moderately useful behavioral context. However, it doesn't disclose rate limits, authentication needs, or cost implications—important for a network-calling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, each earning its place: the first states the core purpose and output, the second explains parameters and timeout behavior. It front-loads the key verb '搜索' and is free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return value format is not needed in the description), and the tool is relatively straightforward (search with timeout), the description covers the main flow. However, it lacks mention of any error conditions, input validation rules, or what 'content' typically contains (e.g., is it structured or plain text?). The sibling tools array is large, and without more detail, the agent may confuse tool variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions the purpose of 'inquiry_text' as '搜索提问文本'. It does not explain 'timeout_seconds' beyond the default value in the schema, leaving the agent to infer its role. With two parameters but minimal explanatory text, the description fails to add meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Kimi 联网 AI 搜索' (online AI search) and specifies that it returns a complete result with 'content/webPages'. It distinguishes itself from search tools for other platforms (e.g., ai_search_doubao, ai_search_deepseek) by naming 'Kimi' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's an AI search tool that waits for completion and returns results. It also mentions a timeout scenario and refers to the sibling tool 'ai_search_kimi_result' for retrying when a taskId is returned. However, it doesn't explicitly state when not to use this tool (e.g., if the user only needs a quick cached result).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey all behavioral traits. It specifies parameter constraints (page start, page_size defaults, order options) but does not disclose whether the operation is read-only, if authentication is required, rate limits, pagination limits beyond page_size, or what happens on empty results. Significant behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no redundant words. The first sentence states the purpose, the second structures parameter details in a clear list format. Every sentence adds value, keeping the description efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description covers parameter semantics well but lacks behavioral transparency (auth, read-only, rate limits) and usage guidance. It is adequate for basic use but leaves gaps that could affect correct invocation in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries the parameter explanation. It clarifies keyword as required, page starting from 1, page_size default 10 and max 50, and enumerates allowed order values (time, play, like, comment, favorite). This adds substantial meaning beyond the schema's minimal type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb '搜索' (search) and the resource 'B站视频' (Bilibili videos) with a qualifier '优质库' (high-quality library), clearly differentiating from sibling tools like 'bilibili_search_users' and 'bilibili_get_work'. The purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives (e.g., bilibili_search_users, douyin_search_articles). The usage context is implied by the tool name and resource description, but there are no exclusions or situational recommendations, resulting in moderate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the purpose and usage condition but does not mention whether the operation is read-only, how it handles in-progress or failed tasks, polling behavior, rate limits, or authentication requirements. The timeout condition is hinted but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the tool's purpose and then provides the usage condition. Every sentence earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are covered. The description provides the essential context (when to use and what it does) but lacks details on error handling, polling, or what happens if the task isn't ready. It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does not describe the 'task_id' parameter beyond its existence, leaving the agent without format details, how to obtain it, or what values are valid. The reference to 'returns taskId' is context but does not define the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the result of a Doubao video generation task. It specifies the resource ('video generation task result') and the verb ('query'), distinguishing it from siblings like gpt_image_result or doubao_video_generate. The mention of the timeout condition adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: '仅在 doubao_video_generate 超时返回 taskId 后使用' (only use after doubao_video_generate times out and returns a taskId). This provides concrete guidance and implies that the tool should not be used in other scenarios, effectively differentiating it from similar result-query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '实时' (real-time) which indicates data freshness, but it does not disclose error handling, authentication needs, rate limits, or what happens if the opus_id is invalid. The description is too sparse to be transparent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose and one for the parameter definition. It is front-loaded with the core action and contains no redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema exists), the minimal description is largely sufficient. The real-time qualifier adds context. However, slightly more behavioral depth (e.g., data source guarantee) would enhance completeness.
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% schema description coverage, the description adds crucial meaning: 'opus_id 为作品 ID' (opus_id is the work ID). This clarifies the parameter's role beyond the schema's raw type 'string', significantly aiding correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取今日头条作品详情（实时）' which translates to 'Get Toutiao work details (real-time).' The verb 'get' and resource 'work details' are specific, and the platform name 'toutiao' distinguishes it from sibling tools for other platforms like douyin, wechat, etc. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an opus_id, but it does not explicitly state when to use this tool versus alternatives like 'toutiao_search_works'. No when-not-to-use or exclusion criteria are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It describes the search behavior and sort options but does not mention rate limits, authentication requirements, or what happens if the keyword is invalid (e.g., returns empty). It also doesn't state whether the tool modifies data or is read-only, though 'search' implies read-only. Given the 0% annotation coverage, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads the primary action and resource. The second sentence adds specific parameter options. However, the mix of Chinese and English might cause minor parsing issues for some agents, and the lack of a period after the first sentence could affect readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (handling return structure) and the tool is simple (3 params, no nested objects), the description is partially complete. It covers the search target and sort behavior but omits the 'offset' parameter explanation. For a simple search tool, it provides enough to invoke correctly for basic use, but lacks details on pagination and error handling.
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?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It adds meaning to 'keyword' (stated as required, but no detail on format/length) and 'sort_type' (explicitly lists options: default, newest, hottest). However, 'offset' is completely undocumented, and no additional context is given about pagination or result limits. Despite this gap, the description adds significant value beyond the bare schema for two of the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('搜索' = search) and resource ('公众号账号' = WeChat official accounts). It also specifies '优质库' (high-quality database), which distinguishes it from sibling tools like wechat_search_articles (which searches articles, not accounts). The sibling context includes multiple search tools across platforms, and this description clearly identifies its unique target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states that 'keyword' is required, which aligns with the input schema. It provides sort_type options but does not explicitly state when to use this tool versus alternatives like wechat_get_account (which fetches details of a specific account) or wechat_search_articles. There is no guidance on when NOT to use it, such as for searching by user ID or for article content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool automatically waits for completion, may return a taskId on timeout, and allows later retrieval via a separate result tool. This is useful behavioral context beyond what annotations (which are absent) would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (2 sentences) and front-loaded with the core purpose. Every sentence adds value and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown, but indicated), the description does not need to explain return values. It covers purpose, parameter roles, timeout behavior, and a retry mechanism, making it reasonably complete for this 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?
With 0% schema description coverage, the description compensates by explaining 'inquiry_text' (search query) and implying 'timeout_seconds' usage. It adds meaning beyond the bare schema, though it does not detail the range or format of the timeout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs an AI-powered search using '豆包联网' (Doubao) and returns results. It distinguishes itself from siblings like 'ai_search_kimi' and 'ai_search_deepseek' by branding, but does not differentiate its scope or behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for search queries and mentions timeout handling with a fallback to 'ai_search_doubao_result'. However, it does not explicitly state when to use this tool versus other search tools, nor does it specify prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates the tool is a query (read operation) but does not disclose what happens for invalid task_id, pending results, or error states. The behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an output schema (per context), the description adequately covers purpose and usage condition. It lacks details on expected polling behavior (e.g., should it be called repeatedly?) but is otherwise complete for a simple query 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 coverage is 0% and the description does not formally explain the 'task_id' parameter. However, the usage guideline implicitly ties it to the taskId from the generate tool. For a single-parameter tool, this indirect explanation is weak but functional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (查询/query) and resource (任务结果/task result) with the model identifier Seedream 5.0 Pro. It clearly distinguishes itself from sibling tools like doubao_image_lite_result and doubao_video_result by targeting a specific model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition for use: '仅在 doubao_image_pro_generate 超时返回 taskId 后使用' (only after the generate tool times out and returns a taskId). This gives clear context on when to use this tool versus the generate tool, though it does not cover polling behavior or alternative failure handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It mentions the '优质库' (high-quality library) constraint, which implies the tool only returns notes from a curated subset—important for setting agent expectations. It also states the parameter requirement. However, it does not disclose what happens if both ID and link are given, expected format of inputs, rate limits, or authentication needs, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core purpose and parameter requirement. Every word serves a function: it names the action, the target, the scope (优质库), and the essential constraint. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only two parameters (neither required in schema), an output schema is present (so return values need not be described), and the complexity is low, the description covers the essential invocation requirements. However, it leaves the term '优质库' undefined—a curious AI agent would not know what qualifies as 'high-quality' or how to interpret results from this library versus the full note set. This slight ambiguity prevents a perfect score.
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?
Schema description coverage is 0%, so the description must compensate. It does so by stating the critical constraint that at least one of work_id or work_link must be provided, which the schema alone does not convey (both are optional with null defaults). This adds significant meaning beyond the raw types. However, it omits details like the expected format of work_id or work_link (e.g., URL pattern), preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the resource '小红书笔记详情' (Xiaohongshu note details), with the qualifier '优质库' distinguishing it from general notes. The sibling tools include search and other get functions, and this description differentiates by specifying fetching a single note by ID or link, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key constraint: 'work_id 与 work_link 至少传一个', telling the agent that at least one parameter is required. However, it gives no guidance on when to use this tool versus alternatives like xiaohongshu_search_articles, nor does it mention when not to use it or what to do if both parameters are provided. Usage is implied but not explicitly contextualized among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It indicates that this tool polls for results of an asynchronous task, which is a read-like operation. However, it does not cover what happens if the task fails, is still running, or if the taskId is invalid. It also doesn't state whether results are returned immediately or can also be polled before timeout. With no annotations, a score of 3 is appropriate for the minimal but necessary 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each serving a distinct purpose: state what the tool does, then specify when to use it. There is no redundancy or unnecessary detail. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one parameter, no enums, no nested objects) and has an output schema (so return values need not be explained in description), the description is nearly complete. It covers purpose and usage condition perfectly. The only gap is not explaining what happens if the task isn't ready, but the implied workflow (wait for timeout, then poll) suggests the expected behavior. A score of 4 reflects this minor omission.
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 only one parameter (task_id) with 0% schema description coverage, so the baseline is lowered. The description does not explicitly explain the parameter, but the usage guideline implies task_id is the identifier returned by ai_search_kimi. This provides context beyond the bare schema, which just marks it as required string. However, adding a brief note like 'task_id: the task identifier returned by the search tool' would be ideal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: '查询 Kimi 搜索任务结果' (query Kimi search task results). It also specifies the connection to the sibling tool 'ai_search_kimi' and the condition for use (when it times out and returns a taskId). This distinguishes it from other result query tools like 'ai_search_doubao_result' and 'ai_search_deepseek_result' by naming the specific platform (Kimi).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: '仅在 ai_search_kimi 超时返回 taskId 后使用' (only use after ai_search_kimi times out and returns a taskId). This clearly states when to use this tool and implies when not to (before the task completes or if no timeout). It effectively distinguishes a specific workflow from alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the basic functional behavior (get details) and parameter constraints, but does not disclose any potential side effects, authentication requirements, or error handling. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. It is front-loaded with the purpose and immediately provides the critical usage constraint. Every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, output schema exists), the description is complete enough. It covers the purpose, parameter constraints, and format. It does not explain the output structure, but the output schema handles that. It implicitly distinguishes from sibling tools by the name and context, but could be more explicit.
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?
Schema description coverage is 0% (low), so the description must compensate. It explains both parameters: bvid and work_url, the constraint that at least one is required, and the format of work_url (bilibili.com/video/BVxxx or b23.tv short links). This adds significant meaning beyond the schema, which only specifies types and nullability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取 B 站视频详情' (get Bilibili video details). It specifies the resource (single video) and distinguishes from sibling tools like bilibili_get_user_works or bilibili_search_articles by focusing on a single video identified by bvid or URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: at least one of bvid or work_url must be provided, and it explains the supported formats for work_url. However, it does not explicitly state when to use this tool versus alternatives (e.g., bilibili_get_user_works for multiple videos), though the context of sibling tools partially implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool is a follow-up poll operation for retrieving asynchronous results. It implies a dependency on the 'taskId' from a prior call, which is critical. However, it does not detail what happens if the task is still pending (e.g., should retry?) or if the task fails, but the use-case is sufficiently narrow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff. The crucial usage condition is front-loaded, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema (present but not shown in detail). The description covers the core usage pattern (follow-up after timeout). It misses potential edge cases like what to do if the task is still running or error handling, but for a simple result-fetching tool with one parameter, this is reasonably complete.
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?
Schema description coverage is 0% (no descriptions for the 'task_id' parameter in the schema), so the description must compensate. The description clarifies that 'task_id' comes from a timeout of 'ai_search_doubao', adding essential context. It doesn't describe format or constraints, but the single required parameter is well-explained in the description's usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the result of a Doubao search task. The verb '查询' (query) and resource '豆包搜索任务结果' are specific. However, it doesn't explicitly distinguish from sibling results tools like 'ai_search_kimi_result' or 'ai_search_deepseek_result', though the name difference implies a distinct AI provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: only after 'ai_search_doubao' times out and returns a 'taskId'. This provides clear context and an implied alternative (use 'ai_search_doubao' first), making it excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
在没有注释的情况下，描述承担了行为透明度的全部责任。它准确说明了这是一个查询操作而非生成操作，并指明返回内容包含可能出现的失败原因（failReason），但未明确说明查询是否是幂等的或可能多次调用产生的影响（如是否消耗配额），因此扣1分。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述非常简洁，仅两句话，第一句说明功能，第二句给出使用条件，无冗余内容。但第二句使用了中文句号，结构合理，信息密度高，完全符合前端加载原则。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
考虑到工具只有一个参数，且有输出模式，描述完整覆盖了使用场景和返回的关键字段（status/imagePaths/failReason），无需额外补充，对于其复杂度来说非常完整。
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?
参数描述覆盖率为0%，描述承担了完全责任。它提到了taskId的上下文（来自gpt_image_generate超时后返回），但未在描述中显式说明task_id参数的具体格式或限制（如字符串长度）。由于只有一个参数且上下文已暗示，额外信息需求不高，但仍有微小提升空间。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述清晰地声明了工具用于查询GPT图片生成任务的结果，并明确列出了返回内容（status/imagePaths/failReason），动词“查询”和资源“GPT图片生成任务结果”非常具体，且与同类工具（如doubao_image_pro_result）有区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确给出了使用条件：仅在gpt_image_generate超时返回taskId后使用。这直接告诉代理何时应该使用此工具，以及避免在任务未超时或没有taskId时调用，提供了清晰的上下文和排除条件。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，但描述自解释为查询结果，隐含非破坏性只读操作，无矛盾之处，且对于此类简单结果轮询工具已足够。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
单句描述，信息密度高，无冗余，直接传达核心使用场景，符合简洁要求。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
有输出 schema，无需详细说明返回内容；1个参数，描述与使用前提已完全覆盖所需信息，对于异步轮询场景足够完整。
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?
虽然 schema 中 task_id 无描述，但上下文表明其来源为 ai_search_deepseek 超时返回的 ID，描述间接提供了含义。由于只有一个必填参数且 schema 覆盖率为 0%，描述起到了良好补充作用，但未显式说明参数格式或取值范围。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
明确说明查询 Deepseek 搜索任务结果，是结果查询工具，与发起任务的 ai_search_deepseek 形成配对，区分于其他平台的结果查询工具如 ai_search_kimi_result。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
直接说明仅在前置工具 ai_search_deepseek 超时返回 taskId 后使用，给出了明确的使用前提条件，避免误用。
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:

[![redfox-mcp MCP server](https://glama.ai/mcp/servers/redfox-data/redfox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/redfox-data/redfox-mcp)

Score Badge

Copy to your README.md:

[![redfox-mcp MCP server](https://glama.ai/mcp/servers/redfox-data/redfox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/redfox-data/redfox-mcp)

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/redfox-data/redfox-mcp'

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