Skip to main content
Glama
Sign In

Mojeeb

by app.mojeeb.mcp
OverviewDiscussionsAdmin

Create an upload

create_upload

Create an upload

Stages one file for 24 hours, so it can be used anywhere a media link is taken. Two ways:

  • Send the bytes yourself. Give file_name and the exact size_bytes. The upload comes back pending, with upload: the URL, method (PUT) and headers to send the file with, valid for 15 minutes. Send the whole file as the request body with those headers (putUploadContent), for example curl -X PUT -H "X-Upload-Token: …" -H "Content-Type: application/octet-stream" --data-binary @photo.png "$UPLOAD_URL", with upload.url as UPLOAD_URL.

  • Hand over a file as a link. Give file, as ChatGPT passes a file the user attached (download_url, file_id, and maybe mime_type and file_name). Mojeeb downloads it in this call, within 20 seconds, from a public https address (following up to 3 redirects, each to a public https address too), and the upload comes back ready.

An upload holds a JPEG, PNG or WebP image, an MP4 or MOV video, or a PDF or DOCX document, up to 20 MB, its type read from its bytes. Each feature that then reads it checks it against its own types and sizes. Use its url in the media field you need, within 24 hours. A member of the agent can create one; using it needs that feature's own scope. It spends a budget of 10 requests a minute per key.

Input Schema

NameRequiredDescriptionDefault
fileNoA file handed over as a temporary https link, the shape in which ChatGPT passes a file the user attached.
agent_idYesThe agent the resource belongs to. Another company's agent, or the nil UUID, is `404 agent_not_found`; an agent outside the key's agent list is `403 agent_not_authorized`.
file_nameNoThe file's name, with its extension.
size_bytesNoThe file's exact size in bytes: `putUploadContent` must send exactly that many.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses the 24-hour staging lifetime, pending vs ready states, 15-minute upload URL validity, 20-second download window, redirect limits, accepted formats and 20 MB cap, type detection from bytes, per-feature scope checks, and a 10 requests/minute budget per key. This is rich operational context that annotations alone do not provide.

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?

The description is long but well-structured, front-loading the two usage modes with bullets and a concrete curl example. Most details earn their place for a nested, non-idempotent creation tool, though it could be trimmed slightly without losing meaning.

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 complex tool with a nested file object, no output schema, and open-world network behavior, the description covers the missing pieces: return states, upload credentials, lifecycle, size/type limits, and authentication and rate-limit context. An agent has enough information to call it correctly and interpret the result.

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: file_name and size_bytes must match the exact byte length sent to putUploadContent, file is a temporary https link shape with download constraints, and mime_type is explicitly not trusted. This goes beyond the schema's own field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it creates an upload that stages a file for 24 hours for use as a media link. It clearly explains both creation modes, though it does not explicitly differentiate this tool from nearby siblings such as create_attachment.

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

Usage Guidelines4/5

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

It explains exactly when to use each mode: send bytes directly with file_name and size_bytes, or hand over a file link via the file object. It also gives lifecycle and scope guidance, but does not name alternatives or exclusions such as when to use create_attachment instead.

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

All Mojeeb toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources