Una implementación de servidor de Protocolo de contexto de modelo (MCP) que proporciona acceso a varios servicios de almacenamiento a través de Apache OpenDAL™ .
Acceso sin inconvenientes a múltiples servicios de almacenamiento, incluidos S3, Azure Blob Storage, Google Cloud Storage y más
Listar archivos y directorios de los servicios de almacenamiento
Leer el contenido del archivo con detección automática de texto/binario
Configuración basada en variables de entorno
Related MCP server: Alibaba Cloud DMS MCP Server
pip install mcp-server-opendalAgregue lo siguiente a claude_desktop_config.json :
{
"mcpServers": {
"opendal": {
"command": "uvx",
"args": [
"mcp-server-opendal"
],
"env": {
"YOUR_ENV_VAR": "YOUR_ENV_VALUE"
}
}
}
}Requiere que uv esté instalado en su equipo. Consulte la documentación oficial para obtener instrucciones de instalación.
Configure los servicios de almacenamiento mediante variables de entorno. Cada servicio requiere un prefijo y opciones de configuración específicas.
Por ejemplo, para configurar un servicio S3 con el 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=mysecretkeyLuego puedes usar herramientas como read y list con mys3://path/to/file .
mcp-server-opendal también se cargará desde .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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_infolistreadScored across 3 tools
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.
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.
