Xyvenra

Read or save a project

project

Destructive

Read a Cloud page, Studio source, or Mobile Expo draft this account owns. Save replaces Studio source or a Mobile draft and does not publish, start an EAS build, or charge. A Mobile save requires expectedUpdatedAt from the last get or save. Publish Cloud HTML with deploy. Code has no server-side project. Data tables and records use the database tool.

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": {
      "action": "<action>",
      "product": "<product>",
      "projectId": "<projectId>"
    },
    "name": "project"
  }
}

Input Schema

Name	Required	Description
`html`	No	Studio preview. A complete HTML document. Cloud pages are published with deploy.
`name`	No
`draft`	No	Full Mobile builder draft, version 1. A save replaces the stored draft.
`files`	No	Studio source map. index.html is required. Paths end in html, css, js, json, md, or svg.
`action`	Yes
`prompt`	No	Studio only. Up to 4,000 characters.
`product`	Yes
`projectId`	Yes
`expectedUpdatedAt`	No	Required for a Mobile save. Use updated_at from the last get or save.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The destructiveHint=true annotation is confirmed and elaborated: a save replaces Studio source or a Mobile draft, and the description adds what it does NOT do (no publish, no EAS build, no charge). The optimistic-concurrency requirement is disclosed, which is real behavioral context. It stops short of saying what happens on a stale expectedUpdatedAt or whether get returns content plus metadata.

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?

Five tight sentences, front-loaded with the read/save scope before the caveats. 'Code has no server-side project' is terse to the point of being cryptic, and the publish/deploy point is stated twice (once in prose, once inside the html field), but nothing is truly wasted.

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 9-parameter, multi-product, destructive tool with no output schema, the description covers safety, side-effect boundaries, the concurrency token, and sibling routing. Gaps remain around auth/permission requirements, conflict behavior on a stale token, and what get returns, but the core calling decisions are supported.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 56% schema description coverage, the schema already explains html, files, prompt, draft, and expectedUpdatedAt, and the description largely restates the expectedUpdatedAt rule. It does usefully imply which parameters belong to which product (html/prompt for Studio, draft for Mobile) but leaves projectId and name format undefined.

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 specific verbs (read/save) against specific resources (Cloud page, Studio source, Mobile Expo draft) and constrains scope to 'this account owns'. It also explicitly disambiguates from two siblings by declaring 'Publish Cloud HTML with deploy' and 'Data tables and records use the database tool', so an agent can route without opening another schema.

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 explicit when-to-use-elsewhere routing (deploy for publishing, database for tables/records) and an explicit exclusion (code has no server-side project). It also states a hard precondition for Mobile saves: expectedUpdatedAt from the last get or save.

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

All Xyvenra 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.

Resources

Need Help?