Tencent Cloud COS MCP Server

Official

by Tencent

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as getBucket for listing files, putObject for uploading, and aiPicMatting for image matting. However, some overlap exists between imageSearchPic and imageSearchText, both involving image retrieval, which could cause minor confusion. Overall, the descriptions clarify boundaries well.
Naming Consistency3/5
The naming is mixed with camelCase (e.g., aiPicMatting) and snake_case (e.g., get_object_url), lacking a uniform pattern. While verbs like 'create', 'describe', 'get', and 'put' are used consistently, the inconsistency in case styles reduces predictability. It remains readable but not fully standardized.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a cloud storage and processing server. It covers file operations, image processing, and media tasks without feeling overly bloated. The scope justifies most tools, though it borders on being heavy.
Completeness4/5
The server provides good coverage for COS operations, including CRUD-like actions (get, put) and advanced processing (image, media, document tasks). Minor gaps exist, such as no direct update or delete tools for objects, but agents can work around this using upload/overwrite or other methods. The surface is largely complete for the domain.
Average 2.7/5 across 18 of 18 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description '图片处理-抠图' gives no information about what the tool actually does behaviorally - whether it modifies images, returns processed results, requires authentication, has rate limits, or what format the output takes. It's completely inadequate for understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two Chinese characters and a dash, this is under-specification rather than effective conciseness. The description fails to communicate essential information about the tool's purpose and usage. Every sentence should earn its place, but here the single phrase fails to provide meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a tool with 3 parameters, no annotations, and no output schema, the description '图片处理-抠图' is completely inadequate. It doesn't explain what the tool returns, how it processes images, what 'matting' means in this context, or any behavioral characteristics. For a potentially complex image processing tool, this minimal description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (objectKey, height, width) having descriptions in Chinese. The tool description adds no additional parameter information beyond what's already in the schema. With complete schema coverage, the baseline score of 3 is appropriate since the schema does the documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '图片处理-抠图' translates to 'Image processing - matting' which restates the tool name 'aiPicMatting' (AI picture matting) in slightly different words. It's a tautology that doesn't specify what the tool actually does beyond the name. No specific verb or resource distinction from siblings is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison to sibling tools like aiQrcode, aiSuperResolution, or other image processing tools. The agent receives zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a read or write operation, what permissions might be required, whether it's asynchronous (suggested by 'Job' in the name), what happens on success/failure, or any rate limits or side effects. The description provides zero behavioral context beyond the basic action implied by 'create'.
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 - a single Chinese phrase. While this could be seen as efficient, it's arguably under-specified rather than appropriately concise. However, given that it's a single phrase with no wasted words and gets straight to the point (albeit minimally), it earns a relatively high score for conciseness despite its substantive deficiencies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'SmartCoverJob' and the complete absence of annotations and output schema, the description is woefully incomplete. It doesn't explain what a 'media smart cover' is, what the job does, what inputs are needed beyond the schema, what the expected output or result looks like, or any behavioral characteristics. For a job creation tool with no structured metadata, this description provides inadequate 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?
The input schema has 100% description coverage with a clear parameter description for 'objectKey' ('对象在存储桶里的路径'). The description adds no parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建媒体智能封面任务' is a tautology that essentially restates the tool name 'createMediaSmartCoverJob' in Chinese. It provides no additional specificity about what 'media smart cover' means, what resource is being acted upon, or what the actual outcome of this 'creation' entails. While it does contain a verb ('创建') and a noun phrase ('媒体智能封面任务'), it lacks meaningful differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or what distinguishes it from sibling tools like 'createDocToPdfJob', 'describeMediaJob', or other media processing tools. There's no indication of when this tool is the correct choice versus when other tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It states '图片处理-超分辨率', implying a processing operation that likely modifies or enhances images, but doesn't specify if it's read-only, destructive, requires authentication, has rate limits, or what the output entails (e.g., returns a processed image URL). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with just two words ('图片处理-超分辨率'), which is efficient and front-loaded. However, it's arguably too brief, bordering on under-specified, as it lacks necessary details for clarity. Every word earns its place, but more context would improve usefulness without sacrificing 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's complexity (image processing with potential side effects), no annotations, no output schema, and minimal description, the description is incomplete. It doesn't explain what the tool returns, how it behaves, or when to use it, making it inadequate for an AI agent to invoke correctly. More information is needed to compensate for the lack of structured data.
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 1 parameter with 100% description coverage ('图片在存储桶里的路径' meaning 'path of the image in the storage bucket'), so the schema fully documents the parameter. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '图片处理-超分辨率' translates to 'image processing - super resolution', which indicates the general purpose of enhancing image resolution. However, it's vague about the specific action (e.g., 'apply', 'generate', 'enhance') and doesn't differentiate from sibling tools like 'assessQuality' or 'waterMarkFont', which are also image-related. It avoids tautology but lacks 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., for low-resolution images), or exclusions (e.g., not for text processing). With sibling tools like 'assessQuality' and 'imageInfo', there's no indication of how this tool fits into the workflow, leaving usage unclear.
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 but adds minimal behavioral context. It implies a read-only analysis (assessing quality) but doesn't disclose critical traits: whether it modifies the image, requires specific permissions, has rate limits, returns structured scores or simple ratings, or handles errors. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 a brief phrase. It's front-loaded with the core function but lacks elaboration. While efficient, it may be overly terse for a tool that likely returns complex quality metrics, risking under-specification rather than true 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's complexity (quality assessment often involves multiple metrics) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'quality' means, what the output contains (e.g., scores, recommendations), or any limitations (e.g., supported image types). For a tool with no structured output documentation, this leaves the agent guessing about results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'objectKey' clearly documented as '图片在存储桶里的路径' (path of the image in the storage bucket). The description adds no additional meaning beyond this, such as format examples or constraints. Since the schema fully describes the single parameter, the baseline score of 3 is appropriate—adequate but no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '图片处理-图片质量评估' (Image processing - image quality assessment) states a general purpose but lacks specificity. It mentions the domain (image processing) and function (quality assessment) but doesn't specify what kind of quality is assessed (e.g., technical metrics, aesthetic scores) or what the output represents. It doesn't clearly distinguish from siblings like 'imageInfo' which might provide similar metadata.
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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., image format requirements), use cases (e.g., evaluating uploads, filtering content), or comparisons to siblings like 'imageInfo' (which might give basic info) or 'aiSuperResolution' (which enhances quality). The agent must infer usage from the name alone.
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 states '创建' (create), implying a write/mutation operation, but doesn't disclose behavioral traits such as permissions needed, whether it's asynchronous, rate limits, or what happens on failure. This is a significant gap for a tool that likely initiates a processing job without output schema details.
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, efficient sentence in Chinese that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more informative. No wasted text, but it borders on under-specification.
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 complexity of creating a processing job with no annotations and no output schema, the description is incomplete. It doesn't explain what the job entails, expected outcomes, error handling, or how to monitor results (e.g., using 'describeDocProcessJob'). For a mutation tool with minimal structured data, more context is needed to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage ('对象在存储桶里的路径'), so the schema already documents the parameter well. The description adds no additional meaning beyond what the schema provides, such as explaining the objectKey format or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建文档转 pdf 处理任务' clearly states the action (create) and resource (document-to-PDF processing job), which is better than a tautology. However, it doesn't differentiate from siblings like 'createMediaSmartCoverJob' or explain what type of document conversion this handles versus other tools. The purpose is understandable but lacks specificity about scope or differentiation.
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. It doesn't mention prerequisites (e.g., needing an object in storage), exclusions, or comparisons to sibling tools like 'describeDocProcessJob' for checking job status. Usage is implied from the name but not explicitly stated, leaving gaps for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'get image information' but doesn't disclose behavioral traits such as whether this is a read-only operation, requires specific permissions, has rate limits, or what the output format might be. The description is minimal and lacks essential context for safe and effective use.
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 a single phrase. It's front-loaded but potentially under-specified. While efficient, it might benefit from slightly more detail to improve clarity without becoming verbose.
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 no annotations, no output schema, and a minimal description, the description is incomplete. It doesn't explain what 'image information' entails, how results are returned, or any behavioral aspects. For a tool with 1 parameter and no structured context, more detail is needed to guide 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 input schema has 1 parameter with 100% description coverage ('图片在存储桶里的路径' - path of the image in the storage bucket). The description adds no additional meaning beyond the schema, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '图片处理-获取图片信息' (Image processing - get image information) states a general purpose but lacks specificity. It mentions 'get image information' but doesn't specify what information (e.g., metadata, dimensions, format) or distinguish it from sibling tools like 'getObject' or 'assessQuality'. The purpose is clear but vague.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and there's no comparison to sibling tools like 'getObject' (which might retrieve raw image data) or 'assessQuality' (which might analyze image quality). Usage is implied but not explicit.
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 of behavioral disclosure. While it indicates the tool generates watermarked images (implying a write/mutation operation), it doesn't specify whether this modifies the original image, creates a new file, requires authentication, has rate limits, or what the output format/behavior is. For a tool with no annotations, this leaves significant gaps in understanding its effects.
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 (one sentence: '生成带文字水印的图片') and front-loaded with the core purpose. There's no wasted language or unnecessary elaboration, making it efficient for quick understanding.
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's complexity (image processing with mutation), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens to the original image, where the output is stored, error conditions, or any behavioral constraints. For a tool that likely modifies or creates files, more context is needed for safe and 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 schema description coverage is 100%, with both parameters ('objectKey' and 'text') clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how the watermark is applied, font/size options, or positioning). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '生成带文字水印的图片' (Generate images with text watermarks) clearly states the tool's purpose with a specific verb ('生成' - generate) and resource ('图片' - images). However, it doesn't distinguish this tool from potential sibling tools that might also manipulate images, though none of the listed siblings appear to be direct alternatives for watermarking.
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. There's no mention of prerequisites, limitations, or comparison with other tools in the server (like 'putObject' for uploading or 'imageInfo' for analysis). The agent must infer usage context solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('get') without describing what the tool returns, whether it requires authentication, rate limits, or error conditions. For a tool with zero annotation coverage, this is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with just two phrases ('获取COS配置, 腾讯云配置'). It's front-loaded with the core purpose. While efficient, it could be slightly more informative without losing 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 no annotations and no output schema, the description is incomplete. It doesn't explain what configuration data is returned, the format of the response, or any behavioral aspects. For a configuration retrieval tool, this leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters. Baseline 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取COS配置, 腾讯云配置' states the purpose (get COS configuration, Tencent Cloud configuration) but is vague about what specific configuration is retrieved. It distinguishes from siblings by focusing on COS configuration rather than operations like getObject or putObject, but lacks specificity about what configuration data is returned.
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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for usage, or comparison with sibling tools like getBucket or getObject. It simply states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the query action without mentioning whether this is a read-only operation, what permissions might be required, what happens if the job ID doesn't exist, or what format the results will be in. For a query tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence in Chinese that directly states the tool's purpose without any unnecessary words or elaboration. Every word serves a clear purpose in conveying the core functionality.
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?
For a query tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information the query returns (status, progress, output location, error details), what happens for invalid/nonexistent job IDs, or any rate limits or authentication requirements. The context signals indicate this is a simple tool, but the description leaves too many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'jobId' well-documented in the schema itself. The description adds minimal value beyond what's already in the schema - it mentions job IDs come from document task submissions, but this is essentially restating the schema's description. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('查询' - query) and resource ('文档转码任务结果' - document transcoding job result), specifying what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'describeMediaJob' which might have similar query functionality for different resource types.
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. While it mentions job IDs come from '提交文档任务的响应' (responses from submitting document tasks), it doesn't specify when to query versus when to use other tools like 'createDocToPdfJob' or how this differs from 'describeMediaJob' for media-related queries.
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 states 'download' which implies a read operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the file doesn't exist. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose. It's front-loaded with no wasted words, making it highly concise and well-structured.
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 no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., file content, metadata), error handling, or usage context, leaving significant gaps 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 100%, with the parameter 'objectKey' documented as '文件的路径' (file path). The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '下载存储桶内的文件' clearly states the action (download) and target (file in bucket). It distinguishes from siblings like 'getBucket' (list bucket) and 'putObject' (upload), but doesn't explicitly differentiate from 'getObjectUrl' which might return a URL instead of the file content.
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 'getObjectUrl' or 'putObject'. The description implies it's for downloading files, but doesn't specify prerequisites (e.g., file must exist) or compare with sibling 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 the full burden of behavioral disclosure. While it mentions '带签名的' (signed), implying authentication or security aspects, it doesn't elaborate on what this entails (e.g., expiration time, permissions required, or rate limits). For a tool that likely involves sensitive operations (generating signed URLs), this lack of detail is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every part of the sentence contributes essential information, earning its place.
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 complexity (generating signed URLs for file access) and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, URL expiration, or error conditions, nor does it explain the return value (e.g., the structure of the signed URL). For a tool with no structured safety or output information, this leaves critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'objectKey' clearly documented as '文件的路径' (file path). The description adds no additional meaning beyond this, as it doesn't explain path formats, constraints, or examples. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra value from the description.
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 action ('获取带签名的下载链接' - get signed download URL) and the resource ('存储桶内的文件' - file in storage bucket), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'getObject' which might retrieve the file itself rather than just a URL, so it misses full sibling differentiation.
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. There's no mention of prerequisites (e.g., needing authentication or bucket access), comparison to sibling tools like 'getObject' (which might fetch the actual file), or scenarios where a signed URL is preferred over direct access. This leaves the agent with insufficient context for appropriate tool selection.
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 retrieval from a dataset but doesn't disclose behavioral traits such as rate limits, authentication needs, what 'similar' means (e.g., visual similarity, semantic similarity), or response format. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, with every part contributing to understanding the purpose, making it highly concise and well-structured.
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's complexity (image similarity search), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the dataset contains, how similarity is measured, or what the return values are (e.g., list of images, scores). For a retrieval tool with no structured output, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (parameter 'uri' is described as '图片地址' - image address), so the baseline is 3. The description adds no additional meaning beyond the schema, such as format requirements (e.g., supported image types, URI protocols) or constraints (e.g., size limits). It relies entirely on the schema for parameter documentation.
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: '根据输入的图片，从数据集中检索出与输入的图片内容相似的图片' (Retrieve images similar to the input image from a dataset). It specifies the verb '检索出' (retrieve) and resource '图片' (images), but doesn't differentiate from its sibling 'imageSearchText', which performs text-based image search. This makes it clear but not fully sibling-distinct.
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 like 'imageSearchText' (text-based image search) or other image-related tools (e.g., 'aiPicMatting', 'assessQuality'). It implies usage for image similarity retrieval but lacks explicit when/when-not instructions or prerequisites, leaving the agent to infer context.
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 states this is a retrieval/search operation but doesn't disclose important behavioral traits: whether this is read-only or has side effects, what dataset is being searched, authentication requirements, rate limits, pagination behavior, or what happens when no matches are found. The description is minimal and lacks operational 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?
Extremely concise single sentence that directly states the tool's function. No wasted words or unnecessary elaboration. The description is appropriately sized for a simple search 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?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of dataset is being searched, the format of returned images, error conditions, or limitations. Given the complexity of image search and lack of structured metadata, more context is needed for effective agent 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?
Schema description coverage is 100% with one parameter 'text' described as '检索的文本' (search text). The description adds minimal value beyond the schema, only reinforcing that the input is '文本内容' (text content). With high schema coverage, the baseline is 3 even without additional parameter semantics in the description.
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: '从数据集中检索出与输入的文本内容相符的图片' (retrieve images matching input text from a dataset). It specifies the verb '检索' (retrieve/search) and resource '图片' (images), but doesn't distinguish it from sibling 'imageSearchPic' which appears to be a similar image search tool with different input type.
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. The description doesn't mention when this tool is appropriate versus 'imageSearchPic' or other search/retrieval tools in the sibling list. It provides only the basic functionality without context about appropriate 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the upload action but doesn't mention permissions needed, rate limits, whether the operation is idempotent, what happens on conflicts (e.g., overwriting existing files), or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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?
For a file upload tool with no annotations and no output schema, the description is incomplete. It lacks information about return values (e.g., success confirmation, error details), behavioral traits like overwrite behavior or permissions, and differentiation from sibling tools. This leaves significant gaps for an AI agent to use it 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?
Schema description coverage is 100%, so the schema already documents all three parameters well. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify relationships between fileName, filePath, and targetDir). Baseline 3 is appropriate when the schema does the heavy lifting.
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 action (upload) and target (local file to storage bucket). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'putObjectSourceUrl' which likely uploads from a URL instead of a local file.
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. It doesn't mention sibling tools like 'putObjectSourceUrl' (for URL-based uploads) or 'getObject' (for downloads), nor does it specify prerequisites or contexts for use.
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 downloading from a URL and uploading to a bucket, implying a write/mutation operation, but doesn't disclose behavioral traits such as required permissions, rate limits, error handling, or what happens if the file already exists. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: '通过 url下载文件并将文件上传到存储桶'. It's front-loaded with the core action and has no wasted words, making it highly concise and well-structured.
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's complexity (involving download and upload operations), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, error cases, or return values, leaving gaps that could hinder an agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 100%, with clear descriptions for 'fileName', 'sourceUrl', and 'targetDir'. The description doesn't explain parameter interactions, formats, or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
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: '通过 url下载文件并将文件上传到存储桶' (download a file via URL and upload it to a storage bucket). It specifies the verb (download and upload) and resource (file to storage bucket). However, it doesn't explicitly differentiate from sibling tools like 'putObject' (which likely uploads from local source), making it clear but not fully sibling-distinctive.
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. It doesn't mention sibling tools like 'putObject' or 'getObjectUrl', nor does it specify prerequisites, exclusions, or contexts for usage. This leaves the agent with no explicit usage instructions.
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 states the tool performs QR code recognition on images in a storage bucket, implying a read-only operation, but doesn't disclose behavioral traits such as error handling (e.g., what happens if the image isn't a QR code), performance characteristics (e.g., processing time), or output format (since no output schema exists). This leaves significant gaps for an AI agent.
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, efficient sentence in Chinese: '图片处理-二维码识别-识别存储桶内二维码图片内容'. It is front-loaded with the core purpose and has zero wasted words, making it highly concise and well-structured for quick understanding.
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's complexity (image processing with one parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., decoded text, error messages), behavioral details, or usage context. While concise, it fails to provide sufficient information for an AI agent to fully understand how to invoke and interpret results from 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?
The description doesn't explicitly mention parameters, but with 100% schema description coverage (the single parameter 'objectKey' is well-documented in the schema as 'COS对象键（完整路径）示例: images/qrcode.jpg'), the baseline is 3. The description adds value by clarifying the resource context ('识别存储桶内二维码图片内容' - recognize QR code image content in storage bucket), which implicitly relates to the objectKey parameter, elevating the score slightly.
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: '图片处理-二维码识别-识别存储桶内二维码图片内容' (Image processing - QR code recognition - recognize QR code image content in storage bucket). It specifies the verb (recognize), resource (QR code images), and scope (in storage bucket). However, it doesn't explicitly differentiate from sibling tools like 'imageInfo' or 'imageSearchPic' that might also process images.
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. It doesn't mention prerequisites (e.g., needing a valid object key), exclusions (e.g., non-QR code images), or comparisons to sibling tools like 'imageInfo' (which might provide general image metadata) or 'imageSearchPic' (which might search images). The scope is implied ('in storage bucket') but not explicitly contrasted.
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 for behavioral disclosure. While '查询' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what happens with large buckets. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient Chinese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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 simple list operation with one documented parameter and no output schema, the description is minimally adequate. However, with no annotations and siblings that overlap in functionality, it should provide more context about when this specific list operation is needed versus other bucket access tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'Prefix' parameter completely. The description doesn't add any parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter semantics.
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 '查询' (query) and resource '存储桶内的文件列表' (file list in storage bucket), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getObject' or 'getObjectUrl' which also retrieve bucket-related information, preventing a perfect score.
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. With siblings like 'getObject' (retrieve specific file) and 'getObjectUrl' (get file URL), there's no indication of when this list operation is preferred over those individual file operations.
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 states it queries results but doesn't disclose behavioral traits like whether it's read-only (implied but not stated), potential errors (e.g., invalid job IDs), rate limits, authentication needs, or what the output contains (e.g., status, cover image URL). For a query tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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, efficient sentence in Chinese that directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding the tool's function.
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 no annotations and no output schema, the description is incomplete for a tool that queries job results. It doesn't explain what the return values include (e.g., success/failure, cover image details, error messages), which is critical for an agent to use it correctly. The schema covers the input well, but overall context is lacking for effective tool 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 description coverage is 100%, with the parameter 'jobId' fully documented in the schema as '要查询的任务ID，可通过提交智能封面任务的响应中获取' (task ID to query, obtainable from submitting smart cover tasks). The description adds no additional meaning beyond this, as it essentially repeats the same information. Baseline is 3 when schema does the heavy lifting.
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 ('查询' - query) and resource ('媒体智能封面任务结果' - media smart cover job results) with a specific identifier ('根据 jobid' - based on job ID). It distinguishes from siblings like 'createMediaSmartCoverJob' (which creates jobs) and 'describeDocProcessJob' (which queries document jobs). However, it doesn't explicitly mention it's for retrieving results rather than status, which could be slightly 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning job IDs come from '提交智能封面任务的响应中获取' (obtained from submitting smart cover tasks), suggesting it should be used after job creation. However, it doesn't explicitly state when to use this vs. alternatives like checking job status through other means or when not to use it (e.g., for non-media jobs). No explicit alternatives are named.
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:

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

Score Badge

Copy to your README.md:

[![cos-mcp MCP server](https://glama.ai/mcp/servers/Tencent/cos-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Tencent/cos-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/Tencent/cos-mcp'

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