ViralMint

Start an upload

upload_start

Free. Gets a one-time signed upload URL; YOU send the file with your own HTTP client (the server never sees the bytes), then call upload_finish. The URL lives for a few minutes (attachment/project_media about 10, song about 15, video about 5). Voice uploads are not available here.

Args: kind: attachment (an image up to 10 MB, staged for AI Video / Personas; JPEG, PNG, WebP) | song (audio up to 100 MB for Music Video; MP3, WAV, M4A, AAC, FLAC, OGG) | video (your own MP4/MOV up to 500 MB, saved to the Library; 20 a day) | project_media (an image up to 10 MB added to one Studio project; needs project_id). content_type: the file's MIME type, e.g. image/png, audio/mpeg, video/mp4. size_bytes: the exact size of the file. rights_confirmed: must be true for attachment, song and project_media, and only when the user has told you they own it or have permission, including anyone shown in an image. Not needed for video. project_id: for project_media only. filename: optional, ignored by the server.

Returns: {ok, upload_id, method: PUT|POST, url, headers? (PUT: send exactly these) | fields? (POST: multipart form fields, then the file last), curl (use as the path), expires_in_s, then: 'upload_finish(upload_id)'}

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": {
      "kind": "<kind>",
      "content_type": "<content_type>",
      "size_bytes": "<size_bytes>"
    },
    "name": "upload_start"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	Yes
`filename`	No
`project_id`	No
`size_bytes`	Yes
`content_type`	Yes
`rights_confirmed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations: no bytes transit the server, the signed URL is one-time and short-lived with per-kind expiry (about 10/15/5 minutes), size caps and format lists per kind, a 20/day video quota, and the ethical precondition that rights_confirmed may only be set when the user has affirmed ownership. 'Free' and the video exception for rights_confirmed are extra operational context an agent could not infer.

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-loads the core mechanism and expiry table, then uses a structured Args/Returns layout. It is long, but with zero schema descriptions the detail is load-bearing rather than padding; a few clauses (e.g. the parenthetical MIME examples) could be trimmed without loss.

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?

There is no output schema, and the description compensates by spelling out the return shape (upload_id, method PUT vs POST, url, headers for PUT vs multipart fields for POST with file last, curl with <FILE>, expires_in_s) plus the required next step. For a multi-step upload handshake this is complete enough to invoke correctly on the first try.

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?

Schema description coverage is 0%, so the description carries the full burden and does so for all six parameters: kind with per-value limits, formats and staging targets; content_type with MIME examples; size_bytes as exact size; rights_confirmed with the exact condition under which it must be true and the kinds it applies to; project_id scoped to project_media; filename flagged as server-ignored.

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?

Opens with a specific verb+resource ('Gets a one-time signed upload URL') and immediately clarifies the unusual division of labor: the caller sends the bytes with its own HTTP client and the server never sees them. It explicitly frames the pairing with upload_finish, so the agent can tell it apart from the finish step 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 Guidelines4/5

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

Gives clear when-to-use guidance per kind (attachment staged for AI Video/Personas, song for Music Video, video into the Library, project_media needs project_id) and a when-not ('Voice uploads are not available here'). It also states the required follow-up call to upload_finish. The only gap is that it doesn't name the sibling tool that handles voice uploads instead.

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

All ViralMint tools Inspect

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

Need Help?