Which integrations are available for this server?

Provides tools for managing cloud storage remotes and performing file operations (copy, sync, list, mkdir, delete, etc.) via the Rclone RC API.

How do I use rclone-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rclone-mcp-server What files are in my backup remote?" 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.

rclone-mcp-server

by angenge

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

rclone-mcp-server

MCP (Model Context Protocol) server for the Rclone RC API. Gives AI assistants the ability to manage cloud storage remotes, copy/sync files, list directories, and more — all through natural language.

Tools are auto-generated from the rclone-openapi spec using the rclone-sdk client. 98 endpoints, organized into selectable toolsets.

Prerequisites

A running rclone remote control daemon:

rclone rcd --rc-no-auth
# or with auth:
rclone rcd --rc-user=admin --rc-pass=secret

Related MCP server: Agentic AI MCP Server

Installation

All configurations below assume a running rclone daemon (see Prerequisites). Pick one transport — it decides the shape of your client config:

stdio — the MCP client spawns a local server process itself (npx/node, or wrapped in a Docker container) and talks to it over the process's stdin/stdout. This is what Cursor, Claude Desktop, and opencode use locally.
Streamable HTTP — a standalone server runs somewhere and clients connect over HTTP to its /mcp endpoint. No client-side process is spawned.

Stdio transport (local processes)

Directly with npx (requires Node.js)

Cursor / Claude Desktop (.cursor/mcp.json or claude_desktop_config.json):

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_URL": "http://localhost:5572"
      }
    }
  }
}

opencode (~/.config/opencode/opencode.json, or a project-level opencode.json):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "rclone-mcp-server": {
      "type": "local",
      "command": ["npx", "-y", "rclone-mcp-server"],
      "environment": {
        "RCLONE_URL": "https://rclone.example.com"
      }
    }
  }
}

opencode's MCP config differs from other clients — do not copy the mcpServers block above verbatim:

type: "local" is required; opencode uses it to decide how to spawn the server.
command must be an array of strings; there is no separate args key.
Environment variables go under environment, not env.
Use "enabled": false to disable a server.
Restart opencode after editing — config is only loaded at startup. Its tools then appear under the mcp__rclone-mcp-server__ prefix.

With HTTP Basic Auth (rcd behind a reverse proxy). The same shape works for any stdio launch — put the auth variables under env for Cursor/Claude Desktop as shown, under environment for opencode, or as -e flags for Docker:

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_URL": "https://rclone.example.com",
        "RCLONE_USER": "your_user",
        "RCLONE_PASS": "your_password"
      }
    }
  }
}

Via Docker (container over stdio)

Still stdio — the container just runs the same server (ENTRYPOINT node dist/index.js, default stdio command) and the client starts it with docker run. Use this when the client machine has Docker but you don't want Node.js/npm installed there.

Step 1 — build the image (once, on the machine that runs Docker):

cd rclone-mcp-server
docker build -t rclone-mcp-server .

Step 2 — configure the client to spawn docker run -i --rm ... rclone-mcp-server instead of npx.

opencode:

{
  "mcp": {
    "rclone-mcp-server": {
      "type": "local",
      "command": [
        "docker", "run", "-i", "--rm",
        "-e", "RCLONE_URL=http://host.docker.internal:5572",
        "-e", "RCLONE_USER=your_user",
        "-e", "RCLONE_PASS=your_password",
        "rclone-mcp-server"
      ]
    }
  }
}

Cursor / Claude Desktop:

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "RCLONE_URL=http://host.docker.internal:5572",
        "-e", "RCLONE_USER=your_user",
        "-e", "RCLONE_PASS=your_password",
        "rclone-mcp-server"
      ]
    }
  }
}

Notes:

-i is mandatory: it pipes the client's stdin/stdout into the container, which is how stdio MCP works.
host.docker.internal resolves to the machine running Docker. Use it when rcd runs on that same machine; otherwise set RCLONE_URL to the real daemon address. Note: Docker Desktop (Windows/macOS) adds this host automatically, but plain Docker Engine on Linux does not — there you must also pass --add-host=host.docker.internal:host-gateway. On Linux you can instead just set RCLONE_URL to the host's LAN IP and skip the flag.
Environment variables must be passed with -e (or --env-file) — a client's own environment/env block does not reach inside the container.
Tune toolsets/read-only with e.g. -e RCLONE_TOOLSETS=default,jobs or -e RCLONE_READ_ONLY=1 (see Environment Variables).

Streamable HTTP transport (standalone server)

