run402-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUN402_WALLET | No | Active named wallet (profile). Overridden by --wallet <name> and per-directory .run402.json; RUN402_PROFILE is an alias. | default |
| RUN402_API_BASE | No | API base URL (override for staging) | https://api.run402.com |
| RUN402_CONFIG_DIR | No | Local credential storage base directory (named wallets live under profiles/<name>/) | ~/.config/run402 |
| RUN402_ALLOWANCE_PATH | No | Custom allowance file path | {config_dir}/allowance.json |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| upA | Plan or run the canonical app-aware |
| deployA | Unified apply primitive. Accepts a structured ReleaseSpec — database (migrations + expose), value-free secrets.require/delete declarations, functions, site, site.public_paths, site.embedding (framing opt-in by catalog key, e.g. { frame_ancestors: ['localhost'] }; null = deny), site.sign_in_path (the app's own same-origin sign-in page for MCP authorization, e.g. '/join'; null = hosted page), subdomains, and routes.replace web routes — with explicit replace vs patch semantics per resource. Migration entries use id for immutable versioned SQL or name for generated/idempotent content-tracked SQL; name compiles client-side to _<sha256(sql)[0:16]>. Use site.public_paths for clean static URLs such as /events backed by release asset events.html; explicit mode does not expose /events.html unless separately declared, while mode: 'implicit' restores filename-derived reachability and can widen access. Route entries map exact/final-wildcard browser paths like /admin and /admin/* to Node 22 Fetch Request -> Response functions, or exact GET/HEAD method-aware static aliases such as /events to { type: 'static', file: 'events.html' }; acknowledge an intentionally read-only GET/HEAD wildcard function route with allow_warning_codes: ['WILDCARD_ROUTE_EXCLUDES_MUTATION_METHODS']. Direct /functions/v1/:name remains API-key protected. Secret values are set first with |
| statusA | The organization's state as this server's wallet sees it (r.status()): the wallet's local_label, server_label, and address, the tier and its lease, the allowance, the projects, and the active project. Never key material. Any other operation is a |
| whoamiA | The remote identity (r.orgs.whoami()): the control-plane principal this server's wallet resolves to, its active authenticator and linked identities, its org memberships, and the sign-in session grade (none for a wallet). For the local wallet use status. Any other operation is a |
| doctorB | Local health and configuration diagnostics (r.doctor()): { ok, blocking[], warnings[], checks[] }, the same report as |
| docsA | The SDK reference for |
| runA | Run a TypeScript snippet against the SDK in a sandbox. |
| expand_resultA | Fetch more of a result a previous tool showed you only a window of. Tools on this surface truncate the VIEW, never the DATA: when one prints a ref together with shown and total, the full result is held behind that ref and this is how you read the rest of it. Pass the ref plus offset and limit to page through it. Refs live in this server process only — they expire after 30 minutes and only the most recent handful are kept, so re-run the producing tool rather than storing a ref across sessions. A result that carried a secret is never retained and never has a ref, so nothing here can hand one back. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
The main overlaps are `up` vs `deploy` and `whoami` vs `status`, but descriptions explicitly clarify their boundaries: `up` handles setup plus deploy, `deploy` only deploys, `whoami` covers remote identity, and `status` covers local wallet/org state. `docs` and `run` are related but distinct, and `expand_result`/`doctor` are clearly separate, leaving only minor room for confusion.
Names are mostly lowercase CLI-style tokens (`up`, `whoami`, `deploy`, `status`, `docs`, `doctor`, `run`), but they mix verbs, nouns, and an adverb, and `expand_result` uses snake_case while the rest are single words. There is no predictable verb_noun pattern across the set.
Eight tools is well-scoped for a deployment/control-plane MCP: core workflows, identity/state inspection, diagnostics, documentation, result expansion, and a generic SDK escape hatch each have a clear role. Nothing feels redundant or missing at the count level.
The universal `run` tool provides broad SDK coverage, and `up`, `deploy`, `whoami`, `status`, and `doctor` cover the main lifecycle paths. However, direct secret-management operations and some one-time-secret flows are unavailable or require CLI fallback, which is a minor but real gap.