couchdrop-mcp
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., "@couchdrop-mcplist files in the root directory"
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.
couchdrop-mcp
Local stdio MCP server for Couchdrop. It lets MCP clients list Couchdrop files, inspect file metadata, download and upload files, list users and groups, and read folder permissions.
Requirements
Node.js 22 or newer
A Couchdrop API token
Related MCP server: MCP Local Filesystem Server
Couchdrop Token
Create or retrieve an API token from your Couchdrop account, then provide it to
the server as COUCHDROP_API_TOKEN. Keep the token in your local MCP client
configuration or shell environment. Do not commit it to source control.
Use a token with the narrowest access that fits your workflow.
Install And Configure
You can run the package with npx; no global install is required.
Claude Desktop
Add the server to your Claude Desktop MCP configuration, then restart Claude Desktop.
{
"mcpServers": {
"couchdrop": {
"command": "npx",
"args": ["-y", "couchdrop-mcp"],
"env": {
"COUCHDROP_API_TOKEN": "your-couchdrop-api-token"
}
}
}
}Codex
Codex reads MCP servers from ~/.codex/config.toml or a trusted project
.codex/config.toml.
[mcp_servers.couchdrop]
command = "npx"
args = ["-y", "couchdrop-mcp"]
[mcp_servers.couchdrop.env]
COUCHDROP_API_TOKEN = "your-couchdrop-api-token"Generic MCP Client
Configure the client to start a stdio server with this command:
{
"command": "npx",
"args": ["-y", "couchdrop-mcp"],
"env": {
"COUCHDROP_API_TOKEN": "your-couchdrop-api-token"
}
}If your client prefers an installed binary, install the package and run
couchdrop-mcp as the stdio command.
Environment Variables
Variable | Required | Default | Description |
| Yes | None | Couchdrop API token sent to Couchdrop API and FileIO requests. |
| No |
| Base URL for Couchdrop management API requests. |
| No |
| Base URL for Couchdrop FileIO requests. |
| No |
| Maximum bytes returned inline for downloads without |
Tools
All Couchdrop paths must start with /. Path segments must not contain ...
Tool | Arguments | Description |
|
| Lists files and folders at a Couchdrop path. |
|
| Gets metadata for a Couchdrop file or folder. |
|
| Downloads a file. Without |
|
| Uploads a local file to a Couchdrop path. |
| None | Lists Couchdrop users visible to the token. |
| None | Lists Couchdrop groups visible to the token. |
|
| Gets permissions for a Couchdrop folder path. |
Safety Notes
Tokens stay local to your MCP client configuration or environment. This server does not persist tokens.
v0.1 exposes no delete, move, chmod, user mutation, or group mutation tools.
couchdrop_upload_filewrites to the requesteddestinationPath; check the path before calling it.Use
outputPathfor large or binary downloads. Inline downloads are intended for small UTF-8 text files.In v0.1, uploads and downloads saved with
outputPathare buffered in memory before being sent or written.
Local Development
npm install
npm run typecheck
npm test
npm run build
npm run devTo inspect the package contents before publishing:
npm run build
npm pack --dry-runContributing
Contributions are welcome. Keep changes small, add or update tests for behavior changes, and run the local verification commands before opening a pull request.
Do not commit real Couchdrop tokens, generated secrets, or private customer paths in tests or documentation.
License
MIT
Available Tools
7 toolscouchdrop_download_fileD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| outputPath | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
couchdrop_get_file_infoD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
couchdrop_get_folder_permissionsD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
couchdrop_list_filesD
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | / |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
couchdrop_list_groupsD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
couchdrop_list_usersD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
couchdrop_upload_fileD
| Name | Required | Description | Default |
|---|---|---|---|
| localPath | Yes | ||
| destinationPath | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
v0.1.0- First observed
couchdrop_download_file - First observed
couchdrop_get_file_info - First observed
couchdrop_get_folder_permissions - First observed
couchdrop_list_files - First observed
couchdrop_list_groups - First observed
couchdrop_list_users - First observed
couchdrop_upload_file
TDQS
Each tool targets a distinct file or administrative operation (download, get info, list, upload, permissions, groups, users) with no overlap in purpose, making them easily distinguishable even without descriptions.
All tools follow the consistent 'couchdrop_verb_noun' pattern (e.g., couchdrop_download_file, couchdrop_list_users), with no mixing of conventions or ambiguous verbs.
Seven tools is well-scoped for a file management and permissions service; not too few to feel thin nor too many to overwhelm, covering core operations without redundancy.
Covers key file operations (upload, download, list, info) and some admin actions (list users/groups, get permissions), but notably lacks file deletion, file update, and any user/group creation or modification, creating significant gaps for full lifecycle management.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
- SupabaseOAuthcom.supabase
MCP server for interacting with the Supabase platform
The official MCP Server for the Mux API
MCP server for Appcircle mobile CI/CD platform.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server enabling file operations (list, search, read, rename, move) on Google Drive and OneDrive.MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that provides secure access to local file system operations.-
- AlicenseNot gradedqualityDmaintenanceMCP server for uploading, listing, and retrieving files on S3-compatible storage (AWS S3, DigitalOcean Spaces) with public/private access and temporary URLs.15MIT
- AlicenseNot gradedqualityAmaintenanceA full-featured secure MCP server for local file system operations, with built-in image processing, OCR and media tools.Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/OraDavis/couchdrop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server