The server runs on its own and clients connect over HTTP — no client-side spawn. Use for remote hosting or web-based MCP clients that can't spawn local processes, or when you want one server shared by many clients.

Step 1 — start the server on a machine that can reach the rcd daemon. The rclone connection settings come from that machine's environment:

RCLONE_URL=https://rclone.example.com \
RCLONE_USER=your_user \
RCLONE_PASS=your_password \
npx rclone-mcp-server http --port 3000

(KEY=value prefixes are bash/POSIX syntax — on Windows cmd use set "RCLONE_URL=...", on PowerShell $env:RCLONE_URL="...".)

It listens on http://0.0.0.0:3000/mcp (the /mcp path only).

Step 2 — point clients at the endpoint instead of a local command.

opencode (~/.config/opencode/opencode.json):

{
  "mcp": {
    "rclone-mcp-server": {
      "type": "remote",
      "url": "http://localhost:3000/mcp"
    }
  }
}

Cursor (.cursor/mcp.json, UI: Type = streamableHttp):

{
  "mcpServers": {
    "rclone-mcp-server": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

Claude Desktop (claude_desktop_config.json) does not accept url entries (they are silently dropped), so bridge over stdio with mcp-remote:

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:3000/mcp"]
    }
  }
}

Note: replace localhost with the server's hostname/IP when clients run on other machines. The server binds all interfaces by default — put it behind a reverse proxy with authentication (HTTPS) before exposing it publicly, and point clients at https://your-host.example.com/mcp.

Also note that RCLONE_USER/RCLONE_PASS only protect the link between this server and rcd — the MCP /mcp endpoint itself has no authentication, and the default toolset includes write operations (copy/mkdir/delete). Do not expose it to untrusted networks without the reverse-proxy auth above.

Configuration

These settings configure the server process itself. They work identically no matter which of the two ways the process gets started:

spawned by your MCP client — the client launches the server for you using one of the configs from Installation (npx/docker, stdio mode). You don't run anything by hand; the settings live in the client's own env/environment block (or in -e flags for Docker).
started manually in a terminal — required for the standalone http mode and for direct testing. You type the command yourself and pass the settings as shell environment variables or CLI flags.

Both channels feed settings into the same process. The two sections below document those inputs (environment variables and CLI flags) once.

Environment Variables

Variable	Description	Default
`RCLONE_URL`	rclone RC daemon URL	`http://localhost:5572`
`RCLONE_USER`	HTTP Basic Auth username	—
`RCLONE_PASS`	HTTP Basic Auth password	—
`RCLONE_TOOLSETS`	Comma-separated toolset list	`default`
`RCLONE_READ_ONLY`	Set to `1` to disable write tools	—
`PORT`	HTTP listen port for the `http` command	`3000`

CLI Arguments

The server's own command-line interface, used when you start it manually:

stdio is the default command — it is exactly the process a client spawns for you in stdio mode (Stdio transport), so you rarely type it yourself.
http is the standalone mode that must be started manually — the Step 1 of Streamable HTTP transport.

rclone-mcp-server [command]

Commands:
  rclone-mcp-server stdio  Run with stdio transport (default)
  rclone-mcp-server http   Run with Streamable HTTP transport

Options:
  --toolsets   Comma-separated list of toolsets
  --read-only  Only expose read-only tools
  --port       HTTP port (http command only, default: 3000)

Toolsets

Tools are grouped by API path prefix. Enable only what you need to keep the tool list focused.

Toolset	Paths	Default
`core`	`/core/version`, `/core/stats`, `/operations/about`	Yes
`config_read`	`/config/listremotes`, `/config/get`	Yes
`operations`	`/operations/list`, `/operations/stat`, `/operations/size`, `/operations/copyfile`, `/operations/movefile`, `/operations/mkdir`, `/operations/deletefile`	Yes
`sharing`	`/operations/publiclink`	No
`sync`	`/sync/*`	No
`jobs`	`/job/*`	No
`config_admin`	`/config/*` (rest)	No
`operations_advanced`	`/operations/*` (rest)	No
`mount`	`/mount/*`	No
`serve`	`/serve/*`	No
`core_advanced`	`/core/`, `/rc/` (rest)	No
`vfs`	`/vfs/*`	No
`cache`	`/cache/*`	No
`debug`	`/debug/*`	No
`backend`	`/backend/*`	No
`options`	`/options/*`	No
`plugins`	`/pluginsctl/*`	No
`fscache`	`/fscache/*`	No

