Skip to main content
Glama
Sign In
verse-mcp

verse-mcp

by dev-vinayagastya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create a share link (set visibility)

create_share_link

Generate a browser link to a 3D scene you own, optionally set public, unlisted, or private visibility, and mint revocable private share tokens for controlled access.

Instructions

Get a link to a scene you own, optionally changing who can open it. visibility: 'unlisted' (default; anyone with the link), 'public', or 'private' (opens only with a secret share token). For a private scene this mints a share token and returns a link that includes it (the token is shown once; keep the returned shareId to revoke it with revoke_share_link). Share links do not expire on their own; revoke them to cut access. Needs VERSE_API_KEY set to your account token.

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": {
      "scene": "<scene>"
    },
    "name": "create_share_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
sceneYesScene id (e.g. palm-villa-0a1b2c3d4e5f), the job id returned by upload_scene, or a Verse share link.
new_tokenNoMint a fresh private share token even if the scene is not private (e.g. to hand out revocable links).
visibilityNoSet the scene's visibility first. Omit to keep it as is.
autoplay_tourNoOpen the link playing the scene's camera path (see list_camera_paths).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already say readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true, but the description adds the non-obvious operational facts: the token is shown only once, the returned shareId is needed to revoke, links persist until revoked, and VERSE_API_KEY must be set to the account token. These are exactly the mutation and auth details an agent cannot infer from the annotations.

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 scope and the visibility enum are front-loaded in the first sentence, and each following clause adds a distinct operational fact. It is dense with parentheticals, which makes it slightly harder to scan than an ideal definition, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation tool with no output schema, the description does the important work: it explains what comes back (a link plus shareId), how long it lives, and the auth requirement. Remaining gaps are the unmentioned autoplay_tour behavior and the slight tension between 'for a private scene this mints a token' and the new_token override, both of which the schema covers instead.

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; the description earns an extra point by explaining what 'private' actually means (opens only with a secret share token) and by confirming the default. It does not, however, address autoplay_tour or clarify how new_token interacts with the private-scene token minting described in the text, so coverage of the parameters it does mention is partial.

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 opens with a concrete verb and resource ('Get a link to a scene you own') and immediately states the optional scope ('changing who can open it'). It is clearly distinct from revoke_share_link and get_embed_code because it explicitly frames this as link minting with a returned shareId used for later revocation.

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?

It gives the default condition ('unlisted' default), lists the two alternatives, and routes revocation to the named sibling revoke_share_link. What is missing is an explicit statement of when to prefer this tool over get_embed_code or when a new_token mint is preferable outside the private case, so it stops short of full when/when-not guidance.

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

Deploy Server

Other Tools