Docs

Agents

How an agent connects to Just Share as a remote MCP server, and what you approve when it does.

Connect your agent once, approve it on the account site, then ask it to share files. The last part is a reference for people building agent apps.

What your agent app needs

Just Share is a remote MCP server. Your agent app needs to support remote MCP servers that ask you to sign in (MCP authorization over OAuth). A separate API key is not a way to connect. Whether an app supports remote MCP servers can depend on the app and on your plan with it, and in an organization an owner may have to add it.

Separately, your agent needs access to the files you want to share. Supporting remote MCP and OAuth does not by itself mean an app can read local files or send raw file bytes. No agent app is certified as supported here, so check your app’s documentation for both.

Connect

  1. In your agent app, add a remote MCP server with the address https://app.justshare.sh/api/mcp. Apps call this a connector, an integration or an MCP server.

    • In Claude, open Customize > Connectors, add a custom connector and paste the address. If Claude asks how to register, choose Register automatically.
    • In Cursor, add a server with this url in its MCP settings.
    • In VS Code, run MCP: Add Server, choose HTTP and paste the address.

    On the account site, the Agents page also has Open in Cursor and Open in VS Code. Each app asks you to confirm before it adds Just Share.

  2. The app opens a Just Share page, right away or the first time you use it. Sign in with your email, using the link we send or the six-digit code. Either works for 15 minutes. There is no password.

  3. Check the app’s name and the return address on the approval page. The app chooses its own name and Just Share doesn’t verify it. If the address belongs to the agent you’re using, choose Allow. If it looks unfamiliar, choose Don’t allow.

  4. Open the Agents page on the account site and select Check again. The agent you approved should be listed there.

If you choose Don’t allow, your agent app is told you said no, and it gets no access.

Try a first share

Once the agent is listed, ask it to share one file it can read. That checks that it can send files, not just connect. On Free, links expire after seven days and you don’t set an expiry:

Share ./report.pdf with Just Share.

On Paid, a new link needs an explicit expiry:

Share ./report.pdf with Just Share and make the link expire in 7 days.

Check that the agent returns a justshare.sh link and the file opens there. Keep the link and the conversation, because the agent needs them to update or delete the share. For a folder, see Getting started.

What you approve

The approval page shows the name the app gave when it registered and the address it sends you back to. Just Share doesn’t verify the name, so check that the address belongs to the agent you’re using.

Allowing an agent lets it:

  • Upload the files you ask it to share, create links, and update or delete your links.
  • On Paid, choose when each link expires and whether it keeps earlier versions.
  • Stay connected after the page closes, until you disconnect it.

It can’t choose or pay for a plan, and it can’t see your email address or payment details. The connector receives only the files your agent sends it, not your conversation or the rest of your project. Your agent can still send files you didn’t intend to share, so check what it is about to send.

Anyone who holds a recipient link can open it. Having no account to sign in to is not a privacy guarantee.

You approve on the account site, never inside a shared page. Shared pages are served from a separate address and can’t reach your account.

Disconnect

The Agents page on the account site lists the agents you allowed. Disconnect all agents removes access for every one of them at once, including access an agent is using at that moment. Your links stay up. To share again, connect your agent again from its app. You can’t disconnect a single agent yet.

Troubleshooting

You can’t find a place to add a remote connector. Your app, or your plan with it, may not offer remote MCP servers with sign-in. Check its documentation, or ask your organization’s owner.

The sign-in email doesn’t arrive or the code doesn’t work. The link and the code last 15 minutes. Request a new one from the sign-in page and use the newest.

The agent isn’t listed after you allowed it. On the Agents page, select Check again. If it is still missing, the approval may not have finished or may have been declined. Remove and re-add the connector in your app and go through the approval again. After Disconnect all agents, you also need to connect again from the app.

The agent is connected but can’t send files. There are two separate causes. If the agent can’t read the file on your computer, it needs file access, or another app that has it. If it can read the file but the files add up to more than 8 MiB inline, the agent must stage enough files, with an HTTP PUT of raw bytes and custom headers, to keep the inline total within 8 MiB (see Sending files). An app that can only send inline can share a smaller set, up to 8 MiB in total.

The share is refused. A file path may use only letters, digits, _, . and - in each folder or file name, and each name must start with a letter, digit or _. The entryPath must match one of the files you send. Free also refuses a request that sets an expiry or turns on history, and Paid refuses a new link without an expiry. See Limits for sizes.

For agent app developers

The connector follows the MCP authorization specification with OAuth 2.1.

MCP endpoint https://app.justshare.sh/api/mcp (stateless HTTP)
Protected resource metadata /.well-known/oauth-protected-resource/api/mcp
Authorization server metadata /.well-known/oauth-authorization-server/api/auth
Client registration Dynamic client registration for public clients
Grant Authorization code with PKCE, then refresh tokens
Scopes shares:write, and offline_access for refresh tokens
Access tokens Signed JWTs for the MCP endpoint, valid for 15 minutes
Refresh tokens Replaced on every use; an old one stops working