Special values:

default — the three default toolsets (core, config_read, operations)
all — every toolset

Examples

Manual terminal invocations of the flags above (the manual channel — run the server directly, e.g. for testing, instead of having a client spawn it). The same settings, when the server is spawned by a client, go under RCLONE_TOOLSETS / RCLONE_READ_ONLY in the client's env/environment block (or as -e flags for Docker):

# Default toolsets (12 tools)
npx rclone-mcp-server

# Everything (98 tools)
RCLONE_TOOLSETS=all npx rclone-mcp-server

# Just file operations and config
npx rclone-mcp-server --toolsets operations,config_read

# Default + mount
npx rclone-mcp-server --toolsets default,mount

# Read-only mode (no copy, delete, sync, etc.)
npx rclone-mcp-server --read-only

MCP Resources

Beyond the call-based tools, the server exposes read-only resources so clients can pull context like a file URL. They are always registered (regardless of toolset) and are safe to enable in read-only mode.

Resource URI	Description
`rclone://remotes`	List of configured remote names
`rclone://config/dump`	Full config dump with secrets redacted (pass, token, key, auth, …)
`rclone://core/version`	Running Rclone engine / Go version
`rclone://core/stats`	Real-time transfer & job stats
`rclone://jobs/active`	Active background jobs
`rclone://{remote}/{+path}`	Directory listing or file content for a remote path (stat → list / cat; binary or >1MB files return metadata only)

Examples:

rclone://remotes
rclone://core/version
rclone://my-remote/ — list the root of remote my-remote
rclone://my-remote/Books/guide.pdf — try to read a file

Read-Only Mode

When --read-only or RCLONE_READ_ONLY=1 is set, only non-mutating tools are registered. This excludes operations like file copy/move/delete, sync, directory creation, mount/unmount, etc. Useful for giving AI assistants safe, read-only access.

Usage Scenarios

The scenarios below build on the base installs from Installation: use the stdio command/args block you picked there and only swap the env fields. For the stdio examples below we use the published package via npx; if you built locally, replace "command": "npx", "args": ["-y", "rclone-mcp-server"] with "command": "node", "args": ["/path/to/rclone-mcp-server/dist/index.js"].

The examples use the Cursor / Claude Desktop mcpServers form. For opencode, keep the server entry as an opencode local config and move every env key under environment — see the opencode variant of Scenario 1 below.

Scenario 1 — Standard developer config (default tools + job monitoring)

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_URL": "http://localhost:5572",
        "RCLONE_TOOLSETS": "default,jobs"
      }
    }
  }
}

For a remote daemon behind a reverse proxy with HTTP Basic Auth:

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_URL": "https://rclone.example.com",
        "RCLONE_USER": "your_user",
        "RCLONE_PASS": "your_password",
        "RCLONE_TOOLSETS": "default,jobs"
      }
    }
  }
}

Same scenario in opencode form (~/.config/opencode/opencode.json):

{
  "mcp": {
    "rclone-mcp-server": {
      "type": "local",
      "command": ["npx", "-y", "rclone-mcp-server"],
      "environment": {
        "RCLONE_URL": "https://rclone.example.com",
        "RCLONE_USER": "your_user",
        "RCLONE_PASS": "your_password",
        "RCLONE_TOOLSETS": "default,jobs"
      }
    }
  }
}

2 — Read-only (viewing only)

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_URL": "http://localhost:5572",
        "RCLONE_TOOLSETS": "default",
        "RCLONE_READ_ONLY": "1"
      }
    }
  }
}

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_URL": "http://localhost:5572",
        "RCLONE_TOOLSETS": "default,jobs,sync,sharing"
      }
    }
  }
}

4 — Everything (98 tools)

{
  "mcpServers": {
    "rclone-mcp-server": {
      "command": "npx",
      "args": ["-y", "rclone-mcp-server"],
      "env": {
        "RCLONE_TOOLSETS": "all"
      }
    }
  }
}

Common Tool Examples

The registered tool names are snake_case versions of each RC endpoint, e.g. /operations/copyfile → operations_copyfile. Since this is often an MCP bridge to a remote rcd daemon, remote names must carry a trailing colon and there is no local: remote on the daemon — use a real configured remote (e.g. my-remote:).

Discover (always list first, never guess a path)

