What can you do with this server?

Upload files from disk to a Stickafile portal and get a shareable link, and list available portals. * push(path, portal?): Upload a single absolute-path regular file from an allowed workspace directory to a Stickafile portal; returns { url, name, size }. * list_portals(): List the portals the token can push to, including name, token, mode, status, file count, and URL. * Portal selection: portal is an 8-character token from list_portals, never a name. If omitted and one active portal exists, it uses that; if multiple exist, it returns the list for the user to choose. * Safety: Refuses dotfiles/dot-directories and credential-like files; resolves symlinks; path must be inside allowed roots. No override. * Limits: One file per call. No resume on failure—do not auto-retry; ask the user. Bytes never enter the model context. Token checked at startup.

How do I use stickafile-mcp?

1. Click on "Deploy 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., "@stickafile-mcp push dist/report.pdf and give me the link" 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.

stickafile-mcp

by gitkvn

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

stickafile-mcp

An MCP server that lets a coding agent upload a file from disk to Stickafile and hand back a shareable link. The bytes go from disk to storage and never enter the model's context.

Two tools:

push(path, portal?, note?) → { url, name, size }
list_portals() → the portals the token can push to

A push makes a standalone link by default. Pass a portal token when the file belongs in a project's portal instead.

Install

claude mcp add stickafile --scope user -e STICKAFILE_TOKEN=sf_... -- npx -y stickafile-mcp

In a project, ask for a link to a file:
push dist/report.pdf and give me the link

The server checks the token once at startup. A revoked, expired, or wrong-server token makes it exit with a message in the client's MCP log instead of failing on the first push. A network failure at startup does not block it; the first call reports the problem instead.

Any MCP client works; the equivalent .mcp.json entry is:

{
  "mcpServers": {
    "stickafile": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "stickafile-mcp"],
      "env": { "STICKAFILE_TOKEN": "sf_..." }
    }
  }
}

Related MCP server: YAFL MCP Server

Configuration

Variable	Required	Meaning
`STICKAFILE_TOKEN`	yes	An `sf_` API token. Scopes: list portals, push to portals, create links.
`STICKAFILE_ALLOW`	no	Directories `push` may read from, separated by `:` (`;` on Windows). Default: the directory the server was started in, which Claude Code sets to the project.
`STICKAFILE_PORTAL`	no	Default portal, by name or 8-character token. When set, a `push` without `portal` goes there instead of making a link.
`STICKAFILE_URL`	no	Base URL. Default `https://stickafile.com`. Point at a dev deploy to test.

Set them with more -e flags on claude mcp add, or in the env block of .mcp.json.

Links and portals

push without portal makes a link: a standalone file owned by your account, listed under Links on the dashboard, with no portal involved. This is the quick-send path and needs nothing configured beyond the token. The usual limits apply: 2 GB and 24 hours on the free plan, 10 GB and 30 days with pack credit.

push with portal puts the file in that portal instead, so it sits with a project's other files and the portal's own settings (gate, password, shared view) apply. The argument takes an 8-character portal token (e.g. a1b2c3d4), never a name. A name is guessable and an agent can invent a plausible one; a token has to come from list_portals.

STICKAFILE_PORTAL changes the default: when it is set, a push without portal goes to that portal rather than making a link. An explicit portal token still wins. If the configured portal is missing or deactivated, the push fails rather than silently falling back to a link.

note is optional plain text, up to 500 characters, shown on the download page under the file name. It is dropped on portals that have notes turned off.

Safety

push reads files, so it is the tool a prompt injection would aim at. The controls below run in the server and do not depend on the model behaving.

STICKAFILE_ALLOW is the real boundary. path must be absolute, symlinks are resolved first, and the resolved path must sit inside one of the allowed roots. The agent cannot widen the roots.
Deny list inside the roots. Dotfiles and dot-directories (.env, .git, .ssh, .aws, ...) and credential-shaped names are refused, with no override. The name check strips backup and double extensions (id_rsa.bak, server.key.gz) and matches credential words as whole tokens (aws_credentials, prod-secrets.yaml), so a suffix or affix does not slip a key or secret past it. As a side effect, a file whose name contains the whole word secret(s) or credential(s) is refused even when it is not sensitive (e.g. secret_plans.txt); copy it to a neutral name to push it.
Regular files only, and only what was vetted. vetPath opens the file once and the uploader reads from that descriptor, so the bytes uploaded are the bytes that were checked — a symlink or file swapped in after the check cannot redirect the upload. The descriptor's device and inode must match the entry that passed the name checks, or the push is refused. Files with more than one hard link are refused, because a hardlinked name can point at an inode whose home is outside the workspace; push a copy instead. The API token never appears in tool output.
Portal choice. A push to the wrong shared portal exposes the file to everyone holding that portal's link. The default is therefore a link, which only you and the people you send it to can open; the server never picks a portal on its own. Requiring a token rather than a name for portal raises the bar, but an agent that has called list_portals can still pass any token it saw, and there is no setting that forbids the argument.

