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 distinct action (list spaces, publish, rollback, list versions, search docs), and the publish/rollback split is clarified by descriptions. Minor overlap remains since publish and rollback both make a version live, and my_spaces vs versions are both listing tools over related resources.
Conventions are mixed: verbs (publish, rollback), bare nouns (versions, my_spaces), and one verb_noun (search_docs). Names are still readable and individually clear, but there is no predictable pattern an agent could rely on.
Five tools is a tight, focused surface that matches the hosting/publishing scope without redundancy. It is on the lean side, with only one listing tool per resource and no dedicated space-detail tool.
The core lifecycle (list, publish/create/update, version history, rollback, docs lookup) is covered, but there is no way to delete or unpublish a space, change a space's title/devices after creation, or fetch a single space's details. These are notable gaps that could leave an agent at a dead end for housekeeping tasks.
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, or any other page or project that runs in a browser, 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 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. | |
| game | No | Whether it is a game: true when it has a goal, a score, a win or a lose, false when it has none. Velven tags the space a game from it when the version goes live. Left out, Velven decides from what it sees. | |
| 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. | |
| 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 opened: on a computer, a phone or both. Required for a new space. | |
| 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 flag non-read-only, non-idempotent, open-world, non-destructive; the description goes far beyond, disclosing default preview behavior, live-within-seconds timing, the returned claim token that keeps an unlisted page, the 3 MB total limit, and that velven.json, dotfiles, dot-folders and node_modules are silently dropped (with the result naming the first 10). This is exactly the kind of consequence detail an agent needs before mutating state.
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 action, then organized by auth state and by create/update. Dense but nearly every clause carries a distinct condition; the parenthetical '(3 MB in all)' and the run of routing clauses make some sentences long, which slightly hurts scannability.
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 15-parameter tool with nested objects, the description covers the modes, limits and exclusions, and an output schema exists so return values need not be spelled out. It is silent on preview lifetime and how a preview is later promoted, which an agent deciding between preview and prod might want.
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 per-parameter meaning is already in structured data; the description still adds cross-parameter routing value — which fields select create vs. update, and which are conditional on being signed in (space) vs. not (claim). It does not add syntax or format details for the more complex fields like files or clip, leaving those to 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?
Opens with a specific verb and resource — publishing a browser game or page on Velven's hosting — and scopes the input (one HTML page or a small file set up to 3 MB). It is clearly distinguishable from siblings my_spaces, versions and rollback, which read or restore rather than publish.
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 branches on auth state (signed in = private preview by default; not signed in = unlisted page with claim token) and on mutation mode (prod: true for live). It states creation vs. update routing precisely: new space needs title and devices, update passes space when signed in or claim when not.
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 / devices / descriptionPrevious value: -"Where it can be played. Required for a new space."New value: +"Where it can be opened: on a computer, a phone or both. Required for a new space."Input schema / properties / gameAdded value: +{
+ "description": "Whether it is a game: true when it has a goal, a score, a win or a lose, false when it has none. Velven tags the space a game from it when the version goes live. Left out, Velven decides from what it sees.",
+ "type": "boolean"
+}publish2 fields changedInput schema / properties / how_madeRemoved value: -{
- "description": "How it was made, in the creator's words.",
- "maxLength": 2000,
- "type": "string"
-}Input schema / properties / typeRemoved value: -{
- "description": "What it is. Required for a new space.",
- "enum": [
- "game",
- "world",
- "tool",
- "wonder"
- ],
- "type": "string"
-}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.