{ "fs": "my-remote:", "remote": "" }                 // `rclone_lsjson` — root
{ "fs": "my-remote:", "remote": "Books", "recurse": true }  // recursive
{ "fs": "my-remote:", "remote": "Books/x.pdf" }       // `operations_stat` — one file
{ "fs": "my-remote:" }                                // `operations_size` — totals
{ "fs": "my-remote:" }                                // `core_about` — quota/capacity

Single-file operations

# copy one file
{ "srcFs": "my-remote:", "srcRemote": "backup/a.txt",
  "dstFs": "other-remote:", "dstRemote": "incoming/a.txt" }   // operations_copyfile

# move one file (source removed on success)
{ "srcFs": "my-remote:", "srcRemote": "a.txt",
  "dstFs": "my-remote:", "dstRemote": "archive/a.txt" }              // operations_movefile

# create / delete a directory or file
{ "fs": "my-remote:", "remote": "new-folder" }        // operations_mkdir
{ "fs": "my-remote:", "remote": "tmp/a.txt" }         // operations_deletefile

Deleting a directory needs the operations_advanced toolset. The default tools only include operations_deletefile, which removes a single file — it cannot delete directories. Removing empty directories / a directory tree is done by operations_rmdir / operations_rmdirs / operations_purge, which are grouped under operations_advanced (default: false). To enable directory deletion, set RCLONE_TOOLSETS=default,jobs,operations_advanced. (mkdir is in the default operations toolset, so creating directories works out of the box; only deleting them requires the extra toolset.)

Bulk tree operations — always use `_async: true`

Whole-tree copies and syncs can exceed the request timeout. Set _async: true so the daemon returns a jobid immediately, then poll job_status.

# copy tree src -> dst (additive, no deletes)
{ "srcFs": "source-remote:", "dstFs": "my-remote:", "_async": true }  // sync_copy

# mirror dst to src (DESTRUCTIVE — deletes extra dst files)
{ "srcFs": "my-remote:", "dstFs": "source-remote:", "_async": true }  // sync_sync

# poll the job
{ "jobid": 17 }   // job_status -> until `finished` is true

Long-running tools that accept _async: sync_copy, sync_move, sync_sync, operations_copyfile, operations_movefile, operations_size, operations_purge, operations_delete, operations_copyurl, operations_check.

Share links (`sharing` toolset only)

{ "fs": "my-remote:", "remote": "share/folder" }       // operations_publiclink
{ "fs": "my-remote:", "remote": "share/folder", "unlink": true }  // remove

License

MIT

This project is a secondary refactor based on rclone-ui/rclone-mcp.

Available Tools

12 tools

config_getA

Get remote configuration — Returns the key/value settings for a single remote.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name of the remote configuration to fetch.
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of transparency. It discloses that the tool returns key/value settings, implying a read operation, but lacks explicit statements about safety, error handling, or prerequisites such as existing remote.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two short sentences that front-load the verb and resource, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter, the description adequately states the return type (key/value settings), but with no output schema and no mention of edge cases like missing remote names or error behavior, it is only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds minimal meaning by clarifying the 'single remote' scope, but the parameter descriptions already cover all necessary semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get'), resource ('remote configuration'), and scope ('single remote'), distinguishing it from sibling tools like config_listremotes which list all remotes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for a single remote, which contrasts with listremotes, but it does not explicitly name alternatives or provide when-to-use versus when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

config_listremotesA

List configured remotes — Returns the names of all remotes defined in the config file.

ParametersJSON Schema

Name	Required	Description	Default
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It states that all remote names are returned and implies a read-only listing operation, but it does not disclose edge cases (e.g., empty config file), authentication requirements, or whether the list reflects only the persistent config. For a straightforward list command, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with two parts: a succinct purpose ('List configured remotes') and an explanatory clause. No wasted words, easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no required parameters, no output schema, no annotations), the description is complete enough: it names the action, the resource, and the return type. It does not need to elaborate further, though it could mention formatting (e.g., array vs. newline-delimited).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes both parameters (_async and _group) with high coverage (100%). The description adds no extra parameter-level meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' with the resource 'configured remotes' and explicitly states the return value: 'names of all remotes defined in the config file.' This clearly distinguishes the tool from siblings like config_get (which likely retrieves specific config) and operations_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 compared to alternatives. It does not mention config_get for details on a single remote, nor does it state any prerequisites or exclusions. The agent must infer usage solely from the tool's name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

core_aboutA

Get remote quota — Returns storage quota and usage details for the remote, equivalent to rclone about.

ParametersJSON Schema

