run402-mcp

Overview Schema Source Related Servers Discussions Admin

up

Plan or run an app-aware deployment workflow from a local path or repository URL, handling missing wallet, tier, project, and workspace configuration before deploying.

Instructions

Plan or run the canonical app-aware run402 up workflow from a local path or repo URL: any missing setup (wallet, tier, project, workspace link), then the deploy. Delegates to the SDK and returns the shared up result envelope with graph steps, resources, diagnostics, and next_actions. deploy only deploys.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "up"
  }
}

Input Schema

Name	Required	Description
`dir`	No	Workspace directory to inspect when source is omitted.
`yes`	No	Approve non-interactive prerequisite, spend, and local-write prompts.
`name`	No	Project/app instance name, for example kysigned2.
`tier`	No	Bootstrap tier if account readiness is needed.
`source`	No	Local app directory or public Git repository URL. Defaults to the current directory.
`dry_run`	No	Plan only. No gateway mutation, build execution, release commit, local link write, or prune.
`manifest`	No	Explicit manifest path. Defaults to run402.json, then advanced release-only manifests.
`build_mode`	No	Override app build mode.
`project_id`	No	Existing project id to install into.
`allow_prune`	No	Approve destructive managed-resource prune steps.
`no_rehearse`	No	Skip the automatic rehearsal. By default a migration-bearing deploy against a project with a live release is rehearsed on a contained branch and committed only on a passing report; a first deploy has nothing to protect and commits directly, and a plan whose migrations are all already applied with an identical checksum is not rehearsed either (result.deploy.rehearsal says which: no_live_release / migrations_unchanged / no_migrations).
`display_name`	No	Display name to set on this principal (promotion credit and room presence use it); overrides an existing name. Omitted: RUN402_AGENT_NAME when set (same effect); else, only when the principal has no name yet, the detected client name (claude-code, codex, cursor, or grok; RUN402_CLIENT=<name> declares one that is not auto-detected) is set and reported as identity.source "detected"; otherwise nothing is written (identity.source "undetected", room presence 'agent' for coordination only). A detected client that was not applied is still reported under identity.detected / identity.detection.
`max_spend_usd`	No	Maximum spend up may approve for readiness steps.
`idempotency_key`	No	Root idempotency key for resumable app-up graph mutations.
`allow_shell_build`	No	Approve shell-string build commands after review.

Output Schema

Name	Required	Description	Default
`error`	No
`result`	No
`status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv4.126.1Oct 22, 2026

addedOutput schema / properties / error / properties / diagnostics

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "column": {
+        "type": "integer"
+      },
+      "line": {
+        "type": "integer"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "line",
+      "column",
+      "code",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / error / properties / diagnostics_ref
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / error / properties / diagnostics_total
```
Added value: +{
+  "type": "integer"
+}
```

AddedSep 25, 2026

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the tool may perform missing setup steps (wallet, tier, project, workspace link), then deploy, and returns a result envelope with graph steps, resources, diagnostics, and next_actions. However, it does not itself flag mutation, spend approval, destructive prune behavior, or rehearsal semantics, which are important for a 15-parameter mutating workflow.

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?

The description is three tight sentences. It front-loads the main workflow, then explains the result envelope, then closes with the `deploy` distinction. Nothing is 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?

Given the high parameter count, full schema description coverage, and an output schema, the description provides enough context to understand the tool's role and output shape. It could do more to summarize the approval and safety implications of parameters like `yes`, `allow_prune`, and `max_spend_usd`, but the schema is rich enough that the omission is not severe.

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 the parameter semantics are already fully documented in the input schema. The description adds workflow context and mentions local path or repo URL, but it does not add meaning beyond the schema for the individual parameters.

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?

The description states a specific verb and resource: planning or running the canonical app-aware `run402 up` workflow from a local path or repo URL. It explicitly distinguishes this from `deploy` by saying `deploy` only deploys, which is the key sibling differentiation.

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

Usage Guidelines4/5

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

It gives clear context for when this tool is appropriate: when setup may be missing and the full app-aware up workflow should run, ending in deploy. It explicitly names `deploy` as the narrower alternative, but does not discuss when to use other siblings like `run` or `status`.

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

Deploy Server

up