Provides tools for downloading, uploading, and stat'ing files in Egnyte, enabling AI agents to access binary file contents and perform chunked uploads to the Egnyte cloud storage platform.
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., "@Egnyte Large File Manager download the Excel file at /Projects/budget.xlsx to my local machine"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server that fills the binary / large-file gap in Egnyte's hosted MCP connector.
Egnyte's official connector only returns extracted text (get_file_content) into agent context — it never hands you the real file bytes. So you can't pandas.read_excel() / openpyxl a workbook, parse a native PDF, or re-package a .msg. This server adds the missing piece: sign in with OAuth, then download the actual binary to local disk (and chunk-upload large files back).
It is meant to run alongside the official Egnyte connector, not replace it:
Use the official Egnyte MCP for | Use this server for |
search, | downloading real file binaries to disk, chunked upload of large files |
Where it runs. This is a local stdio MCP server (and
.mcpbbundle). The download→disk→load flow only works where the MCP server shares a filesystem with code execution:
Claude Code (CLI): ✅ fully works — server and your code run on the same machine.
Claude Cowork / sandboxes: ⚠️ Cowork runs your code in an isolated VM whose filesystem is separate from the host where the MCP server runs, so a file the MCP downloads isn't visible to the VM's Python. Use the bundled
python/egnyte_fetch.pyinside the sandbox instead (see Claude Cowork / cloud sandbox).claude.ai web chat: ❌ remote connectors only; no local MCP, no Python filesystem.
Tool | Purpose | Returns |
| Download a file's real bytes to local disk by | the local filesystem path (never the bytes) |
| Upload a local file to Egnyte. Automatically uses chunked upload above the size threshold. | entry/group id + checksum |
| Get file metadata (size, type, ids, checksum) — use to decide before downloading. | metadata object |
| Force the OAuth browser sign-in (otherwise it happens lazily on first call). | sign-in status |
The model gets a path, not the bytes — so a 200 MB workbook never bloats the context. Your code then does pd.read_excel("/path/from/tool").
Related MCP server: mcp-dropbox
Uses the OAuth 2.0 authorization-code flow over an HTTPS localhost loopback redirect. Egnyte does not support PKCE / public clients, so this is a confidential client: a client_secret is required and is stored as a sensitive config field (never logged).
On first tool call (or egnyte_login) the server opens your browser to Egnyte's sign-in page.
You log in as yourself — including via your company's SSO/SAML.
Egnyte redirects to https://localhost:<port>/callback (a self-signed loopback listener — accept the one-time browser cert warning); the server captures the code and exchanges it (with the client_secret) for a token.
The token is cached locally (0600-permission file in your config dir) and reused; it auto-refreshes, falling back to a browser re-auth only when the refresh token is gone.
Because you sign in as yourself, the server only sees what your Egnyte permissions allow — same access model as the official connector. No shared service account, no flattened ACLs.
Headless / SSH: set EGNYTE_NO_BROWSER=1 — the server prints the authorize URL instead of launching a browser; open it on any machine that can reach your Egnyte domain, and it will redirect back to the loopback.
Node.js ≥ 18
An Egnyte API key + secret. Register an app at https://developers.egnyte.com → "Get an API Key". Register https://localhost:53682/callback as the allowed redirect (Egnyte requires HTTPS).
Your Egnyte domain (e.g. acme.egnyte.com).
Local dev: copy .env.example → .env and fill in EGNYTE_DOMAIN, EGNYTE_CLIENT_ID, and EGNYTE_CLIENT_SECRET (all required — Egnyte is a confidential client).
Installed .mcpb bundle: the host (Claude Desktop) prompts for these via the bundle's user_config — client_secret is stored as a sensitive field.
npm install
npm run login # one-time browser sign-in, caches token
npm run dev # run the stdio server locally
npm run build # compile to dist/
npm run pack # build + package into egnyte-large-file-manager.mcpbclaude mcp add egnyte-large-file-manager --transport stdio -- node /abs/path/to/dist/server.js(or install the packed .mcpb in Claude Desktop)
In Cowork your code runs in an isolated VM whose filesystem is separate from the host where an MCP server runs — so the MCP's download wouldn't be visible to the VM's Python. For these environments use the bundled, dependency-free python/egnyte_fetch.py, which runs inside the sandbox and pulls bytes straight from the Egnyte API.
1. Pre-seed a token (interactive browser OAuth can't reach a headless VM):
Run npm run login once on a machine with a browser, then inject the resulting token into the sandbox — either copy ~/.config/egnyte-mcp/tokens.json, or set EGNYTE_ACCESS_TOKEN as a sandbox secret.
Per-user ACLs are preserved only if each user injects their own token (not a shared one).
2. Use it in the sandbox (EGNYTE_DOMAIN + the token in env):
python egnyte_fetch.py download "/Shared/Docs/report.xlsx" # prints {"path": "...", ...}from egnyte_fetch import download
import pandas as pd
path = download("/Shared/Docs/report.xlsx")["path"]
df = pd.read_excel(path, sheet_name=None) # real binary, loaded in-VMSame hardening as the MCP: *.egnyte.com host lock, .. path rejection, download-dir confinement, SHA-512 verify, single + chunked upload.
Per-user OAuth — no shared service token; Egnyte ACLs are enforced per signed-in user.
Client secret — Egnyte requires a confidential client; the client_secret is stored as a sensitive config field and is never logged or returned to the model. OAuth state guards the callback against CSRF.
Token cache is a 0600 file; it is git-ignored and must never be committed.
Least privilege — request only the scopes you need (filesystem read; add write only if you upload).
Paths, not bytes — file contents are written to disk and referenced by path, never echoed through the model.
Download confinement — downloads are restricted to the configured download directory; a model-supplied dest cannot escape it (no ../ or absolute-path writes).
Host locked to *.egnyte.com — the API host is validated, so a bad EGNYTE_DOMAIN can't exfiltrate the token/secret to another server. .. segments in Egnyte paths are rejected.
Apache-2.0. See LICENSE.
Download an Egnyte file's REAL binary to local disk and return the local path (not the bytes). Use this when you need to load a file with code — e.g. pandas/openpyxl on .xlsx, parse a native PDF, read a .msg. Streams, so large files are fine. Provide the Egnyte path (e.g. /Shared/Docs/report.xlsx).
| Name | Required | Description | Default |
|---|---|---|---|
| egnyte_path | Yes | Egnyte path, e.g. /Shared/Docs/report.xlsx | |
| entry_id | No | Specific version entry_id (optional) | |
| dest | No | Local destination file path or directory (optional; defaults to the download dir) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes streaming for large files and return of local path. Annotations already declare readOnlyHint and openWorldHint; description adds value by specifying behavior beyond annotations (streaming, large file handling). No contradictions.
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?
Three sentences, front-loaded with core purpose. Second sentence provides when-to-use context. Third sentence gives path example. No wasted words; concise and informative.
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?
Covers key aspects: what it downloads, how it returns, parameter usage. With no output schema, it explains return value. Minor gaps: no mention of overwrite behavior or error handling, but sufficient for typical use.
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 coverage 100% with descriptions. Description adds context: explains path format with example, clarifies return value. Adds value beyond schema by tying parameters to usage scenario.
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?
Clear verb 'download' and resource 'Egnyte file's REAL binary to local disk'. Distinguishes from siblings by specifying it returns a local path, not bytes, and mentions use cases (pandas, openpyxl). Differentiated from egnyte_stat and egnyte_upload.
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?
Explicitly says when to use: 'when you need to load a file with code' with examples. Implicitly excludes metadata operations (sibling egnyte_stat) and uploads (egnyte_upload). Lacks explicit 'do not use for' statements, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the Egnyte OAuth browser sign-in now (otherwise it happens automatically on the first file operation). Opens your browser; sign in as yourself (SSO supported).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations (which show readOnlyHint=false and openWorldHint=true) by explaining the explicit vs automatic sign-in behavior and browser interaction.
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?
Extremely concise: two sentences with no wasted words, and the most important information is front-loaded.
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 tool's simplicity (zero parameters, no output schema), the description fully covers its purpose, behavior, and usage context.
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?
No parameters exist; baseline score of 4 applies since no parameter info is needed and schema coverage is 100%.
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 verb 'start' and the resource 'Egnyte OAuth browser sign-in', and distinguishes from sibling tools like logout or download.
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?
It explains when to use explicitly ('otherwise it happens automatically on the first file operation'), providing clear context for usage without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke and clear the cached Egnyte token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive action of token revocation and cache clearing, consistent with the destructiveHint annotation. It adds context beyond the annotation by specifying 'clear cached', but could further describe impact on subsequent operations.
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?
Single sentence with no extraneous words. Perfectly concise and upfront.
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 logout with no parameters and no output schema, the description is informative enough. It could briefly mention that subsequent tool calls will require re-authentication, but not essential.
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?
No parameters exist, so baseline score is 4. Description adds no parameter info, which is appropriate.
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 uses a specific verb 'Revoke and clear' and identifies the resource 'cached Egnyte token', which clearly distinguishes it from sibling tools like login, download, etc.
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 explicit guidance on when to use this tool versus alternatives. While the purpose implies post-login usage, there is no mention of prerequisites or counter-indications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for an Egnyte file or folder (size, checksum, ids, is_folder). Use before downloading to check size / that it is a file.
| Name | Required | Description | Default |
|---|---|---|---|
| egnyte_path | Yes | Egnyte path to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds specific returned fields (size, checksum, ids, is_folder) and usage hint. No contradictions.
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?
Two sentences with no filler: first defines purpose, second gives usage guidance. Efficient and well-structured.
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?
Simple tool with one param and no output schema; description covers returned fields and use case. Could mention return format but not necessary for completeness given context.
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?
Only one parameter egnyte_path with 100% schema coverage; description does not add extra meaning beyond the schema, but baseline is acceptable.
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 for an Egnyte file or folder (size, checksum, ids, is_folder)' with a specific verb and resource. It also differentiates from sibling tools like egnyte_download by suggesting use before downloading.
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?
Explicitly advises to 'Use before downloading to check size / that it is a file', providing clear context for when to use. Lacks explicit exclusions or alternatives, but sufficient given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file to Egnyte. Automatically uses chunked upload for large files (>= ~100 MB). Returns the new entry/group id and checksum.
| Name | Required | Description | Default |
|---|---|---|---|
| local_path | Yes | Absolute path of the local file to upload | |
| egnyte_path | Yes | Destination Egnyte path, e.g. /Shared/Docs/out.xlsx | |
| chunk_size | No | Override chunk size in bytes (clamped to 10MB–1GB) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavior beyond annotations: automatic chunked upload for large files and return values (entry/group id and checksum). But does not disclose potential side effects despite openWorldHint=true, such as overwrite behavior or error conditions.
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?
Two sentences, front-loaded with the core action, followed by essential details (chunking, return values). 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?
Given only 3 parameters and no output schema, the description covers the core functionality well. However, it lacks mention of prerequisites (e.g., login state) and what happens on conflict or failure. Still, it meets the needs for a focused upload tool.
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 coverage is 100% with parameter descriptions. The description enhances meaning by linking chunk_size to the auto-chunking behavior and specifying that local_path must be absolute. This adds value beyond the 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 the action (upload a local file), the target (Egnyte), and contrasts with sibling tools like download, stat, login, logout. It is specific and unambiguous.
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 explicit guidance on when to use this tool versus alternatives, prerequisites (e.g., login required), or conditions for avoidance. The description only states the function, not the context.
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. Dates show when Glama detected each change.
v0.1.0egnyte_downloadegnyte_loginegnyte_logoutegnyte_stategnyte_uploadEach tool has a clearly distinct function: download, login, logout, stat, upload. No overlap in purpose.
All tools follow a consistent 'egnyte_' prefix followed by a verb (download, login, logout, stat, upload), making them predictable.
5 tools is well-scoped for a large file manager, covering authentication, metadata inspection, download, and upload without unnecessary extras.
Covers core operations for large files (login, stat, download, upload) but lacks delete, move, or list capabilities, which are minor gaps given the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Egnyte's remote MCP server for secure AI access, search, upload and file management in your account.
Cloud file relay: chunked uploads, folders, share links, inline text reads, ZIP packing.
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
Browse and manage files in your Moxt AI workspace from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hschickdevs/egnyte-large-file-manager'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