Name	Required	Description
`fs`	No	Remote name or path to query for capacity information.
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It states the tool returns storage quota and usage details, implying a read-only operation, but it does not explicitly confirm safety, side-effect-free behavior, or error conditions. The description adds 'equivalent to rclone about' which offers some context, but there is room for more explicit behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the primary action ('Get remote quota') and includes a clear explanation of the return value. It is concise, with no superfluous words, and effectively communicates the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, with no output schema and no annotations. The description explains what it returns (storage quota and usage details) and provides context via the rclone equivalence. It is complete enough for an agent to select and invoke the tool correctly, though it could optionally mention the format of the returned details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides descriptions for all three parameters (fs, _async, _group), achieving 100% coverage. The tool description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get remote quota' and elaborates on returning storage quota and usage details. It distinguishes itself from sibling file-operation tools by focusing on quota information and even mentions the equivalent rclone command, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (to retrieve quota and usage), but it does not explicitly discuss when not to use it or mention alternative tools. The equivalence to 'rclone about' offers some guidance, but it lacks explicit exclusions or comparisons with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

core_statsB

Current stats snapshot — Returns active transfer statistics including bytes transferred, speed, and error counts.

ParametersJSON Schema

Name	Required	Description
`group`	No	Stats group identifier to return a snapshot for. Leave unset to include all groups.
`short`	No	When true, omit the `transferring` and `checking` arrays from the response.
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It implies a read-only, non-mutating operation via the word 'snapshot', which is useful, but it does not explicitly state that it has no side effects, nor does it mention behaviors related to the `_async` parameter. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that says 'Current stats snapshot' and then explains what is returned. Every word contributes; it is minimal and efficient with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple stats tool with four optional parameters and no output schema, the description covers the key return content (bytes, speed, error counts). It does not explain grouping or async behavior, but those are well-covered by the schema, so the description is sufficient for basic selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides full (100%) description coverage for all four parameters, so the baseline is 3. The tool description adds meaning about return content (bytes, speed, errors) but not about parameter semantics; it does not compensate or go beyond the schema's parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a snapshot of active transfer statistics including bytes transferred, speed, and error counts, using a specific verb and resource. However, it does not differentiate from the sibling tool `operations_stat`, which likely serves a similar purpose, so it stops short of a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as `operations_stat` or other sibling tools. The description gives no context about typical use cases, prerequisites, or scenarios where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

core_versionA

Report rclone version — Returns the running rclone version, build metadata, and Go runtime details.

ParametersJSON Schema

Name	Required	Description	Default
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the action is a 'report' (implying read-only) and explicitly lists the three categories of returned data (version, build metadata, Go runtime details). This gives the agent a clear picture of behavior without hiding anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is one concise sentence that front-loads the primary verb and resource ('Report rclone version'), then immediately lists the expected output. Every word earns its place; there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a trivial tool with no output schema, so the description must explain return values. It does so by enumerating version, build metadata, and Go runtime details. The generic parameters are fully documented in the schema, and no other context is required. The description is complete for its complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for both parameters (_async and _group), including their meaning and purpose. The description adds no parameter-specific details, but since these are generic infrastructure parameters, the schema already suffices. Thus the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and a resource: 'Report rclone version' and clearly states the exact output: 'running rclone version, build metadata, and Go runtime details.' This unambiguously differentiates it from sibling tools like core_stats or operations_mkdir, which serve entirely different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the use case obvious—call this tool when you need the rclone version or build/runtime information. There are no competing sibling tools for this functionality, so no exclusions or alternative tool references are needed. The context is clear and sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

operations_copyfileA

Copy a single file — Copies one object from a source remote and path to a destination remote and path.

IMPORTANT: If this operation is expected to take a long time (more than a few seconds), you MUST set _async: true to run it in the background. It will return a jobid immediately, which you can poll using the job_status tool.

ParametersJSON Schema

