Multiplayer Agent

Get upload URLs for a game's files

create_upload

Upload files straight from disk instead of pasting their bytes into a tool call: for images, audio, fonts, 3D models, and ANY file over ~50 KB (a tool call can't carry megabytes of base64). Give each file's hosted path and exact size in bytes; get back one URL per file. PUT each file to its URL with curl, from the game's folder: curl -sS -T "" (Windows PowerShell: curl.exe). Each URL takes ONE PUT of exactly that many bytes and expires in 15 minutes, so upload right away. Then call publish_game with { path, uploadId } entries for these files (small text files can still go inline next to them), or deploy_room_logic with uploadId for a long logic file. An upload belongs to the game it was made for and is used up by the publish. Limits on this studio's plan: 100 files per call, 5 MB per game.

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": {
      "files": "<files>"
    },
    "name": "create_upload"
  }
}

Input Schema

Name	Required	Description	Default
`game`	No	Which game to act on: its publishable key (pk_…) or its exact name. Defaults to the x-mp-game header, then your primary game.
`files`	Yes	The files to upload.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare the generic write-ish profile (readOnlyHint=false, idempotentHint=false); the description adds the real operational behavior: each URL accepts exactly ONE PUT of exactly the declared byte count, expires in 15 minutes, is scoped to the game it was created for, and is consumed by the publish. It also states plan limits (100 files per call, 5 MB per game).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the decision rule and size threshold, then parameters, then the exact curl procedure, then constraints, then next steps and limits. Dense but every sentence carries an operational fact; the PowerShell parenthetical is a small but useful detail rather than padding.

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?

No output schema exists, and the description fully covers the return (one URL per file), the transport mechanics, expiry, consumption semantics, and follow-up calls. Nothing needed to invoke this correctly or to use its result 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 the baseline is 3, but the description reinforces why `size` must be exact (the PUT must match that byte count) and what the return is (one URL per file), which is meaningful beyond the field docs. It does not add anything about `game` or `contentType` beyond the schema.

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?

Specific verb and resource: obtain per-file upload URLs so files can be sent straight from disk. It explicitly contrasts with the inline path (pasting bytes into a tool call / small text files inline in publish_game), so the agent can tell it apart from publish_game and deploy_room_logic without opening schemas.

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 a clear trigger (images, audio, fonts, 3D models, ANY file over ~50 KB) and a clear exclusion (small text files can go inline). It also names the follow-up alternatives — publish_game with { path, uploadId } or deploy_room_logic with uploadId — so routing is unambiguous.

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

All Multiplayer Agent 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.