verse-mcp

Upload a 3D file and get a Verse link

upload_scene

Upload a 3D file from a local path or public URL and convert it into a shareable Verse link that opens in any browser.

Instructions

Upload a 3D file and turn it into a shareable Verse link that opens in any browser. source is a local file path (stdio only) or a public http(s) URL the Verse server will fetch itself (Dropbox needs dl=1, Google Drive needs 'anyone with the link', S3/R2/GCS need a presigned URL). Accepts GLB, glTF, FBX, OBJ, IFC, USD/USDZ, PLY, SPLAT and point clouds (LAS/LAZ/E57). Large local files upload in resumable parts and survive dropped connections; progress is reported as notifications. By default the call waits for the build to finish and returns the link; if the build outlasts wait_seconds it returns the job id so you can poll get_scene_status. Result: link (open in a browser), scene (id), status.

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": {
      "source": "<source>"
    },
    "name": "upload_scene"
  }
}

Input Schema

Name	Required	Description
`as`	No	Say what the file is: a 'product' (a single object) or a walkable 'interior'/'building'/'exterior'. Local uploads only; otherwise detected.
`bake`	No	Bake lighting on the server before building (for live-lit GLBs). Slower.
`kind`	No	Force the file kind when the extension is ambiguous (e.g. 'splat' for a Gaussian-splat .ply). Normally detected from the bytes.
`name`	No	Optional slug used as the scene id prefix, lowercase letters, digits, - and _.
`path`	No	'fidelity' publishes the model as-is (best for single products); 'streamed' builds a streamed scene (best for big walkable scenes). Normally decided automatically.
`source`	Yes	Local file path (e.g. ~/Models/villa.glb) or a public http(s) URL to a 3D file.
`resumable`	No	Force resumable multi-part upload (default: automatic above 100 MB). Use on flaky connections.
`visibility`	No	Set after the build finishes. Needs an account token. 'private' scenes only open with a share link from create_share_link.
`wait_seconds`	No	How long to wait for the build before returning the job id (0 = return right after upload).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations mark it as non-read-only, open-world, non-idempotent, non-destructive, but the description adds substantially more: resumable multi-part uploads that survive dropped connections, progress reported as notifications, default blocking until build completion, and the fallback to a job id. It also discloses the auth requirement for visibility and that private scenes need create_share_link.

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 core purpose and then packed with genuinely useful detail; almost every sentence carries information an agent needs. It is a single dense block rather than structured, which slightly hurts scanability.

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?

Covers the full call lifecycle for a complex 9-parameter upload/build tool: input source forms, format support, upload resilience, wait semantics, polling fallback, and even the return fields (link, scene, status) despite having no output schema.

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 already 100%, so the baseline is 3; the description still adds real meaning for `source` by explaining the provider-specific URL requirements (dl=1, sharing settings, presigned URLs) that the schema does not capture. Other params (as, kind, path, wait_seconds) are left to the schema's own descriptions.

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+resource+outcome: upload a 3D file and turn it into a shareable Verse link that opens in any browser. It is clearly distinct from siblings like get_scene_status or create_share_link, and even names the supported formats.

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 concrete routing: if the build outlasts `wait_seconds`, poll get_scene_status instead; `wait_seconds=0` returns right after upload. Also gives per-provider source requirements (Dropbox dl=1, Google Drive 'anyone with the link', S3/R2/GCS presigned URL) and notes visibility needs an account token. No explicit when-not-to-use case, so a 4 rather than a 5.

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

Deploy Server