Publish browser games, worlds, tools and other wonders built with AI to Velven's hosting, and manage them
Scored across 5 tools
Each tool targets a clearly distinct operation: listing spaces, publishing/updating, rolling back to a previous live version, searching documentation, and listing versions. There is minimal overlap; publish and rollback both affect live state but serve different intents.
Names are all lowercase and snake_case, but they mix parts of speech: nouns (my_spaces, versions), verbs (publish, rollback), and verb_noun (search_docs). The set is readable but lacks a single predictable pattern.
Five tools is well within the ideal 3–15 range and each tool covers a core operation in the hosting/publishing workflow. No tool feels redundant or out of place.
Core lifecycle actions for creating, reading, updating, and reverting are present, but there is no delete or unpublish operation, and no direct way to fetch a single space by slug. These gaps are notable for a hosting platform.
List the spaces of the signed-in Velven account: slug, title, status, whether Velven hosts it, and its page. Needs sign-in; called without it, the app asks the person to sign in to Velven.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| handle | Yes | |
| spaces | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond the annotations: the sign-in gating and the interactive sign-in prompt, which an agent must anticipate before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, the core action front-loaded before the auth caveat, with no wasted clauses. The sign-in consequence sentence is slightly wordy but carries genuine behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-param, read-only list tool with an output schema already defining the return shape, the description covers purpose and the one operational caveat (auth). Nothing essential is missing, though it does not describe result size or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4. The description's field enumeration describes output rather than input and does not conflict with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the spaces of the signed-in Velven account') and enumerates the returned fields (slug, title, status, hosting, page). It is immediately distinguishable from the sibling verbs publish, rollback, search_docs, and versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the precondition ('Needs sign-in') and the consequence of calling without it (the app prompts the person to sign in). It does not name alternative tools or when not to use this one, but for a zero-parameter account-scoped list tool the guidance given is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a browser game, world, tool or wonder on Velven's hosting, from one HTML page or a small set of files (3 MB in all). Signed in: a private preview by default, or with prod: true the next live version, live on its Velven page within seconds. Not signed in: an unlisted page, live the same way, returned with a claim token that keeps it. A new space needs title, type and devices from the person. To update a space pass space (signed in) or claim (not signed in).
| Name | Required | Description | Default |
|---|---|---|---|
| sdk | No | Add Velven's SDK script to the entry page. Default true. | |
| spa | No | Serve the entry page for any unknown path (a single-page app). | |
| clip | No | The video the tile plays on hover, without sound. Give the path of one of the files sent: an MP4 or WebM, up to 3 MB and 5 to 10 seconds long. Velven then records no clip of its own. Without a thumbnail, the clip's first frame is the picture. It must show the space itself. A clip outside that length is refused. If the file doesn't say its length, Velven measures it once live. It keeps the first 10 seconds of a longer clip, and drops a shorter one. A later version that names neither keeps the space's. | |
| html | No | A whole page as one HTML string, published as index.html. | |
| prod | No | Go live on the space's Velven page instead of making a preview. Signed in only. Default false. | |
| type | No | What it is. Required for a new space. | |
| claim | No | The claim token of an unlisted page: publishes its next version, or claims it when signed in. | |
| entry | No | The page that opens first, if not index.html. | |
| files | No | Files by relative path: text as a string, binary as { "base64": "..." }. Must include the entry page (index.html unless entry says otherwise). A velven.json, a dotfile, a dot-folder or node_modules, in any folder, is left out (never published; the result names the first 10 and counts the rest): send velven.json's settings as this tool's fields. | |
| space | No | Publish a new version of this space (yours, signed in). | |
| title | No | The space's name. Required for a new space. | |
| engine | No | What it draws with, if one of these. | |
| devices | No | Where it can be played. Required for a new space. | |
| how_made | No | How it was made, in the creator's words. | |
| thumbnail | No | The picture on the space's tile. Give the path of one of the files sent: a JPEG, PNG or WebP, up to 2 MB and 4096 pixels on each side. It's used as soon as the version is live, and Velven takes no picture of its own. It must show the space itself. | |
| description | No | One line under the name. |
| Name | Required | Description |
|---|---|---|
| space | Yes | The space's slug. |
| terms | No | The Terms line to show the person (no account). |
| reason | No | Why it was refused, naming the file when it was one. |
| status | Yes | The version's status: preview, publishing (waiting on Velven to publish it), live or refused. |
| leftOut | No | Files not published (velven.json, dotfiles, node_modules), the first 10. |
| pageUrl | Yes | The space's page on Velven. |
| version | Yes | The version this publish made. |
| claimUrl | No | Open signed in to claim the page (no account). |
| watchUrl | No | Where to follow the version on Velven. |
| expiresAt | No | When an unlisted page is deleted unless claimed (no account). |
| claimToken | No | The unlisted page's claim token, shown once (no account). |
| previewUrl | No | The private preview, for 24 hours (a preview only). |
| leftOutCount | No | How many files were left out in all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give the generic mutation/openWorld profile; the description adds the genuinely non-obvious behavior – preview-by-default versus going live within seconds, the claim token that keeps an unlisted page, and the 3 MB aggregate size limit. This is real context beyond what the structured fields already say.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and resource, and every sentence carries routing or constraint information with no filler. It is dense to the point of being hard to parse in one pass (nested conditionals crammed into one paragraph), which keeps it off a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter, nested-object tool with an output schema and full schema coverage, the description covers the publishing flow, auth modes, update paths and new-space prerequisites. Return values need not be explained because an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states only locally: the space-vs-claim branch for updating, and the title/type/devices requirements for a new space. It stops short of explaining defaults like sdk or spa, which the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (publish) and resource (a browser game, world, tool or wonder on Velven's hosting), plus scope limits (one HTML page or a small set of files, 3 MB). Reads unambiguously as a deploy/publish operation and is clearly distinct from the read/history siblings my_spaces, versions and rollback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes between modes: signed in defaults to a private preview unless prod: true, unsigned becomes an unlisted page with a claim token, new spaces require title/type/devices, and updates go through either space (signed in) or claim (unsigned). The when-to-use conditions are all stated rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an earlier version of a hosted space live again. Only a version that was live before (rollback: true in versions) can be picked; it goes live at once. Needs sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| space | Yes | The space's slug, as my_spaces or publish named it, e.g. pixel-racer. | |
| version | Yes | The version number to make live again. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| pageUrl | Yes | |
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the change takes effect immediately ('goes live at once'), the candidate set is restricted, and sign-in is required. It does not say what happens to the previously live version, but the addition is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler. The core action is front-loaded, followed by the eligibility constraint and the auth prerequisite in descending order of importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, an output schema and a complete annotation set, the description only needs to supply the human-judgment details — eligibility, immediacy, auth — and it does all three. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented (space slug, version number). The description adds eligibility semantics the schema cannot express — only versions flagged rollback: true in the versions listing are valid inputs — which meaningfully narrows how 'version' should be interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource: 'Make an earlier version of a hosted space live again.' The eligibility clause '(rollback: true in versions)' implicitly separates it from publish (which pushes a brand-new version) and versions (which lists them), so an agent can route without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a hard precondition for use — only a version that was previously live ('rollback: true') may be selected — plus the auth requirement ('Needs sign-in'). It never names an explicit alternative tool for the other case, so it stops just 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.
Search Velven's documentation: publishing and hosting, velven.json, the CLI, the SDK (sign-in, leaderboards, saves, achievements, rooms), claiming a page, the agent API and limits. Returns the best matching sections with links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many sections to return. Default 5. | |
| query | Yes | What to look up, in a few words. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered by structured data. The description adds only that results are 'best matching sections with links' — useful but thin, with no detail on relevance ranking or how results behave when nothing matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose verb+resource leads the sentence, followed by a compact topic inventory and the return shape. The long comma-separated topic list is information-dense but borders on a catalogue; still, every clause carries routing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and it briefly signals the return shape anyway. Scope is well covered for a simple two-parameter search tool; only ranking behavior is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both query and limit are already documented in the schema, including the default of 5. The topic enumeration hints at useful query phrasing but adds no syntax or format meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (Velven's documentation), then enumerates the covered topic areas (publishing, velven.json, CLI, SDK, agent API). This clearly distinguishes it from the sibling tools my_spaces, publish, rollback, and versions, which are all operations rather than documentation lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the topic list and the read-only nature of the tool, but there is no explicit statement of when to reach for this versus reading docs another way, and no exclusions. Adequate but leaves the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a hosted space's versions, newest first: number, status (uploading, preview, publishing, live, refused, unjudged, replaced), size, and whether rollback can pick it. Refused versions carry the reason. Needs sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| space | Yes | The space's slug, as my_spaces or publish named it, e.g. pixel-racer. |
| Name | Required | Description |
|---|---|---|
| space | Yes | |
| versions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true and openWorldHint=false, it discloses ordering (newest first), the full status vocabulary, that refused versions carry a reason, and that authentication is required. This is real operational context, though pagination/limits are unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and the parenthetical status list earns its space because no enum exists in the schema to convey those states.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Auth requirement, ordering, status semantics, and rollback relevance are all covered, and an output schema exists so return shapes need not be re-explained. Only pagination/volume behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single 'space' slug parameter has a pattern and example — so the schema carries the burden. The description adds nothing about the parameter, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource: 'List a hosted space's versions, newest first.' It enumerates the returned attributes (number, status, size, rollback-pickability) and implicitly distinguishes itself from the rollback sibling by flagging which versions rollback can act on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: reviewing version state and determining what rollback can pick, plus the prerequisite 'Needs sign-in'. It does not explicitly name or exclude alternatives (my_spaces, publish, search_docs), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
publish2 fields changedInput schema / properties / clip / descriptionPrevious value: -"The short muted video its tile plays on hover: the path of one of the files sent, an MP4 or WebM up to 3 MB (five seconds at 480p is right). Velven records no clip then; without a thumbnail, the clip's first frame is the picture. A later version that names neither keeps the space's."New value: +"The video the tile plays on hover, without sound. Give the path of one of the files sent: an MP4 or WebM, up to 3 MB and 5 to 10 seconds long. Velven then records no clip of its own. Without a thumbnail, the clip's first frame is the picture. It must show the space itself. A clip outside that length is refused. If the file doesn't say its length, Velven measures it once live. It keeps the first 10 seconds of a longer clip, and drops a shorter one. A later version that names neither keeps the space's."Input schema / properties / thumbnail / descriptionPrevious value: -"The space's picture on its tile: the path of one of the files sent, a JPEG, PNG or WebP up to 2 MB. It is used from the moment the version is live, instead of a picture Velven takes."New value: +"The picture on the space's tile. Give the path of one of the files sent: a JPEG, PNG or WebP, up to 2 MB and 4096 pixels on each side. It's used as soon as the version is live, and Velven takes no picture of its own. It must show the space itself."publish6 fields changedInput schema / properties / clipAdded value: +{
+ "description": "The short muted video its tile plays on hover: the path of one of the files sent, an MP4 or WebM up to 3 MB (five seconds at 480p is right). Velven records no clip then; without a thumbnail, the clip's first frame is the picture. A later version that names neither keeps the space's.",
+ "type": "string"
+}Input schema / properties / prod / descriptionPrevious value: -"Go live after the safety check instead of a preview. Signed in only. Default false."New value: +"Go live on the space's Velven page instead of making a preview. Signed in only. Default false."Input schema / properties / thumbnailAdded value: +{
+ "description": "The space's picture on its tile: the path of one of the files sent, a JPEG, PNG or WebP up to 2 MB. It is used from the moment the version is live, instead of a picture Velven takes.",
+ "type": "string"
+}Output schema / properties / reasonAdded value: +{
+ "description": "Why it was refused, naming the file when it was one.",
+ "type": "string"
+}Output schema / properties / status / descriptionPrevious value: -"The version's status: preview, checking (in the safety check) or live."New value: +"The version's status: preview, publishing (waiting on Velven to publish it), live or refused."Output schema / properties / watchUrl / descriptionPrevious value: -"Where to follow the check."New value: +"Where to follow the version on Velven."versions2 fields changedOutput schema / properties / versions / items / properties / reason / descriptionPrevious value: -"Why the check refused it."New value: +"Why Velven refused it."Output schema / properties / versions / items / properties / status / descriptionPrevious value: -"uploading, preview, checking, live, refused, unjudged or replaced."New value: +"uploading, preview, publishing, live, refused, unjudged or replaced."my_spacespublishrollbacksearch_docsversions
Add one secure layer between your agents and this server.