karaoke-maker-3000

Create local upload

create_local_upload

Authorize a short-lived upload of the user's selected local MP3 only when the current environment can both read that file and send an outbound HTTPS PUT, such as Codex Desktop or CLI. Reading a ChatGPT attachment in a code sandbox does not establish outbound network access; prefer prepare_karaoke with native file parameters in ChatGPT. Supply the filename, exact byte size and SHA256, then stream that file with the returned PUT URL and purpose-bound headers. Ticket issuance does not mean audio was received. No OAuth credentials are needed or exposed. The completed PUT creates a free Quick draft; read it with get_karaoke, then confirm its price before starting. After a timeout or lost upload response, always call get_karaoke with the ticket's project_id before declaring failure, renewing a ticket or creating another project. If an awaiting_start draft exists, resume its current quote. An immediate not_found may precede an in-flight upload commit; briefly wait and recheck that same ID once. If still unconfirmed, report unconfirmed receipt, not server unavailability inferred from a timeout. Keep the same file and key; do not repeatedly renew tickets after an environment network denial. Does not start processing or charge funds.

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>",
      "byte_size": "<byte_size>",
      "sha256": "<sha256>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "create_local_upload"
  }
}

Input Schema

Name	Required	Default
`title`	No
`artist`	No
`sha256`	Yes
`filename`	Yes
`language`	No	auto
`byte_size`	Yes
`idempotency_key`	Yes

Output Schema

Name	Required	Description	Default
`file`	No
`error`	No
`method`	No
`headers`	No
`max_bytes`	No
`expires_at`	No
`project_id`	No
`upload_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the generic write/read/idempotency profile; the description adds the substantive behavior: ticket issuance is not receipt of audio, no OAuth credentials are needed or exposed, the completed PUT creates a free Quick draft, and nothing starts processing or charges funds. It also discloses error semantics (not_found may precede an in-flight commit, report 'unconfirmed receipt' rather than server unavailability) and a deliberate non-retry policy. Minor tension exists between the required idempotency_key and idempotentHint=false, but the description's 'keep the same file and key' framing is consistent enough that it is not a contradiction.

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 the gating condition before any procedural detail, and nearly every sentence carries decision-relevant content (preconditions, credential posture, side effects, timeout recovery). It is a dense single block with no visual breaks, so the recovery sequence is harder to scan than it needs to be, but there is little outright waste.

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 7-parameter write tool with an output schema, this covers the gaps that matter: preconditions the agent cannot verify from the schema, what the call does and does not do downstream, credential exposure, draft pricing confirmation via get_karaoke, and the exact recovery order after a failed or ambiguous upload response.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate, and it partly does: it explains that byte_size must be the exact size and sha256 is the integrity check, and it implies idempotency_key stability ('keep the same file and key'). However title, artist and language — three of the seven parameters — get no explanation at all, and no format constraints are added for the hashed/sized fields.

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 ('Authorize a short-lived upload of the user's selected local MP3') plus the exact precondition (environment can read the file and send an outbound HTTPS PUT). It explicitly names the sibling it is not for in ChatGPT ('prefer prepare_karaoke with native file parameters'), so the agent can route 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?

Gives explicit when-to-use ('Codex Desktop or CLI'), when-not ('a code sandbox reading a ChatGPT attachment does not establish outbound network access'), and the named alternative for that case. It also covers the failure path — always call get_karaoke with project_id after a timeout before renewing a ticket or creating another project — which is guidance no sibling name alone would imply.

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

All karaoke-maker-3000 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?