stickafile-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STICKAFILE_URL | No | Base URL. Default `https://stickafile.com`. Point at a dev deploy to test. | https://stickafile.com |
| 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_TOKEN | Yes | An `sf_` API token. Scopes: list portals, push files. | |
| STICKAFILE_PORTAL | No | Default portal, by name or 8-character token, when `push` is called without one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pushA | 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. |
| list_portalsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
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.
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.
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.
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.