Name	Required	Description
`dstFs`	No	Destination remote name or path, such as `drive2:` or `/` for local filesystem.
`srcFs`	No	Source remote name or path, such as `drive:` or `/` for the local filesystem.
`_async`	No	Run this operation asynchronously in the background. Highly recommended to set to true for long-running operations to avoid timeout.
`_group`	No	Assign the request to a custom stats group.
`dstRemote`	No	Target path within `dstFs` where the file should be written.
`srcRemote`	No	Path to the source object within `srcFs`, for example `dir/file.txt`.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It explains the async mode and jobid/polling behavior, which is valuable. But it does not mention overwrite semantics, what the synchronous call returns, or error conditions, leaving gaps for a file-copy operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but the opening 'Copy a single file — Copies one object' is somewhat redundant. The important async warning is clearly highlighted. Overall it is concise with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter operation with no output schema, the description covers the core usage (copy from source to destination) and the crucial async guidance. It lacks details on synchronous return values and edge cases, but the schema fills in parameter specifics, making it sufficiently complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with descriptions, providing a baseline of 3. The tool description adds meaningful context: it explains the source/destination remote/path structure and emphasizes the `_async` parameter's importance for long operations and its jobid return value, going beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Copy a single file' which is a specific verb and resource, immediately distinguishing it from sibling tools like operations_movefile (move vs copy) and operations_deletefile. It clearly states the action: copying one object from a source remote/path to a destination remote/path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit guidance to use `_async: true` for long-running operations and mentions polling with `job_status`. However, it does not explicitly state when to prefer this tool over alternatives like movefile, though the action itself differentiates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

operations_deletefileA

Delete single file — Removes a specific object from the remote.

ParametersJSON Schema

Name	Required	Description
`fs`	No	Remote name or path that contains the file to delete.
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.
`remote`	No	Exact path to the file within `fs` that should be deleted.

TDQS

A3.5/5.0

Behavior2/5

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 disclosing behavior. It only states that the file is removed, with no mention of permanence, irreversibility, permission requirements, or side effects. This is minimal guidance for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but the em-dash clause 'Removes a specific object from the remote' is somewhat redundant with 'Delete single file'. It is compact but not maximally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks critical context for a destructive tool, such as whether deletion is permanent, what happens if the file does not exist, and whether special permissions are required. With no annotations and no output schema, the description is insufficient for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete) and the resource (single file/object). It distinguishes from siblings like copyfile and movefile by focusing exclusively on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to delete a single file), and the sibling tool names provide contrast for other operations. However, it does not include explicit exclusions or alternatives, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

operations_mkdirA

Create directory — Creates the target directory or container if it does not exist.

ParametersJSON Schema

Name	Required	Description
`fs`	No	Remote name or path in which to create a directory.
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.
`remote`	No	Directory path within `fs` to create.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses an important behavior (idempotence via "if it does not exist"), but it does not mention whether parent directories are created, what happens on errors, or detail the response/return value. This is a moderate level of transparency for a simple create operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with the main action stated first. The phrase "Create directory" is somewhat redundant with the tool name, but the clarifying clause adds value. Overall it is efficient with no unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and full schema coverage, the description provides a basic understanding of the action. However, it omits key context such as whether parent directories are created automatically and what happens if the target already exists (the "if it does not exist" hints at idempotence but does not fully clarify error behavior). This leaves some gaps for a no-annotation, no-output-schema tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds no supplementary meaning about the parameters; it only paraphrases the concept of a target directory, which is already captured by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (create) and resource (directory/container), and the idempotent condition "if it does not exist" adds precision. It is distinctly different from sibling tools like operations_copyfile or operations_deletefile, so purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (to create a directory), but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. Sibling tools are all different operations, so no conflict is present, but no guidance is given beyond the obvious purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

operations_movefileA

Move a single file — Moves one object from a source remote and path to a destination remote and path.

ParametersJSON Schema

Name	Required	Description
`dstFs`	No	Destination remote name or path where the file will be moved.
`srcFs`	No	Source remote name or path containing the file to move.
`_async`	No	Run this operation asynchronously in the background. Highly recommended to set to true for long-running operations to avoid timeout.
`_group`	No	Assign the request to a custom stats group.
`dstRemote`	No	Destination path within `dstFs` for the moved object.
`srcRemote`	No	Path to the source object within `srcFs`.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses long-running/async behavior and jobid polling, which adds value beyond the schema. But it does not explicitly state that the source is deleted after a successful move, nor does it mention permissions, overwrite behavior, or sync return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, followed by a necessary async warning. There is no fluff or redundancy, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimally viable for a move operation but lacks explicit details on prerequisites (e.g., required source/destination), sync return values, and the fact that the source is removed. With six parameters and no output schema, more clarity would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters already have descriptions. The tool description does not add further meaning for any parameter; it only echoes the `_async` behavior. Thus the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Move a single file') and the resource ('one object') with explicit source and destination contexts. This distinguishes it from siblings like operations_copyfile, operations_deletefile, and operations_mkdir.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit conditional guideline for async execution ('If this operation is expected to take a long time... you MUST set `_async: true`'), including how to handle the resulting jobid. However, it does not mention alternatives or when to prefer move over copy/delete, so it lacks full selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

