Click on "Deploy 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., "@io.github.kinginsun/mcp-aliyun-oss Upload /tmp/report.pdf to OSS with prefix agents/reports"
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.
Standalone MCP server (Python SDK 2.x MCPServer) with one tool, oss-upload: put an object on Aliyun OSS named {prefix}/{md5}{ext}.
Repository: github.com/kinginsun/mcp-aliyun-oss
Credentials are read from the environment only. Never put AccessKeys in this repo or in chat.
oss-uploadProvide exactly one source:
Argument | Use when | Bytes | Extension |
| File already on disk | Read the absolute path | Path suffix; optional |
| Generated text (HTML / Markdown / JSON) | UTF-8 | Required |
| Binary |
| Same as |
Other arguments:
oss_path_prefix — default agents/docs. Must start with agents/. No ...
Return value: { status, file_size, key, url } (file_size is decoded bytes).
Decoded size cap is 100MB. Large files: pass local_file_path. Do not send huge base64 over stdio.
Related MCP server: Tencent Cloud COS MCP Server
Required (or the OSS_TEST_* aliases):
Variable | Meaning |
| AccessKey ID |
| AccessKey Secret |
| Bucket name |
| Regional endpoint without |
Optional: OSS_PUBLIC_URL_BASE (CDN / custom domain), OSS_CONNECT_TIMEOUT (seconds, default 120).
If OSS_PUBLIC_URL_BASE is set, url is {base}/{key}; otherwise https://{bucket}.{endpoint}/{key}.
Copy .env.example to a local .env for development; do not commit .env.
From PyPI (after release):
uv tool install mcp-aliyun-oss
# or: pip install mcp-aliyun-ossFrom source:
git clone https://github.com/kinginsun/mcp-aliyun-oss.git
cd mcp-aliyun-oss
uv sync --extra dev~/.cursor/mcp.json)PyPI / uvx (recommended for end users):
{
"mcpServers": {
"aliyun-oss": {
"command": "uvx",
"args": ["mcp-aliyun-oss"],
"env": {
"OSS_ACCESS_KEY_ID": "your-id",
"OSS_ACCESS_KEY_SECRET": "your-secret",
"OSS_BUCKET": "your-bucket",
"OSS_ENDPOINT": "oss-cn-hangzhou.aliyuncs.com"
}
}
}
}Local checkout (development):
{
"mcpServers": {
"aliyun-oss": {
"command": "uv",
"args": ["run", "--directory", "/path/to/mcp-aliyun-oss", "mcp-aliyun-oss"],
"env": {
"OSS_ACCESS_KEY_ID": "your-id",
"OSS_ACCESS_KEY_SECRET": "your-secret",
"OSS_BUCKET": "your-bucket",
"OSS_ENDPOINT": "oss-cn-hangzhou.aliyuncs.com"
}
}
}
}uv run pytestOSS put_object is mocked; no live bucket is required.
GitHub — push to https://github.com/kinginsun/mcp-aliyun-oss (public).
PyPI — bump version in pyproject.toml and server.json, then either:
GitHub Release with tag v0.1.0 (workflow .github/workflows/publish-pypi.yml uses secret PYPI_API_TOKEN), or
Local: uv build && uv publish with a PyPI API token.
MCP Registry — after the same version is on PyPI, install mcp-publisher, log in with GitHub, and from this repo run mcp-publisher publish (uses root server.json).
Registry server name: io.github.kinginsun/mcp-aliyun-oss.
MIT
Upload a file to Aliyun OSS. Object name is MD5(content) + extension under an agents/ prefix.
Provide exactly one source:
local_file_path: absolute path on the machine running this MCP server
content: UTF-8 text (generated HTML/Markdown/JSON); requires filename
content_base64: binary (optional data:*;base64, prefix); requires filename
filename is required for content / content_base64 and may override the suffix when using a path. Example: report.html. Prefix default agents/docs; must start with agents/. Decoded size cap 100MB — large files use local_file_path. Credentials: OSS_ACCESS_KEY_ID, OSS_ACCESS_KEY_SECRET, OSS_BUCKET, OSS_ENDPOINT (or OSS_TEST_*). Returns {status, file_size, key, url}.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| filename | No | ||
| content_base64 | No | ||
| local_file_path | No | ||
| oss_path_prefix | No | agents/docs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses crucial side effects and prerequisites: generated object names, prefix validation, credential environment variables, size cap, and return fields. It does not cover overwrite or error behavior, so it stops short of a 5.
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 purpose is front-loaded and the rest is formatted as scannable bullets that map to parameters. Any redundancy, such as the repeated filename requirement, also carries the additional override/default information.
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?
For a tool with five unstructured optional parameters, no annotations, and no output schema, the description provides mutual exclusion rules, prerequisites, size constraints, naming, and return format—everything needed to call it correctly.
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?
Schema descriptions are 0% covered, but the tool description explains all five parameters: path semantics for local_file_path, UTF-8 vs binary for content/content_base64, the filename override rule, and the prefix default/validation.
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 first sentence names the exact operation and destination ('Upload a file to Aliyun OSS'), and the object-name rule (MD5(content) + extension under agents/) makes the tool's function unambiguous even in the absence of sibling tools.
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 explicitly requires exactly one source, tells when to prefer each source type, and states conditions such as filename being required for content/content_base64. The 100MB cap with 'large files use local_file_path' is a concrete when-to-use rule.
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.
v0.1.0oss-uploadScored across 1 tool
Only one tool exists, so there is no risk of an agent confusing it with another tool. The single oss-upload tool has a clear, singular purpose.
The tool name oss-upload follows a clear verb_noun style and is internally consistent. However, with only one tool there is no broader set of names to compare against for a full consistency assessment.
A single upload tool is far too narrow for a server named mcp-aliyun-oss, which implies broader object storage capabilities. Even if the intent is upload-only, one tool feels under-scoped for the apparent domain.
The server only supports uploading files and lacks common OSS operations such as listing, retrieving, deleting, or generating presigned URLs. This is a significant functional gap that would force agents to rely on external tooling for basic object lifecycle management.
Cloud file relay: chunked uploads, folders, share links, inline text reads, ZIP packing.
File uploads for AI agents. Upload, list, and manage files. No signup required.