Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TOS MCP Server list all objects in the 'documents' bucket"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
TOS 官方推出的 MCP Server 提供强大的查询能力，支持通过自然语言便捷地探索和检索 TOS 中存储的内容，提升了数据访问的直观性与效率。可以与火山引擎云产品 MCP 组合，助力构建更智能的业务应用场景。
版本 | v0.2.0 |
描述 | 基于 MCP 管理 TOS 资源，智能化探索数据 |
分类 | 存储 |
标签 | 搜索，视频，图片，文本 |
本 MCP Server 产品提供以下 Tools (工具/能力):
SaaS
该工具允许您便捷查看火山引擎TOS的存储桶列表。
输入：
{
"inputSchema": {
"type": "object",
"required": [],
"properties": {}
},
"name": "list_buckets",
"description": "查询您账号下拥有的所有存储桶的列表。"
}输出：
返回您账号下拥有的存储桶列表，包含桶名、创建时间、桶位置信息、访问域名等信息。
列举火山引擎 TOS 的存储桶列表。SaaS
该工具允许您便捷查看火山引擎TOS桶下的对象列表，每次请求都会返回存储桶中的部分或全部对象（最多 1000 个）。您可以使用请求参数作为选择条件，返回存储桶中对象的子集。
输入：
{
"inputSchema": {
"type": "object",
"required": [
"bucket"
],
"properties": {
"bucket": {
"type": "string",
"description": "用户指定的存储桶名称"
},
"prefix": {
"type": "string",
"description": "可选的对象前缀"
},
"start_after": {
"type": "string",
"description": "列举对象的起始位置。您可以通过指定对象的起始位置分页列举对象"
},
"continuation_token": {
"type": "string",
"description": "指定列举操作从该 Token 开始，通常从上次请求返回的 NextContinuationToken 中获取此 Token"
}
}
},
"name": "list_objects",
"description": "查询您指定存储桶的对象列表"
}
输出：
返回您指定存储下的对象列表，包含对象名、对象的最后修改时间、ETag、对象大小、存储类型等信息。
列举火山引擎 TOS 的 example 桶下的对象。SaaS
从 TOS 检索对象，需要指定桶名和对象的完整路径。对于文本内容的对象，比如文本文件、CSV 文件等，该工具返回的是其内容。对于图片、视频等二进制对象，该工具返回的是Base64编码的内容。
输入：
{
"inputSchema": {
"type": "object",
"required": [
"bucket",
"key"
],
"properties": {
"bucket": {
"type": "string",
"description": "用户指定的存储桶名称"
},
"key": {
"type": "string",
"description": "用户需要读取的对象名，需要指定完整的对象名"
}
}
},
"name": "get_object",
"description": "获取指定对象的内容，对于文本内容的对象，比如文本文件、CSV 文件等，该工具返回的是其内容。对于图片、视频等二进制对象，该工具返回的是Base64编码的内容。"
}输出：
返回具体的对象内容，对于文本内容的对象，比如文本文件、CSV 文件等，该工具返回的是内容。对于图片、视频等二进制对象，该工具返回的是Base64编码的内容。
读取火山引擎 TOS 桶example下对象名为example.txt的文件内容Related MCP server: MinIO Storage MCP
方舟，python，cursor
https://console.volcengine.com/tos
火山引擎，从 volcengine 管理控制台获取 volcengine 访问密钥 ID、秘密访问密钥和区域，请在.env文件中设置相关环境变量
以下环境变量可用于配置MCP服务器:
环境变量 | 描述 | 默认值 |
| 火山引擎账号 ACCESS KEY | - |
| 火山引擎账号 SECRET KEY | - |
| 火山引擎 TOS region | - |
| 火山引擎 TOS Endpoint | - |
| 火山引擎 Security Token，可选 | - |
| 指定访问的 TOS 桶，可选 | - |
安装 Python 3.10 或者更高版本
安装 uv
如果是linux系统
curl -LsSf https://astral.sh/uv/install.sh | sh如果是window系统
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"同步依赖项并更uv.lock:
uv sync构建mcp server:
uv buildWhen using uv no specific installation is needed. We will
use uvx to directly run mcp-server-tos.
添加以下配置到你的 mcp settings 文件中
{
"mcpServers": {
"tos-mcp-server": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/src/mcp_server_tos",
"run",
"mcp-server-tos"
]
}
}
}[示例如下]
查看MCP Server 详情 在大模型生态广场，选择合适的MCP Server，并查看详情
选择MCP Server即将运行的平台 检查当前MCP Server 已适配的平台，并选择合适的平台
查看并对比可用的Tools 仔细查看可用的Tools的功能描述与所需的输入参数，并尝试运行对应的功能。
获取专属的URL或代码示例 检查账号登录状态与服务开通情况，生成唯一URL
去对应的Client的平台进行使用 点击快捷跳转按钮，前往方舟平台的体验中心进行对应MCP Server的体验
[示例如下]
{
"mcpServers": {
"tos-mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/volcengine/mcp-server#subdirectory=server/mcp_server_tos",
"mcp-server-tos"
],
"env": {
"VOLCENGINE_ACCESS_KEY": "your access-key-id",
"VOLCENGINE_SECRET_KEY": "your access-key-secret",
"VOLCENGINE_REGION": "tos region",
"TOS_ENDPOINT": "tos endpoint",
"SECURITY_TOKEN": "your security token",
"TOS_BUCKET": "your specific bucket"
}
}
}
}volcengine/mcp-server is licensed under the MIT License.
Retrieves an object from VolcEngine TOS. In the GetObject request, specify the full key name for the object.
Args:
bucket: The name of the bucket.
key: The key of the object.
Returns:
If the object content is text format, return the content as string.
If the object content is binary format, return the content as base64 encoded string.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | ||
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return behavior for text vs. binary formats, which is valuable context beyond basic retrieval. However, it lacks details on error conditions, permissions required, rate limits, or whether it's read-only (implied but not stated).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The Args and Returns sections are structured clearly, though the formatting with quotes might be slightly verbose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with 2 parameters) and no annotations or output schema, the description is moderately complete. It covers the purpose, parameters, and return behavior, but lacks context on usage guidelines, error handling, or integration with sibling tools, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'bucket' is the bucket name and 'key' is the full key name for the object, clarifying what these parameters represent. For a tool with 2 parameters and low schema coverage, this compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'an object from VolcEngine TOS', making the purpose explicit. However, it doesn't differentiate from sibling tools like list_objects, which might also retrieve object information in a different way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 list_objects. It mentions specifying the full key name but doesn't explain when this is preferable over listing objects or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all buckets in TOS.
Returns:
A list of buckets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Returns: A list of buckets' which adds some behavioral context about the output. However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a list operation with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that directly state the action and return value. It's front-loaded and has zero waste, making it efficient. However, it could be slightly improved by integrating the return statement more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimal but covers the basic purpose and return. It's adequate for a simple list tool but lacks depth in behavioral context and usage guidelines, making it just sufficient for minimal viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%. With no parameters, the description doesn't need to add parameter semantics. The baseline for 0 parameters is 4, as it appropriately handles the lack of inputs without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List all buckets in TOS' which clearly indicates the verb (list) and resource (buckets). However, it doesn't differentiate from sibling tools like 'list_objects' which suggests it's vague about scope distinction. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'list_objects'. The description only states what it does without context or exclusions. This leaves the agent with no explicit or implied usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all objects in a bucket.
Args:
bucket: The name of the bucket.
prefix: The prefix to filter objects.
start_after: The start after key to filter objects.
continuation_token: The continuation token to filter objects.
Returns:
A list of objects.
| Name | Required | Description | Default |
|---|---|---|---|
| bucket | Yes | ||
| prefix | No | ||
| start_after | No | ||
| continuation_token | No |
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 mentions that it returns 'A list of objects' but lacks details on pagination behavior (implied by 'continuation_token'), rate limits, authentication requirements, or error handling. The description is minimal and doesn't adequately cover behavioral traits for a tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections for 'Args' and 'Returns', making it easy to scan. It's concise with no wasted words, though the parameter explanations are very brief. The front-loaded purpose statement is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return format (e.g., structure of the object list), pagination behavior (critical given 'continuation_token'), error cases, and usage context. The minimal parameter explanations don't compensate for the missing behavioral and output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all four parameters with brief explanations, but schema description coverage is 0%, so the schema provides no additional context. The parameter explanations are basic (e.g., 'The prefix to filter objects') and don't add significant semantic detail beyond what the parameter names imply. This meets the baseline for minimal compensation given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all objects') and resource ('in a bucket'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_object' (which retrieves a specific object) and 'list_buckets' (which lists buckets rather than objects). However, it doesn't explicitly mention how it differs from siblings beyond the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools like 'get_object' for retrieving specific objects or 'list_buckets' for listing buckets, nor does it explain prerequisites or appropriate contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_objectlist_bucketslist_objectsEach tool has a clearly distinct purpose with no ambiguity. get_object retrieves specific object content, list_buckets enumerates available buckets, and list_objects lists objects within a bucket. The three tools cover different operations without overlap.
All tool names follow a consistent verb_noun pattern with snake_case formatting. get_object, list_buckets, and list_objects maintain perfect naming consistency throughout the toolset.
With only 3 tools, this feels thin for a storage service interface. While the tools cover basic read operations, the absence of create, update, or delete operations makes this feel incomplete rather than minimal. The count is borderline for the apparent scope.
Significant gaps exist in this TOS storage interface. While it provides read operations (get_object, list_buckets, list_objects), it lacks essential CRUD operations like create_bucket, put_object, delete_object, or delete_bucket. Agents will encounter dead ends when trying to perform basic storage workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
Browse, search, rename, and favorite your Tolstoy media library from any AI client.
Create a free sandbox object storage bucket; upload, download, list, inspect, and delete objects.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dinghuazhou/sample-mcp-server-tos'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