operations_sizeA

Count remote size — Reports total size, file count, and number of objects without size metadata.

ParametersJSON Schema

Name	Required	Description
`fs`	No	Remote name or path to measure aggregate size information for.
`_async`	No	Run this operation asynchronously in the background. Highly recommended to set to true for long-running operations to avoid timeout.
`_group`	No	Assign the request to a custom stats group.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the key behavioral traits: a potentially long-running operation, the requirement to set _async for long runs, immediate jobid return, and polling via job_status. It does not state read-only status, but 'Count remote size' strongly implies a non-mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first leads with the purpose and output metrics, the second presents the critical async guidance. Every sentence is informative and the format is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a size-counting tool with no annotations and no output schema, the description covers the main behavior, the async path, and the polling mechanism. It lacks an explicit return-value breakdown or error cases, but is reasonably complete for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters, but the description adds important semantics by mandating _async for long-running cases and clarifying the background-execution behavior. It also reinforces that fs denotes the remote to measure, though _group is only covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Count remote size' and specifies the exact outputs: total size, file count, and number of objects without size metadata. This clearly distinguishes it from sibling file-operation tools like operations_mkdir or operations_deletefile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly frames the tool as a remote-size reporting operation and provides important operational context through the async execution note. It does not explicitly compare against alternatives or state when not to use it, but the purpose is specific enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

operations_statB

Stat an object — Returns metadata for a single file or directory, mirroring rclone lsjson on one entry.

ParametersJSON Schema

Name	Required	Description
`fs`	No	Remote name or path that contains the item to inspect.
`opt`	No	Optional JSON object of listing flags, matching those accepted by `operations/list`.
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.
`remote`	No	Path to the file or directory within `fs` to describe.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'mirroring rclone lsjson' which gives a hint about output format, but it does not explicitly state whether the operation is read-only, whether any modifications are made, or if special permissions are required. This lack of transparency is a significant gap for a tool 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the purpose ('Stat an object'). It is concise with no redundant information, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no annotations and no output schema, so the description must compensate. It provides a clear scope (single entry) and hints at output via the lsjson reference, but it lacks details on the exact return format, behavior with directories versus files, or how the 'opt' parameter affects results, leaving some gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% parameter descriptions, so the schema already fully documents all five parameters. The description adds no parameter-specific details beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns metadata for a single file or directory, which is a specific verb and resource. The reference to 'mirroring rclone lsjson' hints at differentiation from listing tools like rclone_lsjson, but it could be more explicit in distinguishing from sibling operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for single-item metadata retrieval via the phrase 'single file or directory', but it does not explicitly state when to use this tool over alternatives such as rclone_lsjson or operations_size, nor does it mention any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rclone_lsjsonB

List objects — Lists objects and directories for a remote path, returning the same fields as rclone lsjson.

ParametersJSON Schema

Name	Required	Description
`fs`	No	Remote name or path to list, for example `drive:`.
`opt`	No	Optional JSON-encoded object of listing flags (e.g. `{ "recurse": true, "showHash": true }`).
`_async`	No	Run the command asynchronously. Returns a job id immediately.
`_group`	No	Assign the request to a custom stats group.
`remote`	No	Directory path within `fs` to list; leave empty to target the root.
`recurse`	No	Set to true to list directories recursively.
`dirsOnly`	No	Set to true to return only directory entries.
`metadata`	No	Set to true to include backend-provided metadata maps.
`showHash`	No	Set to true to include hash digests for each entry.
`filesOnly`	No	Set to true to return only file entries.
`hashTypes`	No	Specify one or more hash algorithms to include when `showHash` is true (e.g. `md5`).
`noModTime`	No	Set to true to omit modification times for faster listings on some backends.
`noMimeType`	No	Set to true to omit MIME type detection.
`showOrigIDs`	No	Set to true to include original backend identifiers where available.
`showEncrypted`	No	Set to true to include encrypted names when using crypt remotes.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the burden of behavioral disclosure. It states that the tool lists objects and directories, which implies read-only behavior, but does not explicitly state that no modifications occur. It also mentions returning fields like `rclone lsjson`, which adds some context about output shape, but lacks details on pagination, response format, or backend-specific behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of a single sentence with a dash-used emphasis. It is front-loaded with the action ('List objects') and includes a useful clarifier about matching `rclone lsjson`. Every word earns its place, and there is no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 15 parameters and no output schema, yet the description only provides a one-line summary. It fails to mention default behavior (e.g., non-recursive unless `recurse` is set), the return format (JSON array), or any caveats about performance or API usage. The reference to `rclone lsjson` assumes familiarity with the external tool, which may not be available to the agent. This is insufficient for such a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides. Each parameter in the schema has a clear description (e.g., 'recurse', 'dirsOnly'), so the tool description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'List objects — Lists objects and directories for a remote path.' It specifies the action (list), resource (objects and directories), and scope (remote path). It also distinguishes from siblings like operations_mkdir and operations_deletefile by its focus on listing. The reference to `rclone lsjson` further clarifies the exact behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions or prerequisites. Siblings like operations_stat could be confused for listing a single object, but the description provides no comparative context or usage hints.

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.