Claude Code's own permission prompt is the human confirmation. The path shown there is the path that gets read.

Windows is untested

The path controls are developed and tested on macOS and Linux. Windows is not covered by the test suite, and three things are open questions rather than cleared: NTFS alternate data streams (a name like secret.pem:hidden does not end in .pem), 8.3 short names (ID_RSA~1), and whether realpath casing keeps the case-insensitive root-boundary check honest. O_NOFOLLOW, which closes the check-then-open race on POSIX, is also absent on Windows. Treat the guarantees above as verified on POSIX only until there is Windows coverage.

No resume

A failed push restarts from the beginning; the abandoned server-side session is cleaned up automatically. Because a retry re-sends the whole file, push tells the agent not to retry on its own and to ask the user first.

Development

npm run test:unit                # path and deny-list tests; no network
STICKR_REPO=../stickr npm test   # plus the full e2e against a local stickr checkout

The e2e boots the Stickafile backend from a checkout of the private stickr repo, so outside contributors cannot run it; npm run test:unit is the suite that runs anywhere.

src/upload.js is a port of public/upload-core.js in the stickr repo. The retry, chunking, and presign-continuation logic must stay in step between the two; see the header comment in each.

Available Tools

2 tools

list_portalsList Stickafile portalsA

Read-only

List the Stickafile portals this account can push to, with each portal's name, token, mode (shared or inbox), status, and file count. Call this when push reports that a portal must be chosen, or when the user asks what portals exist. Not needed before an ordinary push.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`portals`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior context by naming what each portal entry contains (name, token, mode, status, file count) and clarifying the shared-vs-inbox mode distinction, though it says nothing about pagination, result limits, or the sensitivity of the exposed token.

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?

Three compact sentences: the first states what is listed, the second states when to call it, the third states when not to. Nothing is padding, and the routing condition is front-loaded after the purpose.

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?

For a zero-parameter read tool with a full output schema and covering annotations, this is complete. Fields are summarized for orientation, trigger conditions are explicit, and no knowledge an agent needs to invoke it correctly is missing.

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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not invent parameter guidance.

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?

States a specific verb and resource ('List the Stickafile portals') plus scope ('this account can push to') and enumerates the returned fields. It is immediately distinguishable from the sibling 'push' tool, which performs the upload rather than enumerating destinations.

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

Usage Guidelines5/5

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

Gives explicit triggering conditions ('when push reports that a portal must be chosen, or when the user asks what portals exist') and an explicit exclusion ('Not needed before an ordinary push'). The agent knows both when to call it and when to skip it relative to the push sibling.

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

pushPush a file to StickafileA

Upload a file from disk to a Stickafile portal and return a shareable download link. Use this when the user wants to send, share, or hand off a file (a build, an export, a report, an archive, a video, a dataset) to a person or another machine, or asks for "a link" to a file. The bytes are read from disk and uploaded directly; they never enter the conversation. path must be an absolute path to a regular file inside the workspace. Dotfiles and credential-like files (.env, keys, certificates) are refused. portal is an 8-character portal token, obtained from list_portals; never invent one. It is optional when the account has exactly one active portal. If it is omitted and the account has several portals, the tool returns the list of portals (name, token, and whether each is shared) for the user to choose from — relay that and ask; do not pick one yourself. Tell the user which file you are uploading before calling this. Uploads take roughly a minute per gigabyte; call once per file and wait for the result. Do NOT retry a failed push automatically: there is no resume, so a retry re-sends the entire file from the start. Stop and ask the user whether to retry. Returns { url, name, size }.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path to the file to upload
`portal`	No	The 8-character portal token to push to, from list_portals. Not a portal name. Optional when the account has exactly one active portal; if omitted with several, the tool returns the list to choose from.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes
`name`	Yes
`size`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations establish this is a non-read-only, open-world, non-idempotent, non-destructive write. The description goes well beyond them, disclosing that bytes are read from disk and never enter the conversation, that dotfiles/credential-like files are refused, that ~1 minute/GB throughput applies, that there is no resume on retry, and that a missing portal with multiple portals triggers a portal-list response. This is unusually rich behavioral context.

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?

