Utplava

Deploy

deploy

Idempotent

Deploys a GitHub repository (owner/name) to Utplava. The first deploy creates the app; later calls for the same repository redeploy it. Returns the app ID, the deployment status and, once live, the app's 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": {
      "repo": "<repo>"
    },
    "name": "deploy"
  }
}

Input Schema

Name	Required	Description	Default
`repo`	Yes	GitHub repository as owner/name, e.g. "your-name/my-app".
`branch`	No	Not yet supported: the repository's default branch is always deployed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / branch / description

Previous value: -"Omit to deploy the repository's default branch — branch overrides are not yet supported."New value: +"Not yet supported: the repository's default branch is always deployed."

changedInput schema / properties / repo / description

Previous value: -"GitHub repository as owner/name, e.g. \"kp080681/my-app\"."New value: +"GitHub repository as owner/name, e.g. \"your-name/my-app\"."

First observedOct 28, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and openWorldHint=true. The description adds value beyond them by explaining the create-on-first-call / redeploy-on-later-call behavior and by describing the returned fields (app ID, status, address) despite there being no output schema. It does not cover failure modes or auth requirements, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what the tool does and the required argument, followed by lifecycle behavior and return values. Every sentence carries information; 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 two-parameter, non-destructive deploy tool with no output schema, the description covers purpose, lifecycle behavior and return values adequately. It could mention the branch caveat or typical failure conditions, but the essential calling information is present.

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?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the branch field's 'not yet supported' caveat. The description only restates the owner/name format and adds nothing about the optional branch parameter, so the baseline 3 applies.

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 a specific verb and resource (deploys a GitHub repository to Utplava) with the exact expected argument format (owner/name). It is clearly distinguishable from siblings like get_status, list_apps and set_env, which are reads or config operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clarifies the create-vs-redeploy semantics of repeated calls, which is useful context for an agent deciding whether to invoke it again. However, it gives no explicit guidance on when to use it versus siblings (e.g. deploy before or after set_env) and states no exclusions or prerequisites.

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?