12 tool updatesv1.0.3Aug 10, 2026
- First observedconfig_get
- First observedconfig_listremotes
- First observedcore_about
- First observedcore_stats
- First observedcore_version
- First observedoperations_copyfile
- First observedoperations_deletefile
- First observedoperations_mkdir
- First observedoperations_movefile
- First observedoperations_size
- First observedoperations_stat
- First observedrclone_lsjson

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools map to distinct rclone commands (mkdir, copy, move, delete, stat, lsjson, about, size, version, stats, config get/list). Slight overlap between 'operations_size' and 'core_about' (both report usage-related metrics) and between 'rclone_lsjson' and 'operations_stat' (both inspect objects), but the descriptions clarify the difference.

Naming Consistency4/5

Consistent use of domain prefixes (operations_, core_, config_) followed by verb_noun names. The outlier is 'rclone_lsjson' which uses a different prefix than the otherwise consistent 'operations_' prefix, but the structure is still readable.

Tool Count5/5

12 tools is well-scoped for an rclone wrapper, covering file operations, remote inspection, configuration queries, and core diagnostics without exceeding a manageable number.

Completeness3/5

The set covers common file lifecycle operations (create/copy/move/delete/stat) and remote inspection, but misses directory deletion (only mkdir) and any config mutation (only get/list). For a single-file oriented rclone server, this is a notable gap.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2

Related MCP Servers

rclone-mcp
Cloud Storage File Systems
rclone-ui
A
license
A
quality
F
maintenance
MCP server for the Rclone RC API. Gives AI assistants the ability to manage cloud storage remotes, copy/sync files, list directories, and more — all through natural language.
Updated 7 months ago (2026-02-08 21:37 UTC)
56
55
10
MIT
Agentic AI MCP Server
AI & Machine Learning Autonomous Agents
BenBoBenBo
A
license
Not graded
quality
D
maintenance
An MCP server with real AI capabilities (OpenAI/Anthropic) for natural language understanding, multi-step planning, and autonomous task execution, enabling intelligent file analysis, weather-based planning, and more.
Updated a year ago (2025-08-29 20:49 UTC)
225
ISC
@krovacloud/mcpofficial
Cloud Platforms Developer Tools
krovacloud
A
license
A
quality
A
maintenance
MCP server for interacting with the Krova Cloud API, enabling AI assistants like Claude to manage cloud resources.
Updated 17 hours ago (2026-09-05 17:35 UTC)
6
23
MIT
sync-vault-agent
Cloud Storage Search
abcamus
A
license
Not graded
quality
B
maintenance
An MCP server that enables AI assistants to search, read, and manage files across multiple cloud drives (Baidu, Aliyun, 115, OneDrive, Quark) through a unified interface.
Updated 2 months ago (2026-07-20 14:21 UTC)
19
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/angenge/rclone-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

rclone-mcp-server

Prerequisites

Installation

Stdio transport (local processes)

Directly with npx (requires Node.js)

Via Docker (container over stdio)

Streamable HTTP transport (standalone server)

Configuration

Environment Variables

CLI Arguments

Toolsets

Examples

MCP Resources

Read-Only Mode

Usage Scenarios

Scenario 1 — Standard developer config (default tools + job monitoring)

2 — Read-only (viewing only)

3 — Enable bulk sync + share links

4 — Everything (98 tools)

Common Tool Examples

Discover (always list first, never guess a path)

Single-file operations

Bulk tree operations — always use _async: true

Share links (sharing toolset only)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@krovacloud/mcpofficial

Latest Blog Posts

MCP directory API

Bulk tree operations — always use `_async: true`

Share links (`sharing` toolset only)