Skip to main content
Glama
kychee-com

run402-mcp

by kychee-com
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

up

Plan or run the full app-aware deploy workflow from a local path or repo URL, handling missing setup steps like wallet, tier, project, and workspace link 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dirNoWorkspace directory to inspect when source is omitted.
yesNoApprove non-interactive prerequisite, spend, and local-write prompts.
nameNoProject/app instance name, for example kysigned2.
tierNoBootstrap tier if account readiness is needed.
sourceNoLocal app directory or public Git repository URL. Defaults to the current directory.
dry_runNoPlan only. No gateway mutation, build execution, release commit, local link write, or prune.
manifestNoExplicit manifest path. Defaults to run402.json, then advanced release-only manifests.
build_modeNoOverride app build mode.
project_idNoExisting project id to install into.
allow_pruneNoApprove destructive managed-resource prune steps.
no_rehearseNoSkip 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_nameNoDisplay 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_usdNoMaximum spend up may approve for readiness steps.
idempotency_keyNoRoot idempotency key for resumable app-up graph mutations.
allow_shell_buildNoApprove shell-string build commands after review.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
resultNo
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses plan-vs-run behavior, automatic setup steps (wallet, tier, project, workspace link), delegation to the SDK, and the shared result envelope. It does not spell out all side effects such as spend, local writes, or destructive prune, but these are surfaced through parameter descriptions, and the overall mutating/deploying nature is clear.

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 sentences with no filler: the first states the action and scope, the second explains return contents, and the third draws a clear boundary against `deploy`. It is well front-loaded and every sentence earns its place.

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 15-parameter tool with an output schema and complete parameter documentation, the description provides the essential overview, source input options, setup/deploy behavior, and return envelope. It does not cover every behavioral edge case, but those are adequately documented in the schema; only a small amount of extra context about plan-only invocation would make it fully complete.

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%, and the individual parameter descriptions are rich. The tool description adds only high-level contextual grouping like 'missing setup (wallet, tier, project, workspace link)', which maps to parameters but does not add detailed semantics beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Plan or run the canonical app-aware run402 up workflow'. It also specifies the input source ('local path or repo URL'), what the workflow includes (missing setup + deploy), and differentiates from the sibling `deploy` by noting that 'deploy only deploys'.

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 clearly frames `up` as the full setup-plus-deploy workflow and distinguishes it from `deploy` with 'deploy only deploys'. This gives an agent enough to choose between the two, though it does not explicitly mention when to prefer other siblings like `status` or `doctor`. The guidance is present but not exhaustive.

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

Deploy Server

Other Tools