# run.zero (remote · api.run-zero.de)

Deploy apps, APIs and Postgres from your AI agent. EU PaaS hosted in Germany, OAuth sign-in.

- Trust score: 79/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `api.run-zero.de`: 79/100 (this document), [markdown](https://verifymcp.io/servers/de-run-zero-mcp/api.md), [page](https://verifymcp.io/servers/de-run-zero-mcp/api)

## Channel facts

- Endpoint: `https://api.run-zero.de/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `1.0.2`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 94/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 74/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6408 tokens (~128/item across 50 items; 50 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 97/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 7 of 8 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "runzero_deploy_preview" implies "deploy" and declares readOnlyHint instead, contradicting what its own name says it does.
  - An AI judge read all 51 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.

## Install

### How do I install the run.zero MCP server?

run.zero is a hosted endpoint at https://api.run-zero.de/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http de-run-zero-mcp 'https://api.run-zero.de/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "de-run-zero-mcp": {
      "url": "https://api.run-zero.de/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "de-run-zero-mcp": {
      "type": "http",
      "url": "https://api.run-zero.de/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.de-run-zero-mcp]
url = "https://api.run-zero.de/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "de-run-zero-mcp": {
      "type": "remote",
      "url": "https://api.run-zero.de/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add de-run-zero-mcp --url 'https://api.run-zero.de/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  de-run-zero-mcp:
    url: "https://api.run-zero.de/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "de-run-zero-mcp": {
      "Transport": "http",
      "Url": "https://api.run-zero.de/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add de-run-zero-mcp -t streamable-http -u 'https://api.run-zero.de/mcp'
```

### Other

```json
{
  "mcpServers": {
    "de-run-zero-mcp": {
      "type": "http",
      "url": "https://api.run-zero.de/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 79, +41)

- [security improvement] Transport: unverified → pass
- [security improvement] Injection markers: unverified → pass
- [security] First check of Judged manipulation: pass
- [security] Authorization: Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Tool coverage: unverified → 100
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: excellent
- [functional] First check of Schema quality: fail
- [functional] First check of Destructive annotations: 88
- [functional] First check of Tool coverage: 100

### 2026-11-04 (score 38)

First indexed and scored.

## MCP tools (50)

### `runzero_get_help` (~91 tokens)

Platform help

Look up structured guidance on platform concepts and conventions. Topics: workflow, files, addons, procfile, domains. Call this whenever you need to understand addons, the Procfile/PORT convention, or the typical workflow for a new app. Returns markdown.

Input parameters:

- `topic` (string): One of: workflow, files, addons, procfile, domains. Omit to get a list of available topics.

### `runzero_list_apps` (~54 tokens)

List apps

List the apps the authenticated user has access to (own + collaborated), newest first — one compact row each (name, slug, url, kind, status, flags). Details of one app: runzero_get_app.

### `runzero_get_app` (~55 tokens)

Get app details

Get one app: slug, status, publish mode, services (URL, replicas, health, env var NAMES), addons, domains. Secret values are never returned.

Input parameters:

- `name` (string, required): Name of the app

### `runzero_create_app` (~165 tokens)

Create app

Create a new app. Optionally links to a Git repository — if no repo is given, you can attach one later.

Input parameters:

- `branch` (string): Git branch (default: main)
- `companionOf` (string): Name/slug of an existing app this one is a companion of (e.g. a preview or staging environment, or an A/B variant). The new app reuses the parent's repo and joins a shared project so the two show up…
- `name` (string, required): App name (3-30 chars, lowercase, letters/numbers/hyphens)
- `repo` (string): Git repository URL (https://github.com/org/repo)

### `runzero_list_templates` (~95 tokens)

List templates

List the curated template library: finished, deployed page designs (landing pages, shops, portfolios …) that can be adopted as the starting point of a NEW app instead of building from scratch. Each entry has a live URL and a screenshot URL plus kind/industries/tags for matching. Adopting a matching template is far cheaper and better-looking than writing a page from zero — check here FIRST on any first build.

### `runzero_adopt_template` (~133 tokens)

Create app from template

Create a NEW app as a full copy of a template from runzero_list_templates: app + repo + running instance, owned by the caller. Use this INSTEAD of runzero_create_app when a template matches the request, then adapt the copy (texts, colors, images — placeholder assets keep their paths and get overwritten). The copy provisions asynchronously; follow with runzero_wait_for_build as usual.

Input parameters:

- `name` (string): Name for the new app (short kebab-case, derived from the subject)
- `sourceSlug` (string, required): Slug of the template (from runzero_list_templates)

### `runzero_list_services` (~42 tokens)

List services

List the services (runtime processes) of an app with their build source, port, replicas and status.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_get_logs` (~86 tokens)

Get service logs

Get the runtime log output of one service (stdout/stderr of its running containers), last N lines.

Input parameters:

- `app` (string, required): Name of the app
- `service` (string, required): Name of the service
- `tail` (integer): Number of log lines (default: 60 — the error is in the last lines; raise only if they do not explain it)

### `runzero_get_metrics` (~93 tokens)

Get service metrics

CPU and memory usage of a service over a time window (default last hour). Returns per-pod current/min/max/avg — CPU in millicores, memory in MiB — not raw time series, to stay compact.

Input parameters:

- `app` (string, required): Name of the app
- `range` (string): Time window (default: 1h)
- `service` (string, required): Name of the service

### `runzero_screenshot` (~238 tokens)

Screenshot live page

SEE the deployed page with your own eyes: renders the live URL in a real browser and returns fresh screenshots as images — desktop (1280×800) and/or mobile (390×844). Use it after runzero_wait_for_build to review the visual result like a designer would (spacing, contrast, overlaps, broken mobile layout) and fix what you SEE, not what you assume. Never cached; but the rollout of a fresh build lands ~30-90s after build success, so a screenshot taken too early shows the previous version — if it looks unchanged, wait briefly and call again.

Input parameters:

- `app` (string, required): Name of the app
- `fullPage` (boolean): Render the whole page height (capped at 3200px) instead of the first screen, so sections further down are in the picture too (default: false)
- `path` (string): Page path to render, e.g. '/impressum' (default: '/')
- `service` (string): Service name (optional if the app has exactly one)
- `viewport` (string): Which widths to render (default: both)

### `runzero_rebuild_service` (~78 tokens)

Rebuild service

Rebuild a service from the latest commit of its repo branch; on success the new version rolls out to the live URL. Use after an external repo changed; pushes via runzero_push_files rebuild on their own.

Input parameters:

- `app` (string, required): Name of the app
- `service` (string, required): Name of the service to rebuild

### `runzero_delete_app` (~64 tokens)

Delete app

Permanently delete an app with all its services, addons (including database data), secrets and domains. Irreversible: only on an explicit request, and name the app back to the user before calling.

Input parameters:

- `name` (string, required): Name of the app to delete

### `runzero_deploy` (~123 tokens)

Deploy app

Deploy an app. Fetches the repo and checks for run-zero.yaml (or the older itdone.yaml). If found, syncs all services + addons + domains from config. If not, deploys the repo as a single service. Services missing from the config are scaled to 0; with prune=true they are DELETED. Run runzero_deploy_preview first to see the diff.

Input parameters:

- `app` (string, required): Name of the app
- `prune` (boolean): Delete services not present in config (default: false → scale to 0 instead)

### `runzero_deploy_preview` (~45 tokens)

Preview deploy changes

Preview what a deploy would change without making any changes. Use this before runzero_deploy to verify the diff.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_add_service` (~153 tokens)

Add service

Add a new service to an app. Clones the repo, builds with buildpacks, and deploys. The web process must listen on $PORT.

Input parameters:

- `app` (string, required): Name of the app
- `branch` (string): Git branch (default: main)
- `git_token` (string): GitHub PAT for private repos
- `name` (string, required): Service name (3-30 chars, lowercase)
- `path` (string): Subdirectory inside the repo for monorepo builds
- `port` (integer): Container port to expose (default: 8080)
- `replicas` (integer): Replica count (default: 1)
- `repo` (string, required): Git repository URL

### `runzero_delete_service` (~89 tokens)

Delete service

Permanently delete one service of an app: its running containers, its public URL and its configuration. Irreversible, and it also deletes the persistent volume of the service with all its backups; to only stop it, scale it to 0 with runzero_scale_service.

Input parameters:

- `app` (string, required): Name of the app
- `service` (string, required): Name of the service to delete

### `runzero_scale_service` (~104 tokens)

Scale service

Set the replica count of a service (0-10). Scaling to 0 takes the service offline (its URL stops answering) without deleting it; scale up again to bring it back. A service with a persistent volume runs 0 or 1 replicas and keeps its data at 0.

Input parameters:

- `app` (string, required): Name of the app
- `replicas` (integer, required): Replica count (0-10)
- `service` (string, required): Name of the service

### `runzero_volume_status` (~90 tokens)

Volume status

Show the persistent volume of a service: mount path, size, last backup, the backups that can be restored, and the state of a running or last restore. Volumes are declared under `volumes:` in run-zero.yaml (runzero_get_help topic files).

Input parameters:

- `app` (string, required): Name of the app
- `service` (string): Service name (default: the only service)

### `runzero_backup_volume` (~75 tokens)

Back up volume

Start a backup of the persistent volume now, on top of the automatic daily one. The service keeps running. It runs in the background; runzero_volume_status lists it once it is finished.

Input parameters:

- `app` (string, required): Name of the app
- `service` (string): Service name (default: the only service)

### `runzero_restore_volume` (~121 tokens)

Restore volume

Replace the data on the persistent volume with a backup. The service stops, the current data is backed up first, the backup is unpacked, and the service starts again. Takes minutes; follow it with runzero_volume_status (`restore.phase` ends at `done`, with `error` if it failed and the data stayed unchanged).

Input parameters:

- `app` (string, required): Name of the app
- `backupId` (string, required): Id of the backup, from runzero_volume_status
- `service` (string): Service name (default: the only service)

### `runzero_set_secrets` (~100 tokens)

Set secrets

Set one or more environment variables for an app or a specific service. Existing keys are overwritten; other keys are preserved. Affected services are redeployed automatically.

Input parameters:

- `app` (string, required): Name of the app
- `secrets` (object, required): Key/value pairs. Keys must start with a letter and contain only letters, numbers, and underscores.
- `service` (string): Scope secrets to a single service. Omit for app-wide secrets.

### `runzero_list_secrets` (~44 tokens)

List secret names

List the secret keys for an app (values are never returned). Includes both app-wide and per-service secrets.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_delete_secret` (~67 tokens)

Delete secret

Delete a single secret from an app or a service. Affected services are redeployed automatically.

Input parameters:

- `app` (string, required): Name of the app
- `key` (string, required): Secret key to delete
- `service` (string): Service scope. Omit for app-wide secrets.

### `runzero_list_builds` (~67 tokens)

List builds

List recent build records for an app. Returns kpack Build status (success/failed/running) per service. To WAIT for a build to finish, use runzero_wait_for_build instead of calling this in a loop.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_list_versions` (~135 tokens)

List versions

Earlier versions of a service that can be put back online, newest first. Each entry has an `image` (pass it to runzero_activate_version or runzero_preview_version), when it was built, and `summary` — the commit message, i.e. what changed. `active: true` marks what is online now. Use this when the user refers to an earlier state ("wie gestern", "vor der Umgestaltung"). Omit `service` when the app has only one.

Input parameters:

- `app` (string, required): Name of the app
- `service` (string): Service name (default: the only service)

### `runzero_preview_version` (~139 tokens)

Preview earlier version

Show an earlier version under a SECOND address without touching the live site — use this whenever the user wants to look before deciding. Returns a url; the pod needs a few seconds, so a first request may fail — retry once. Pass `stop: true` (without `image`) to tear the preview down again; it costs nothing once stopped.

Input parameters:

- `app` (string, required): Name of the app
- `image` (string): Image of the version to show, from runzero_list_versions
- `service` (string): Service name (default: the only service)
- `stop` (boolean): Remove the preview instead of creating one

### `runzero_work_url` (~116 tokens)

Get preview link

The URL where this app's UNPUBLISHED changes can be looked at, and a link that opens it (the plain hostname refuses without one). Call this after EVERY change to an app that publishes on request, and give the user the link with a plain sentence: their change is on the preview, their real site is untouched, and it goes live when they say so. Without that sentence they look at their own website, see nothing, and conclude the change was lost.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_list_releases` (~105 tokens)

List releases

What the user has PUBLISHED, newest first, with the sentence they described each change with, and which one visitors see right now. This is the list to use when someone says "wie letzte Woche" or "vor der Umgestaltung" — not runzero_list_versions, which lists every build including the platform's own bookkeeping commits and is unreadable for a person. Also reports whether something is built and waiting.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_publish` (~141 tokens)

Publish changes

Put the waiting changes on the real site — this is what VISITORS see, so only ever on an explicit request ("mach das live", "veröffentliche das"), never on your own initiative after finishing a change. Write `description` in the user's own words and in their language ("Tag der offenen Tür angekündigt"), because that sentence is what they will read next month when they want to go back. Only for apps that publish on request; an app that publishes automatically has nothing to publish.

Input parameters:

- `app` (string, required): Name of the app
- `description` (string, required): What changed, in the user's words — shown in their version list

### `runzero_restore_release` (~123 tokens)

Restore release

Put an earlier published state back on the real site. Use the id from runzero_list_releases. This CHANGES what visitors see. It does not touch the code: anything changed since is still there and still waiting, so this undoes what is published, not the work. If the user wants an announcement removed rather than the whole site rolled back, edit the page instead — going back also removes every other change made since.

Input parameters:

- `app` (string, required): Name of the app
- `release` (integer, required): Release id from runzero_list_releases

### `runzero_set_publish_mode` (~111 tokens)

Set publish mode

Switch between publishing every change immediately (auto) and collecting changes on a preview until the user releases them (manual). Explain the consequence before switching to manual: from then on nothing reaches their visitors until they say so, which is the point but also a way to wonder for days why a change never appeared. Switching back to auto publishes whatever was waiting, immediately.

Input parameters:

- `app` (string, required): Name of the app
- `mode` (string, required): auto = live at once, manual = release first

### `runzero_activate_version` (~177 tokens)

Activate version

Put an earlier version back online — this CHANGES what visitors see. Only do this when the user explicitly asks to go back; never on your own initiative after a failed build (fix the code instead). While an older version is active, new builds are built but NOT published, until you call this again with image "latest". If the service has a database, the container goes back but the data does not — say so and pass acknowledge_data only after the user confirms.

Input parameters:

- `acknowledge_data` (boolean): Required when the service has an addon: confirms the database is not rolled back
- `app` (string, required): Name of the app
- `image` (string, required): Image from runzero_list_versions, or "latest" to follow new builds again
- `service` (string): Service name (default: the only service)

### `runzero_wait_for_build` (~242 tokens)

Wait for build

Wait server-side until the newest build of an app is finished AND the new version is serving traffic — use this INSTEAD of polling runzero_list_builds, sleeping, or re-checking the site in a loop. Blocks up to 45 seconds per call and returns {status: "success" | "failed" | "running", phase, rollout, builds}. "running" with phase "building" or "rolling-out" means: call it again. A rollout follows every successful build by 30-90 s, and until it lands the live URL, curl and screenshots still show the OLD version — do not push a fix for what you see in that window. "success" with phase "live" means every pod serves the new build; phase "done" means built but not live for a reason named in `hint` (the app publishes on request, an older version is pinned, not deployed yet). On "failed", read runzero_get_build_logs with the failed build id.

Input parameters:

- `app` (string, required): Name of the app
- `service` (string): Only wait for this service (default: all services)

### `runzero_get_build_logs` (~104 tokens)

Get build logs

Get the full log stream for a specific build (all kpack steps concatenated). Use runzero_list_builds first to find the build id.

Input parameters:

- `app` (string, required): Name of the app
- `build_id` (string, required): Build id from runzero_list_builds
- `tail` (integer): Number of log lines from the END (default: 120). A failed build explains itself in its last lines; raise only if they do not.

### `runzero_push_files` (~414 tokens)

Push files

Push changes into the app's Git repository as ONE atomic commit (create, patch, and delete in a single push). CHANGING an existing file? Use `edits` — an exact-snippet replacement, like your editor's edit tool. Use `files` only to create a NEW file or to genuinely rewrite one end to end: it resends the whole document, so a twelve-line change costs you the entire file. Both may appear in the same push (different paths). If the app has no repository yet, a platform-managed repo is created automatically on the first push. Text files only (UTF-8) — for binary assets (icons, images, fonts) NEVER attempt to inline the bytes; models cannot generate valid binary data. Instead use runzero_upload_assets (the user uploads via the dashboard) or set sourceUrl on a file entry (the server downloads it from the web). IMPORTANT: after the FIRST push on a fresh app, run runzero_deploy once — it creates the service(s) from the repo (single service from the root, or several from a run-zero.yaml). Later pushes rebuild existing services automatically. See runzero_get_help topic 'files' for the full flow, code layout rules and the run-zero.yaml format. Only works with platform-managed repositories, not external repos. `deletions` and `files` overwrite or remove files in the repo; earlier content stays in the Git history.

Input parameters:

- `app` (string, required): Name of the app
- `deletions` (array): File paths to delete from the repo
- `edits` (array): Patches to existing files — the cheap way to change code. Applied in order; several edits may target the same file and are applied one after another.
- `files` (array): Files to create or rewrite completely. To change part of an existing file use edits instead.
- `message` (string): Commit message
- `trigger_build` (boolean): Trigger a build after pushing (default: true)

### `runzero_list_files` (~58 tokens)

List files

List all files in the app's Git repository (platform-managed repos only). Optionally filter by path prefix.

Input parameters:

- `app` (string, required): Name of the app
- `path` (string): Path prefix filter (e.g. src/)

### `runzero_read_file` (~138 tokens)

Read file

Read a file from the app's Git repository (platform-managed repos only), UTF-8. Returns at most 250 lines per call (a note at the end says how to continue) — read the part you need with startLine/endLine instead of the whole file; every returned line is paid for on every later step.

Input parameters:

- `app` (string, required): Name of the app
- `endLine` (integer): Last line to return (default: startLine + 249)
- `path` (string, required): File path within the repo
- `startLine` (integer): First line to return (1-based, default 1)

### `runzero_upload_assets` (~91 tokens)

Get asset upload link

Get the dashboard upload link for an app so the USER can upload binary assets (icons, images, fonts) via drag & drop — real bytes, nothing travels through the model. Give the returned URL to the user, wait until they confirm the upload, then call runzero_list_files with path 'assets/' and reference the files in the code.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_list_users` (~50 tokens)

List app users

List the end-users of an app's login realm (requires the app's keycloak addon). Returns id, username, email and enabled state.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_create_user` (~93 tokens)

Create app user

Create an end-user in the app's login realm. Returns the generated password ONCE if none is given — relay it to the user, it cannot be retrieved later.

Input parameters:

- `app` (string, required): Name of the app
- `email` (string): Email address
- `password` (string): Initial password (generated if omitted)
- `username` (string, required): Username (letters, digits, . _ -)

### `runzero_delete_user` (~76 tokens)

Delete app user

Permanently delete an end-user (account, sessions, login data) from the app's login realm. Irreversible; to only block the login use runzero_set_user_enabled.

Input parameters:

- `app` (string, required): Name of the app
- `user_id` (string, required): Keycloak user id (from runzero_list_users)

### `runzero_reset_user_password` (~80 tokens)

Reset app user password

Replace an end-user's password in the app's login realm; the old one stops working at once. Returns the new password ONCE (generated if none given).

Input parameters:

- `app` (string, required): Name of the app
- `password` (string): New password (generated if omitted)
- `user_id` (string, required): Keycloak user id

### `runzero_set_user_enabled` (~75 tokens)

Enable or block app user

Enable or disable (block) an end-user in the app's login realm. A disabled user cannot log in but is not deleted.

Input parameters:

- `app` (string, required): Name of the app
- `enabled` (boolean, required): true = enable, false = block
- `user_id` (string, required): Keycloak user id

### `runzero_list_identity_providers` (~48 tokens)

List login providers

List external login providers (Google, GitHub, …) configured on the app's login realm. Secrets are never returned.

Input parameters:

- `app` (string, required): Name of the app

### `runzero_create_identity_provider` (~209 tokens)

Add login provider

Add an external login provider (Google, GitHub, Microsoft, generic OIDC/SAML) to the app's login realm, so end-users can sign in with it. You need an OAuth client id/secret from the provider first. IMPORTANT: the response contains a redirect URI that the user must register in the provider's OAuth app — surface it to them. For generic 'oidc' also pass authorization_url and token_url.

Input parameters:

- `alias` (string, required): Short id, e.g. "google" (lowercase, digits, -)
- `app` (string, required): Name of the app
- `authorization_url` (string): Generic OIDC only
- `client_id` (string, required): OAuth client id from the provider
- `client_secret` (string, required): OAuth client secret from the provider
- `display_name` (string): Button label shown on the login page
- `provider_id` (string, required): Provider type
- `token_url` (string): Generic OIDC only

### `runzero_generate_image` (~152 tokens)

Generate image

Generate an image with AI (FLUX) and commit it into the app's repo. Costs credits. Use for hero images, backgrounds, illustrations. The file is committed at the given path (e.g. assets/hero.jpg), replacing a file already there, and a rebuild is triggered; reference it in the code afterwards. The prompt is sent to Black Forest Labs (EU endpoint).

Input parameters:

- `app` (string, required): Name of the app
- `aspect_ratio` (string): Aspect ratio (default: 16:9)
- `path` (string, required): Target path in the repo, e.g. assets/hero.jpg (.png for PNG)
- `prompt` (string, required): What the image should show

### `runzero_db_query` (~158 tokens)

Run SQL query

Run one SQL statement against an app's PostgreSQL addon (owner/admin only). Read-only by default: the statement runs in a READ ONLY transaction that is rolled back. With allow_write=true it CAN WRITE: INSERT/UPDATE/DELETE and DDL (DROP, ALTER, TRUNCATE) are committed immediately and cannot be undone. Before setting allow_write, show the user the exact SQL and get their explicit confirmation. Results are capped at 1000 rows; statements time out after 15s.

Input parameters:

- `allow_write` (boolean): Must be true for INSERT/UPDATE/DELETE/DDL; default false = read-only
- `app` (string, required): Name of the app
- `sql` (string, required): A single SQL statement

### `runzero_describe_addon` (~65 tokens)

Describe addon

Show exactly which environment variables an addon injects into an attached service, straight from the platform (the source of truth — use this instead of guessing env var names). Call it BEFORE writing code that reads addon credentials.

Input parameters:

- `type` (string, required): Addon type

### `runzero_get_legal_profile` (~90 tokens)

Get legal profile

Get the user's saved legal profile (their Impressum details: name/company, address, contact, and for a company the representative, register and VAT id). Read this BEFORE asking the user for Impressum data, so you reuse what they already gave and only ask for what is missing. Returns the profile (or null) and imprintReady = whether it has the §5 DDG minimum.

### `runzero_set_legal_profile` (~216 tokens)

Save legal profile

Save or update the user's legal profile so it is reused across their apps and the legal pages can be regenerated. Send only what the user actually provided; omitted fields are cleared. NEVER invent legal data.

Input parameters:

- `city` (string): City
- `country` (string): ISO country code, default DE
- `email` (string): Contact e-mail
- `entityType` (string): 'person' or 'company'
- `legalName` (string): Name or company incl. legal form
- `phone` (string): Contact phone (optional)
- `postalCode` (string): Postal code
- `registerCourt` (string): Register court (company)
- `registerNumber` (string): Register number (company)
- `represented` (string): Represented by / Geschäftsführer (company)
- `street` (string): Street + house number
- `supervisoryAuthority` (string): Chamber / supervisory authority (regulated trades)
- `vatId` (string): VAT id / USt-IdNr., if any

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/de-run-zero-mcp/api#diagnostics

## Score history

- 2026-11-05: 79
- 2026-11-04: 38

## Common questions

### What is the run.zero MCP server?

run.zero is an MCP server listed in the public MCP registry as de.run-zero/mcp. Deploy apps, APIs and Postgres from your AI agent. EU PaaS hosted in Germany, OAuth sign-in. This page covers its hosted endpoint (https://api.run-zero.de/mcp).

### Is the run.zero MCP server safe to use?

run.zero scores 79 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the run.zero MCP server expose?

run.zero exposes 50 tools: runzero_get_help, runzero_list_apps, runzero_get_app, runzero_create_app, runzero_list_templates, and 45 more. Their descriptions and schemas cost roughly 5,678 tokens of context every time the server is loaded.

### Does the run.zero MCP server require authentication?

Yes. run.zero asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the run.zero MCP server still maintained?

run.zero is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://api.run-zero.de/mcp
- Repository: https://github.com/getitdone-gmbh/run-zero-mcp
- Website: https://run-zero.de/en/features/mcp
- Changelog RSS feed: https://verifymcp.io/servers/de-run-zero-mcp/api.xml
- Changelog JSON feed: https://verifymcp.io/servers/de-run-zero-mcp/api.json
- HTML version of this page: https://verifymcp.io/servers/de-run-zero-mcp/api