Client ID metadata documents are not supported. The connector exposes six tools and no tool for listing links.

Tools

Tool What it does
prepare_upload Reserves a one-use upload for one file and returns where and how to send its bytes.
publish_share Publishes files and returns the link, its ID and its revision.
update_share Replaces everything a link shows, keeping the same address.
get_share Returns a link’s address, title, current revision, expiry and whether history is on.
delete_share Stops the link and all its revisions from opening.
configure_share Changes a link’s expiry or version history without sending files.

publish_share takes a title, an entryPath (the file that opens first, such as index.html) and files. update_share takes the same fields, plus the link’s id and the expectedRevision it last saw. An update replaces the whole bundle, so list every file to keep. If the link changed since the agent last saw it, the update is refused, nothing changes, and the agent should read the current revision with get_share before retrying.

Both also accept two optional fields. Choosing an expiry and turning history on require Paid; setting historyEnabled to false also works on Free.

  • expiresInSeconds: from 3600 (one hour) to 31536000 (365 days), or null for no expiry. A new Paid link needs an explicit choice, so publish_share on Paid is refused without one. On update_share, leaving it out keeps the link’s current expiry.
  • historyEnabled: true keeps earlier versions of the link. History is off unless the agent turns it on.

configure_share takes { id, expectedRevision, historyEnabled?, expiresInSeconds? } and needs at least one of the two choices. A new expiry counts from the moment it is set. Setting historyEnabled to false permanently deletes the link’s saved earlier versions; they can’t be brought back.

On Free, a link expires 7 days after its latest successful publish or update. A failed update doesn’t restart that time. Free can’t set an expiry or turn on history: a call that tries is refused, with a message saying Paid is chosen on the website. An agent can set expiry and history, but it can’t buy Paid.

Sending files

The connector doesn’t read files from your computer or fetch them from addresses. Your agent reads each file itself and sends it in one of two ways. One files list can mix both.

  • Inline: { path, contentType, base64 }, with the file’s bytes encoded as base64 inside the tool call. Suited to small files.
  • Staged: { path, uploadId }, for a file the agent has already sent with prepare_upload and an HTTP PUT. Suited to large or binary files.

Staging only works if the agent can read local files and send an HTTP PUT with raw bytes and custom headers. Whether a given agent app can do this is up to the app.

To stage a file:

  1. Call prepare_upload with the file’s exact size in bytes and its MIME contentType. It returns an uploadId, an uploadUrl, an expiresAt time, method: "PUT" and the headers to send.
  2. Send the file’s raw bytes to uploadUrl with a PUT, using exactly the returned headers. They include an authorization bearer credential for this one upload and a content-length that must match the prepared size.
  3. Once the PUT succeeds, list the file in publish_share or update_share as { path, uploadId }.

For example, after prepare_upload returns, an agent with a shell could send the file like this. The values in angle brackets come from the prepare_upload result:

curl --fail -X PUT '<uploadUrl>' \
  -H 'authorization: Bearer <upload credential>' \
  -H 'content-type: application/octet-stream' \
  -H 'content-length: <size>' \
  --data-binary @demo.mp4

Then it publishes the staged video next to an inline page:

{
  "title": "Product demo",
  "entryPath": "index.html",
  "files": [
    { "path": "index.html", "contentType": "text/html", "base64": "<base64 bytes>" },
    { "path": "demo.mp4", "uploadId": "<uploadId>" }
  ]
}

Each prepared upload accepts one PUT and expires after one hour. If the PUT fails or the time runs out, call prepare_upload again; a used or expired upload can’t be retried. An upload that didn’t finish, has expired, belongs to another account, or was prepared before you disconnected your agents can’t be published.

The upload credential is as good as a password for that one file until it is used or expires. Keep it out of anything shared: don’t paste it into chat, logs or the files being published.

Limits

Each plan sets a file size and a total for everything the account stores. The connector refuses a share or update that would go over them.

Free Paid
Largest file 50,000,000 bytes 100,000,000 bytes
Stored across the account 500,000,000 bytes 20,000,000,000 bytes
Saved earlier versions None Optional, kept up to 90 days, counted in storage

The connector also has technical limits on every plan:

  • Up to 256 files in one publish_share or update_share call.
  • Inline files: up to 8 MiB of decoded bytes in one call.
  • A total size limit for each share, set by the operator, applies to inline and staged files together. It can be lower than the figures above.
  • Paths up to 512 characters, with each name made of letters, digits, _, . and -, starting with a letter, digit or _. The entryPath must be one of the files, and a path can’t appear twice.

See Share, update and delete for what happens when a step fails.

How an agent learns your plan’s limits before it shares isn’t built: today it finds out when a share is refused.