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), site.noindex (true = X-Robots-Tag: noindex, nofollow, nosnippet on every response of the host; false or null = indexable), 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 |
| doctorA | 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
Deploy and up both perform deployments, differing only in whether setup is auto-completed, so an agent must read carefully to pick between them. Status, whoami, and doctor are also three overlapping read-only state views (local wallet vs remote principal vs diagnostics), and all of them plus most other operations are reachable through run, creating multiple routes to the same result. Descriptions do draw the lines explicitly, which keeps it from being worse.
Names mix bare verbs (deploy, run), bare nouns (status, whoami, doctor, docs), an adverb-ish workflow name (up), and one snake_case compound (expand_result). Individual names are readable, but there is no predictable convention an agent could extrapolate from.
Eight tools is a healthy scope for a deployment platform and nothing feels padded. The only quibble is that status, whoami, and doctor are thin convenience wrappers that run/docs already cover, so a couple of slots are low-value rather than bloated.
Core lifecycle is covered: plan/setup (up), apply (deploy), inspect (status/whoami/doctor), reference (docs), and an arbitrary SDK escape hatch (run) plus pagination (expand_result). Rollback, release listing, and secret management are not first-class tools, but the run snippet surface plus CLI pointers make them reachable, so gaps are workable rather than blocking.