Front-loaded with the core action and return value, then layers edge cases in a logical order. It is long, but nearly every sentence carries actionable constraint (refusals, no-retry, throughput, portal fallback). Slightly verbose with repeated portal-optional phrasing, hence not a full 5.

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?

For a 2-parameter upload tool with an output schema and annotations, the description covers the full operational surface: input constraints, credential refusals, timing, retry policy, and the ambiguous multi-portal case. Nothing an agent needs to call it correctly is missing, and the return shape is stated since an output schema exists.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: path must be absolute and inside the workspace, and portal behavior when omitted (single-portal default vs. multi-portal fallback returning the list), plus 'never invent one.' These operational semantics exceed the field-level schema text.

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?

States a specific verb and resource: upload a file from disk to a Stickafile portal and return a shareable download link. Clearly separates this from list_portals, which is named only as the source of a portal token. An agent knows exactly what the tool does without opening the schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('when the user wants to send, share, or hand off a file ... or asks for "a link"'), with concrete examples (build, export, report, archive). It also gives operational exclusions: call once per file, wait, do NOT retry automatically because there is no resume, and stop and ask instead. Alternatives and conditions are spelled out.

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.

2 tool updatesv0.1.0Sep 11, 2026
- First observedlist_portals
- First observedpush

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-09-11 16:55 across 2 tools

Disambiguation5/5

push uploads a file and returns a link, while list_portals enumerates available portals; these are clearly distinct resource+action pairs with no overlap. The descriptions even clarify the dependency relationship between them without creating ambiguity.

Naming Consistency4/5

Both names use lowercase snake_case, but 'push' is a bare verb while 'list_portals' follows the verb_noun convention. The deviation is minor and both remain readable and predictable in style.

Tool Count3/5

Two tools is thin even for a focused file-sharing server; the primary action (push) plus one helper leaves no room for adjacent operations. It is defensible for a narrowly scoped uploader, but sits at the borderline of feeling under-provisioned.

Completeness3/5

The core upload-to-link workflow and portal discovery are covered, but there is no way to list files already in a portal, check upload status, delete/revoke a previously shared file, or manage portals beyond listing them. These are notable gaps for a file-sharing lifecycle.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

putput-mcp A
io.github.putput-io-dev
File uploads for AI agents. Upload, list, and manage files. No signup required.
File Systems Cloud Storage Agent Orchestration
421
uldl
sh.uldl
Persistent file storage for AI agents via MCP and curl. Upload, download, and version files.
File Systems Cloud Storage Agent Orchestration
2
uploads.shOAuth
sh.uploads
Host files from coding agents; stage on a branch and attach to GitHub PRs.
Version Control File Systems Developer Tools
118
Valet A
io.github.valetdotdev
Get share links, publish and manage websites, artifacts and agents. No account needed.
Content Management Systems Developer Tools Agent Orchestration
621

Related MCP Servers

@putput/mcpofficial
Cloud Storage Developer Tools
putput-io
A
license
Not graded
quality
D
maintenance
File uploads for AI agents. Upload, list, and manage files from AI coding assistants like Claude, Cursor, Windsurf, and VS Code Copilot with no signup required.
Updated 8 months ago (2026-02-27 20:34 UTC)
1
MIT
YAFL MCP Serverofficial
Cloud Storage File Systems
yafldev
A
license
Not graded
quality
D
maintenance
Enables AI agents to securely transfer files between machines via encrypted, expiring share links, with tools for upload, download, status checks, and link management.
Updated 3 months ago (2026-08-01 20:37 UTC)
MIT
mcp_file_manager
Cloud Storage File Systems
xtawa
F
license
A
quality
B
maintenance
Enables AI agents and users to upload and download files via MCP, generating shareable links and identifier codes. Files are automatically deleted after 24 hours.
Updated 2 months ago (2026-08-09 10:01 UTC)
9
-
pshare-share-mcp
ntanhprt
F
license
A
quality
C
maintenance
Enables AI assistants to upload files and folders to a Pshare instance and generate share links, with support for optional password, TTL, and chunked uploads for large files.
Updated 2 months ago (2026-08-21 02:48 UTC)
1
-

stickafile-mcp

Install

Configuration

Links and portals

Safety

Windows is untested

No resume

Development

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@putput/mcpofficial

YAFL MCP Serverofficial

mcp_file_manager

pshare-share-mcp