Skip to main content
Glama

Create upload URL

create_upload_url

Step 1 of 2 for uploading a file you already HOLD — one generated locally, returned as base64 by an image API, or sitting on disk. Returns a one-time address to send the bytes to, plus the exact HTTP requests to make; the caller sends the bytes and finish_upload then turns them into an asset. Requires a token with the write scope and a caller that can make HTTP requests. Prefer upload_from_url whenever the file is already at a URL Playbook can fetch — that route is one call and needs nothing from you. Come here when it is not: no URL at all, a URL behind a login, an expired signed URL, a host that blocks datacenter addresses, or an ingest that failed with "Source URL too large to fetch; upload manually" (Playbook's fetcher runs to a five-minute streaming budget, which this path does not have — though it has a size ceiling of its own, below). When neither a reachable URL nor HTTP requests are available, share_board with enable_uploads returns a link a person can drop the file on. Files above 104857600 bytes are refused: these tools transfer in a single request, and splitting a larger file into chunks is what the Playbook web and desktop apps are for.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filename": "<filename>",
      "size": "<size>",
      "media_type": "<media_type>"
    },
    "name": "create_upload_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeYesExact size of the file in BYTES. It is checked against the workspace's storage allowance before the upload address is issued, and a wrong value here produces a signature that does not match the bytes you actually send. Measure it, do not estimate it.
filenameYesFilename including its extension, e.g. "moon.png". Playbook derives the stored file extension from it, so a name with no extension produces an object with no usable type. It does NOT become the asset's title — the two calls share no state, so pass the title again to finish_upload.
media_typeYesMIME type of the file, e.g. "image/png". Required, and required again at completion: it is covered by the upload signature, so the value you give here is the exact Content-Type the recipe will tell you to send. Get it from whatever produced the file rather than guessing from the extension.
organizationNoWorkspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / size / maximum
      Added value: +9007199254740991
  2. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / context
      Removed value: -{
      -  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "filename",
      -  "size",
      -  "media_type",
      -  "context"
      -]New value: +[
      +  "filename",
      +  "size",
      +  "media_type"
      +]
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: discloses the required `write` token scope, that the caller must be able to make HTTP requests, that the address is one-time, that the two calls share no state, and that files above 104857600 bytes are refused because transfers are single-request. The only gap is that it does not say how long the one-time address stays valid.

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 purpose and return value, then routing rules, then limits — a sensible order for a multi-step tool. It is dense but nearly every clause carries decision-relevant information; the final sentence about chunking in the web/desktop apps is slightly expendable.

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 two-step, side-effecting tool with no output schema, the description covers the return value (one-time address plus exact HTTP requests), the auth requirement, the caller capability requirement, the size limit, and the handoff to finish_upload. Nothing an agent needs in order to call 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?

Schema coverage is 100%, so 3 is the baseline, but the description adds cross-call meaning the schema cannot: media_type and size are covered by the upload signature and must match exactly what is sent and re-supplied at completion, and there is a size ceiling referenced "below." It reinforces rather than merely repeats the field docs.

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 plus its role in a workflow: "Step 1 of 2 for uploading a file you already HOLD" and "Returns a one-time address to send the bytes to, plus the exact HTTP requests to make." It immediately distinguishes itself from upload_from_url, so an agent can choose between the two without opening either 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 routing rules: "Prefer upload_from_url whenever the file is already at a URL Playbook can fetch," followed by an enumerated list of when to come here (no URL, URL behind a login, expired signed URL, blocked datacenter host, ingest failure). It also names a third fallback, share_board with enable_uploads, for when neither a reachable URL nor HTTP requests are available.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources