The MCP Server for Apache OpenDAL™ enables seamless access and operations across multiple cloud storage services:
List Files and Directories: Retrieve contents from supported storage services
Read File Contents: Access files with automatic text/binary detection
Get File Metadata: Obtain detailed information about specific files
Multiple Storage Support: Connect to services like S3, Azure Blob Storage, and Google Cloud Storage
Simple Configuration: Set up storage services using environment variables
Resource URI Access: Use resource URIs (e.g., alias://path/to/file) to interact with specific resources
Provides integration with Apache OpenDAL™, enabling access to various storage services through a unified interface.
Supports loading configuration from .env files for easier setup of storage service connections.
Enables listing files, reading file contents, and retrieving metadata from Google Cloud Storage through the OpenDAL interface.
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., "@MCP Server for Apache OpenDAL™ list files in mys3://documents/"
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.
A Model Context Protocol (MCP) server implementation that provides access to various storage services via Apache OpenDAL™.
Seamless access to multiple storage services including S3, Azure Blob Storage, Google Cloud Storage, and more
List files and directories from storage services
Read file contents with automatic text/binary detection
Environment variable based configuration
Related MCP server: Alibaba Cloud DMS MCP Server
pip install mcp-server-opendalAdd the following to claude_desktop_config.json:
{
"mcpServers": {
"opendal": {
"command": "uvx",
"args": [
"mcp-server-opendal"
],
"env": {
"YOUR_ENV_VAR": "YOUR_ENV_VALUE"
}
}
}
}It requires uv to be installed on your machine. Check the official documentation for installation guides.
Configure storage services by setting environment variables. Each service requires a prefix and specific configuration options.
For example, to configure an S3 service with alias "mys3":
OPENDAL_MYS3_TYPE=s3
OPENDAL_MYS3_BUCKET=mybucket
OPENDAL_MYS3_REGION=us-east-1
OPENDAL_MYS3_ENDPOINT=http://localhost:9000
OPENDAL_MYS3_ACCESS_KEY_ID=myaccesskey
OPENDAL_MYS3_SECRET_ACCESS_KEY=mysecretkeyThen you can use tool like read and list with mys3://path/to/file.
mcp-server-opendal will also load from .env.
npx @modelcontextprotocol/inspector \
uv run mcp-server-opendalGet metadata of file in OpenDAL service
Args:
uri: resource URI, e.g. mys3://path/to/file
Returns:
File metadata information
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should reveal behavioral traits but only mentions it returns metadata. It does not disclose potential side effects (read-only assumed), authorization needs, or error conditions, leaving the agent underinformed.
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 concise with clear sections for purpose, args, and returns. It avoids fluff but could include more detail on the return value. Still, it earns its brevity.
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 simple tool with one parameter and no output schema, the description provides basic information. However, it fails to describe the format or contents of the returned metadata, leaving a gap for the agent.
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?
With 0% schema coverage, the description provides an example URI format for the 'uri' parameter, adding meaning beyond the bare schema type. However, it lacks details like allowed schemes or URI validation, so only partially compensates.
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 'Get metadata of file', specifying a unique resource and operation. It distinguishes from sibling tools 'list' and 'read' by implying it returns metadata, not file listing or content.
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 on when to use this tool versus sibling tools like 'list' or 'read'. The description only states what it does, not in which context it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in OpenDAL service
Args:
uri: resource URI, e.g. mys3://path/to/dir
Returns:
String containing directory content
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the return type is a string with directory content, but lacks details on pagination, error handling, or side effects. The read-only nature is implied but not explicit.
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 extremely concise (5 lines) with clear Args/Returns structure. Every sentence adds value with no wasted words.
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 simple list tool with one parameter and no output schema, the description covers the basic purpose and parameter. However, it lacks details on output format, behavior with invalid URIs, and performance expectations.
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 description coverage is 0%, so the description compensates well. It explains the 'uri' parameter as a resource URI with an example format, adding meaning beyond the raw schema.
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 'List files in OpenDAL service' which is a specific verb and resource. It distinguishes from siblings like 'read' and 'get_info' by the listing action, but does not explicitly differentiate them.
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 on when to use this tool versus alternatives (e.g., when to use 'read' instead). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read file content from OpenDAL service
Args:
uri: resource URI, e.g. mys3://path/to/file
Returns:
File content or error information
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavior. It only states 'Read file content' and mentions 'Returns: File content or error information', but does not disclose read-only semantics, potential side effects, or limitations (e.g., file size, permissions).
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 extremely concise, using only three lines to convey purpose, argument, and return value. Every sentence is necessary and front-loaded with the primary function.
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 simplicity of the tool (single parameter, no output schema), the description covers the core functionality and return type. Minor gaps exist (e.g., no size limits or error details), but it is largely complete for a basic read operation.
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 description coverage is 0%, so the description must clarify parameters. It provides an example URI ('mys3://path/to/file') and labels the parameter as 'resource URI', adding some meaning beyond the raw schema. However, it does not explain the format or constraints fully.
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 'Read file content' and the resource 'from OpenDAL service', using a specific verb and object. It distinguishes from sibling tools 'get_info' and 'list' which imply different operations.
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. There is no mention of context, prerequisites, or when not to use it, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: get_info retrieves metadata, list lists directory contents, and read reads file content. There is no overlap between them.
Tools follow a verb_noun pattern (get_info, list, read), but 'list' and 'read' lack a noun component, which is a minor inconsistency. Overall, the naming is predictable.
With only 3 tools, the server covers only read operations, which is too few for a full-featured storage abstraction like OpenDAL. Many essential operations (create, delete, update) are missing.
The tool surface is severely incomplete for the stated purpose. It only provides read and listing capabilities, leaving out write, delete, and other management operations required for a storage server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Tigris MCP Server seamlessly connects AI agents to Tigris bucket and object management.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Xuanwo/mcp-server-opendal'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
