Skip to main content
Glama

sprkly-mcp

by app.sprkly
OverviewDiscussionsAdmin

Upload a file as media

sprkly_upload_media
Idempotent

Upload files the user has on their machine (slides, photos, a short video) into sprkly and get a media_id for each. LINK MODE is the way to send a file from disk. Send files, one entry per file with its filename, sha256 and size_bytes. You get back one uploadUrl per file. PUT the bytes to it: curl -sS -X PUT --data-binary @01.jpg "". Each PUT answers JSON with mediaId. Links last 15 minutes. Up to 50 MB per file and 35 files per call. The bytes never pass through you, so a whole carousel costs a few hundred tokens. INLINE MODE is for tiny files only (a few KB): data_base64 plus filename, 25 MB at most. base64 costs about one token per character, so never inline a real slide. When files is sent, data_base64 and filename are ignored. For a public link use media_urls on sprkly_schedule_post instead. The same bytes sent twice return the same media_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoLINK MODE. One entry per file, in slide order. Get the values in Bash: sha256sum 01.jpg (first 64 characters) and stat -c %s 01.jpg. 1 to 35 entries.
filenameNoINLINE MODE. The file name, for example 01.jpg. Used in the response and in error messages. The bytes decide the real type. Ignored when files is sent.
data_base64NoINLINE MODE, tiny files only. The file contents, base64 encoded. Standard or URL-safe alphabet, with or without a data: prefix. Ignored when files is sent.
content_typeNoINLINE MODE. Optional MIME hint such as image/jpeg. sprkly sniffs the bytes and that wins.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / content_type / description
      Previous value: -"Optional MIME hint such as image/jpeg. sprkly sniffs the bytes and that wins."New value: +"INLINE MODE. Optional MIME hint such as image/jpeg. sprkly sniffs the bytes and that wins."
    • changedInput schema / properties / data_base64 / description
      Previous value: -"The file contents, base64 encoded. Standard or URL-safe alphabet, with or without a data: prefix."New value: +"INLINE MODE, tiny files only. The file contents, base64 encoded. Standard or URL-safe alphabet, with or without a data: prefix. Ignored when files is sent."
    • changedInput schema / properties / filename / description
      Previous value: -"The file name, for example 01.jpg. Used in the response and in error messages. The bytes decide the real type."New value: +"INLINE MODE. The file name, for example 01.jpg. Used in the response and in error messages. The bytes decide the real type. Ignored when files is sent."
    • addedInput schema / properties / files
      Added value: +{
+  "description": "LINK MODE. One entry per file, in slide order. Get the values in Bash: sha256sum 01.jpg (first 64 characters) and stat -c %s 01.jpg. 1 to 35 entries.",
+  "items": {
+    "properties": {
+      "filename": {
+        "description": "The file name, for example 01.jpg.",
+        "type": "string"
+      },
+      "sha256": {
+        "description": "SHA-256 of the file, 64 hex characters.",
+        "type": "string"
+      },
+      "size_bytes": {
+        "description": "Exact file size in bytes.",
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "filename",
+      "sha256",
+      "size_bytes"
+    ],
+    "type": "object"
+  },
+  "maxItems": 35,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "data_base64",
-  "filename"
-]New value: +[]
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the idempotentHint annotation, the description adds rich behavioral context: presigned upload URLs, 15-minute link expiry, 50 MB and 35-file limits, the PUT flow, and that identical bytes yield the same media_id. It also explains that bytes never pass through the agent, which is valuable for cost and architecture understanding.

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 every section earns its place: mode selection, limits, workflow, and exclusion criteria. It is front-loaded with the core purpose, though a bit dense; minor tightening could make it even easier to scan.

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 tool with no output schema, the description fully covers what an agent needs: how to get upload URLs, how to upload bytes, what the response contains, limits, idempotency, and which sibling to use for public links. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already covers all parameters, the description adds meaning beyond it: it distinguishes the two modes, clarifies that files takes precedence over inline params, explains when data_base64 is appropriate, and provides concrete bash commands for computing sha256 and size_bytes.

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?

The description states a specific verb and resource: upload local files into sprkly and receive a media_id per file. It clearly distinguishes this from URL-based or public-link workflows, including naming the schedule_post alternative for public links.

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?

It explicitly explains when to use LINK MODE versus INLINE MODE, including file size thresholds, and directs users to sprkly_schedule_post for public links. This gives an agent actionable routing guidance beyond just naming the tool.

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

All sprkly-mcp 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