TOS MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific TOS operations like bucket management, object handling, media processing, and URL generation. There is no overlap or ambiguity between tools, as each name precisely indicates its function (e.g., tos_list_buckets vs. tos_list_objects, tos_image_info vs. tos_video_info).
Naming Consistency5/5
All tools follow a consistent 'tos_verb_noun' pattern with snake_case throughout, such as tos_create_bucket, tos_get_object, and tos_image_process. This predictable naming convention makes it easy for agents to understand and select the appropriate tool without confusion.
Tool Count5/5
With 13 tools, the set is well-scoped for a TOS (object storage) server, covering essential operations like CRUD for buckets and objects, listing, metadata retrieval, media processing, and URL generation. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness5/5
The tool surface provides complete coverage for TOS operations, including full CRUD for buckets and objects, lifecycle management (e.g., delete, list), media-specific functions (image/video info and processing), and utility features like presigned URLs. There are no obvious gaps that would hinder agent workflows in this domain.
Average 2.7/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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 carries full burden. It implies a generation action but doesn't disclose behavioral traits like whether this requires authentication, what permissions are needed, if the URL is time-limited (only hinted by 'expires' parameter), or what the output format is. It's minimal and leaves critical behavior unspecified.
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 a single phrase, '生成预签名 URL', which is front-loaded and wastes no words. It's appropriately sized for the minimal information it conveys, though this conciseness contributes to low scores in other dimensions due to 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 tool's complexity (generating URLs with authentication implications), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a URL string), error conditions, or security considerations, leaving significant gaps for an AI agent to understand and 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 parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters (e.g., method choice affects URL usage) or practical examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 '生成预签名 URL' (Generate presigned URL) states the basic action but is vague. It doesn't specify what resource it operates on (TOS objects), what the URL is for (temporary access), or how it differs from siblings like tos_get_object. It's better than a tautology but lacks specificity and 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention use cases like sharing temporary access, bypassing direct authentication, or when to choose this over tos_get_object for downloading. There's no context about 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 carries the full burden of behavioral disclosure. It only states the action ('获取图片信息') without revealing whether this is a read-only operation, if it requires specific permissions, rate limits, error conditions, or what format the information is returned in. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase ('获取图片信息'), which is front-loaded and wastes no words. However, it might be overly terse given the lack of additional context needed for clarity and guidelines, slightly reducing its effectiveness despite efficient wording.
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 interacting with a storage system (TOS), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'image information' includes (e.g., metadata, dimensions, format), potential errors, or how it differs from general object retrieval. For a tool in this context, more detail is needed to be fully helpful.
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 clear Chinese descriptions for 'bucket_name' and 'object_key'. The description doesn't add any meaning beyond what the schema provides, such as explaining how these parameters relate to image retrieval or providing examples. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 '获取图片信息' (Get image information) states a clear verb+resource combination, indicating this tool retrieves metadata about images. However, it doesn't distinguish itself from sibling tools like 'tos_get_object' (which might retrieve general object data) or 'tos_image_process' (which processes images), leaving ambiguity about what specific 'image information' means compared to general object retrieval.
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 bucket and object key), exclusions (e.g., not for videos), or comparisons to siblings like 'tos_get_object' for non-image objects or 'tos_video_info' for videos. Usage is implied but not explicitly stated.
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. The description mentions '组合操作' (combined operations) which suggests multiple processing steps, but doesn't disclose whether this creates new files, modifies existing ones, requires specific permissions, has rate limits, or what the output looks like. For a tool with 5 required parameters and no annotations, this is a significant gap in behavioral information.
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 with just one Chinese phrase containing 11 characters. It's front-loaded with the core purpose. However, this brevity comes at the cost of completeness - while technically concise, it may be under-specified for a tool with 5 required parameters and no annotations.
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 5 required parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool actually produces (a new processed image file? a modified original?), doesn't mention error conditions, and doesn't provide context about the processing operations beyond what's in the parameter schema. For an image processing tool with multiple parameters, this leaves significant 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%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema - it mentions '支持多种处理参数' (supports multiple processing parameters) which aligns with the 'process' parameter documentation, but doesn't provide additional semantic context about parameter interactions or usage patterns. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '图片处理（组合操作，支持多种处理参数）' which translates to 'Image processing (combined operations, supports multiple processing parameters)'. This indicates the tool processes images with combined operations, but it's vague about the specific action - it doesn't specify whether it transforms, modifies, or creates new images. It doesn't clearly distinguish from sibling tools like 'tos_image_info' (which presumably reads image metadata) or 'tos_video_snapshot' (which extracts video frames).
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 any prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'tos_image_info' (for metadata) or 'tos_put_object' (for uploading). There's no indication of whether this tool is for batch processing, real-time transformation, or specific 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 carries full burden for behavioral disclosure. It only states the action ('list') without mentioning pagination behavior (implied by 'max_keys'), rate limits, authentication needs, or what 'TOS objects' entails (e.g., files, metadata). This is inadequate for a tool with multiple parameters and no output schema.
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 with no wasted words. However, it's overly concise to the point of under-specification, lacking necessary context for effective use, which slightly reduces its score from perfect.
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 (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances like pagination. For a list operation in a storage system, 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?
Schema description coverage is 100%, so the schema fully documents all parameters (bucket_name, delimiter, max_keys, prefix). The description adds no additional meaning beyond what's in the schema, such as explaining how 'delimiter' affects listing or the purpose of 'prefix'. Baseline 3 is appropriate as the schema handles parameter documentation.
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 '列举 TOS 对象' (List TOS objects) states a clear verb ('list') and resource ('TOS objects'), but it's vague about scope and doesn't distinguish from siblings like 'tos_list_buckets'. It doesn't specify whether this lists objects within a bucket or across all buckets, leaving 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a bucket), exclusions, or how it differs from sibling tools like 'tos_list_buckets' or 'tos_get_object', leaving the agent to infer usage from context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('获取视频信息') without detailing traits like whether it's read-only (implied but not explicit), what permissions are needed, rate limits, error handling, or the format of returned information. This is inadequate for a tool with parameters and no output schema.
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 phrase ('获取视频信息'), which is appropriately concise and front-loaded with the core action. However, it's overly brief, bordering on under-specification, as it lacks necessary details for a tool with parameters and no output schema, slightly reducing its effectiveness.
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 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what video information is returned (e.g., metadata, duration, format), how errors are handled, or any behavioral context. This leaves significant gaps 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 schema description coverage is 100%, with clear descriptions for 'bucket_name' and 'object_key' in the input schema. The description adds no additional meaning beyond the schema, such as explaining how these parameters relate to video retrieval or any constraints. Since the schema does the heavy lifting, 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 '获取视频信息' (Get video information) states a clear verb ('获取' - get) and resource ('视频信息' - video information), but it's vague about what specific information is retrieved. It doesn't distinguish this tool from sibling tools like 'tos_image_info' or 'tos_get_object', which suggests similar information retrieval for different resources.
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 bucket and object key), exclusions, or comparisons to sibling tools like 'tos_get_object' (which might handle general objects) or 'tos_video_snapshot' (which might extract frames). This leaves the agent without context for 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 the full burden of behavioral disclosure. While it mentions 'supports persistence' (implying the captured frame can be saved), it doesn't describe what happens during execution (e.g., whether it overwrites existing files, requires specific permissions, has rate limits, or returns any output). This is inadequate for a tool with 6 parameters and no output schema.
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 (one phrase) and front-loaded with the core functionality. There's no wasted text, but it may be too brief given the tool's complexity. Every word earns its place, though more detail would improve completeness.
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 (6 parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or behavioral aspects like whether it's idempotent. The high schema coverage helps, but the description alone is insufficient 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 all parameters clearly documented in the input schema. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain relationships between parameters like 'bucket_name' and 'save_bucket'). 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 'Video frame capture (supports persistence)', which clearly states the core function (capturing frames from videos) and mentions persistence capability. However, it doesn't specify what resource it operates on (video objects in storage) or differentiate it from sibling tools like 'tos_video_info' or 'tos_image_process'.
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 when this tool is appropriate compared to other video or image processing tools in the sibling list, nor does it specify prerequisites or exclusions for its 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('create') but doesn't cover critical aspects like permissions required, whether creation is idempotent, error conditions (e.g., duplicate bucket names), or what happens on success (e.g., returns a bucket ID or confirmation). This is a significant gap for a mutation 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 a single, efficient sentence ('创建 TOS 存储桶') that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 a creation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'TOS' refers to, the result of the operation (e.g., success response or error handling), or behavioral traits like rate limits. For a tool that modifies state, this leaves critical 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 clear descriptions for both parameters (e.g., 'bucket_name' as bucket name, 'acl' as access control permission with enum values). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high coverage without extra value.
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 '创建 TOS 存储桶' (Create TOS bucket) states the basic action and resource, making the purpose understandable. However, it doesn't differentiate from sibling tools like 'tos_list_buckets' or 'tos_delete_bucket' beyond the verb, and the term 'TOS' might be ambiguous without context. It's clear but generic.
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., needing a unique bucket name), exclusions, or comparisons to siblings like 'tos_list_buckets' for viewing existing buckets. Usage is implied by the verb 'create' but lacks explicit 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 the full burden of behavioral disclosure. While '删除' (delete) implies a destructive mutation, the description fails to specify critical behaviors: whether deletion is permanent, if it requires specific permissions, what happens on success/failure, or any rate limits. This leaves significant gaps for a tool that performs irreversible actions.
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—a single phrase—with zero wasted words. It is front-loaded and directly states the action, making it efficient for quick understanding. This brevity is appropriate given the tool's straightforward purpose, though it sacrifices detail for 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 (a destructive operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It does not explain the deletion process, error handling, or return values, leaving users unsure of outcomes. For a mutation tool in a storage context, more context is needed to ensure safe and correct 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?
The input schema has 100% description coverage, with clear Chinese descriptions for 'bucket_name' and 'object_key'. The description adds no additional parameter semantics beyond the schema, such as format examples or constraints. However, since the schema is well-documented, a baseline score of 3 is appropriate, as the description does not compensate but also does not 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 '删除 TOS 对象' (Delete TOS object) states a clear verb ('delete') and resource ('TOS object'), which is better than a tautology. However, it lacks specificity about what a 'TOS object' is (e.g., a file in a cloud storage bucket) and does not distinguish this tool from sibling tools like 'tos_delete_bucket' or 'tos_put_object', leaving ambiguity about the exact scope of deletion.
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 does not mention prerequisites (e.g., the object must exist), exclusions (e.g., cannot delete non-empty buckets), or related tools like 'tos_delete_bucket' for bucket-level operations. Without such context, users might misuse it or struggle to choose between 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. It states the action ('获取' - get) but does not describe traits such as read-only nature (implied by 'get'), authentication requirements, rate limits, error conditions (e.g., if bucket doesn't exist), or response format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('获取存储桶元数据') that is highly concise and front-loaded, with no wasted words. It efficiently conveys the core purpose without unnecessary elaboration, earning a top score for brevity and clarity in structure.
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 (a read operation with one parameter) and lack of annotations and output schema, the description is incomplete. It fails to explain what metadata is returned, error handling, or behavioral context, making it inadequate for an agent to fully understand the tool's operation beyond its basic purpose.
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 'bucket_name' documented as '存储桶名称' (bucket name). The description does not add any meaning beyond this, such as format constraints (e.g., naming rules) or examples. Since the schema fully describes the parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to given high schema coverage.
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 '获取存储桶元数据' (Get bucket metadata) states a clear verb ('获取' - get) and resource ('存储桶元数据' - bucket metadata), establishing the tool's basic purpose. However, it lacks specificity about what metadata is retrieved (e.g., creation date, permissions, size) and does not differentiate from siblings like 'tos_list_buckets' (which lists buckets) or 'tos_get_object' (which retrieves object data), leaving room for 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. It does not mention prerequisites (e.g., bucket existence), exclusions (e.g., not for object data), or comparisons to siblings like 'tos_list_buckets' (for listing) or 'tos_get_object' (for object retrieval), leaving the agent to 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?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose that deletion is destructive and irreversible, potential permissions required, error conditions (e.g., non-empty bucket), or rate limits. 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 front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 destructive deletion tool with no annotations and no output schema, the description is incomplete. It lacks critical context: what TOS is, the irreversible nature of deletion, prerequisites, and expected outcomes. This leaves significant gaps for safe agent operation.
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 ('bucket_name') well-documented in the schema. The description adds no parameter-specific information beyond implying the bucket to delete. Baseline 3 is appropriate as the schema handles 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 '删除 TOS 存储桶' clearly states the action (delete) and resource (TOS bucket). It distinguishes from siblings like 'tos_create_bucket' (create) and 'tos_delete_object' (delete object rather than bucket). However, it doesn't specify what TOS is or the scope of deletion, keeping it from 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., bucket must be empty), exclusions, or related tools like 'tos_list_buckets' for verification. 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?
With no annotations, the description carries the full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires authentication, has rate limits, returns binary data or errors for missing objects, or if it's idempotent. For a download operation, 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 with zero waste. It's front-loaded and appropriately sized for the tool's purpose, making it easy to parse quickly.
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 a download operation (involving data retrieval, potential errors, and no output schema), the description is incomplete. It doesn't explain what is returned (e.g., file content, format, or error handling), and with no annotations, it fails to cover critical behavioral aspects, making it inadequate for safe 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%, so the schema already documents all parameters (bucket_name, object_key, return_as_base64). The description adds no additional meaning beyond implying these are needed for downloading, which is minimal value. Baseline 3 is appropriate as 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 '从 TOS 下载对象' clearly states the action (download) and resource (object from TOS), distinguishing it from siblings like 'tos_put_object' (upload) and 'tos_list_objects' (list). However, it doesn't specify that this downloads the object's content (vs. metadata), which could be inferred but isn't explicit.
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 like 'tos_presigned_url' (for temporary access) or 'tos_get_bucket_meta' (for metadata). The description implies it's for downloading objects, but lacks context on prerequisites (e.g., object must exist) or exclusions (e.g., not for streaming).
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 '上传对象到 TOS' (upload object to TOS), which implies a write/mutation operation, but does not disclose critical traits such as permissions required, whether it overwrites existing objects, rate limits, error handling, or response format. This is a significant gap 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 phrase ('上传对象到 TOS') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it highly concise and well-structured for its purpose.
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 a write operation with 5 parameters and no annotations or output schema, the description is incomplete. It lacks information on behavioral traits (e.g., mutation effects, error cases), output format, and usage context. This is inadequate for a tool that performs object uploads, as it leaves critical operational details unspecified.
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 all parameters well-documented (e.g., bucket_name, content, object_key). The description does not explain parameter interactions, defaults, or usage examples. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is added.
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 '上传对象到 TOS' clearly states the action (upload) and resource (object to TOS) in Chinese, making the purpose understandable. It distinguishes from siblings like tos_delete_object (deletion) and tos_get_object (retrieval). However, it lacks specificity about what 'TOS' refers to (e.g., a storage service), which slightly reduces 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., bucket must exist), exclusions, or comparisons to siblings like tos_presigned_url (for pre-signed uploads) or tos_image_process (for image-specific handling). Usage is implied by the action but not explicitly defined.
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 ('list') without any information about permissions required, rate limits, pagination, error conditions, or what the output looks like (e.g., bucket names, creation dates). This is inadequate for a tool that likely returns a list of resources.
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 phrase ('列举 TOS 存储桶') that directly conveys the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for its simplicity.
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 output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of bucket names or details), any behavioral traits like authentication needs or limitations, or how it fits with sibling tools. For a tool in a storage service context, this leaves 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since no parameters exist, and the description doesn't contradict or confuse this.
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 '列举 TOS 存储桶' (List TOS buckets) clearly states the verb ('list') and resource ('TOS buckets'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'tos_list_objects' which lists objects within buckets rather than the buckets themselves, 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. For example, it doesn't mention that this tool lists all buckets in the TOS service, while 'tos_list_objects' requires specifying a bucket to list its contents, or that 'tos_get_bucket_meta' retrieves metadata for a specific bucket. This lack of comparative context leaves usage unclear.
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:

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

Score Badge

Copy to your README.md:

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

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