Utplava

Publish files

publish_files

Destructive

Puts an app online from its files, with no GitHub needed. Use this when the person has the app's files here in the chat (for example a single-page HTML app you wrote) rather than in a GitHub repository. Send every file the app needs: an index.html at the top level for a website, or a package.json for a Vite or React project. Up to 50 files and 2 MB in total; web files only (HTML, CSS, JavaScript, TypeScript, JSON, SVG, images, fonts). Never include secret keys or .env files: Utplava refuses the upload. Ask the person for keys later and save them with set_env. For a new app pass name; to update an app published this way, pass its appId and the complete new set of files (files left out are removed). Returns the app ID and deployment status; check get_status for the live address.

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": {
      "files": "<files>"
    },
    "name": "publish_files"
  }
}

Input Schema

Name	Required	Description
`name`	No	A short name for a new app, e.g. "Bakery site". Omit when passing appId.
`appId`	No	The app to update. Only apps published with publish_files can be updated this way.
`files`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the destructive/openWorld/idempotent hints, the description discloses hard limits (50 files, 2 MB), allowed file types, that secrets and .env are rejected server-side, and critically that updates replace the whole file set so omitted files are removed. It also states the return payload (app ID and deployment status) that an agent must act on.

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 opening sentence front-loads the core action, and the remaining sentences are dense with actionable constraints rather than filler. It is a long single block, but nearly every clause carries operational information; slightly better segmentation would improve scannability.

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?

For a destructive, open-world write tool with no output schema, the description covers prerequisites, limits, forbidden content, update semantics, and what is returned. An agent could call this correctly and safely without consulting anything else.

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?

With 67% schema coverage the description adds real routing meaning: name only for new apps, appId only for apps originally published this way, and files must include index.html at top level or package.json for Vite/React. It does not explain the base64 encoding switch, which is left entirely to the schema.

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?

"Puts an app online from its files, with no GitHub needed" gives a concrete verb plus resource and immediately separates it from the repository-based alternative (deploy). An agent can choose between this and deploy without inspecting either 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?

Explicit selection criteria are provided: use when the app's files are in the chat rather than in a GitHub repo. It also routes follow-on work to siblings by name — set_env for keys afterward, get_status for the live address — and states the create-vs-update condition (pass name for new, appId to update).

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

All Utplava tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?