# io.sota/mcp (remote · mcp.sota.io)

EU-native PaaS for AI agents — deploy web apps with one sentence, managed Postgres, GDPR by default.

- Trust score: 78/100 (medium)
- Change this week: +8
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.sota.io`: 78/100 (this document), [markdown](https://verifymcp.io/servers/io-sota-mcp/mcp.md), [page](https://verifymcp.io/servers/io-sota-mcp/mcp)
- npm · `@sota-io/mcp`: 35/100, [markdown](https://verifymcp.io/servers/io-sota-mcp/sota-io-mcp.md), [page](https://verifymcp.io/servers/io-sota-mcp/sota-io-mcp)

## Channel facts

- Endpoint: `https://mcp.sota.io/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.5.0`

## 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-08-03.

- **Endpoint Security**: 89/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.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - 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**: 68/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2807 tokens (~200/item across 14 items; 14 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **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.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http io-sota-mcp https://mcp.sota.io/mcp
```

### Codex

```toml
[mcp_servers.io-sota-mcp]
url = "https://mcp.sota.io/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "io-sota-mcp": {
      "type": "remote",
      "url": "https://mcp.sota.io/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add io-sota-mcp --url https://mcp.sota.io/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  io-sota-mcp:
    url: "https://mcp.sota.io/mcp"
```

### Other

```json
{
  "mcpServers": {
    "io-sota-mcp": {
      "type": "http",
      "url": "https://mcp.sota.io/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-08-02 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 77, +5)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 72, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 70, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 70)

First indexed and scored.

## MCP tools (14)

### `create_account` (~261 tokens)

Sign up for a brand-new sota.io account from inside Claude — no browser, no copy-paste. Two-step flow:

STEP 1: Call with just `email`. We send a 6-digit confirmation code to that email.
STEP 2: Call again with `email` + `code`. We verify, create the account on the Free tier (3 projects, EU-hosted, no credit card), generate a sota.io API key, and return it to you.

After Step 2 you'll get back a key like `sota_…`. **Save it in a safe place** — you'll need it for any subsequent sota.io tool call in Claude (or you can use it with the sota CLI). It is shown ONCE and never recoverable.

sota.io is an EU-native PaaS hosted in Germany — GDPR-compliant by default, no CLOUD Act exposure. Disposable / throwaway email addresses are not accepted; use a real address.

Input parameters:

- `code` (string): The 6-digit code from the confirmation email. Provide on the second call to complete signup. Omit on the first call.
- `email` (string, required): A real email address. We send the confirmation code here. Throwaway / disposable email services are blocked.

### `list-projects` (~107 tokens)

List all projects on your sota.io account. sota.io is an EU-native DevOps PaaS hosted in Germany (GDPR-compliant). Each project gets a live URL at {slug}.sota.io with automatic HTTPS, a managed PostgreSQL 17 database (DATABASE_URL auto-injected), PgBouncer connection pooling, daily backups, zero-downtime blue-green deployments, gVisor container isolation, and custom domain support (up to 5 per project with automatic HTTPS).

### `create-project` (~407 tokens)

Create a new project on sota.io. Each project automatically provisions: (1) a managed PostgreSQL 17 database accessible via the DATABASE_URL environment variable (auto-injected, no configuration needed), (2) PgBouncer connection pooling (pool size 20, max 100 clients), (3) automatic daily database backups with 7-day retention, (4) a live URL at https://{slug}.sota.io with automatic HTTPS via Let's Encrypt. The project slug is auto-generated from the name (lowercase, hyphens, max 63 chars) and is immutable after creation. Supported frameworks: Next.js, Node.js (Express/Fastify/Koa), Python (Flask/FastAPI/Django), or any language via custom Dockerfile. You can also add up to 5 custom domains per project with automatic HTTPS (via API: POST /v1/projects/:id/domains with {domain: "yourdomain.com"}). DNS: A record to 23.88.45.28 for apex domains, CNAME to {slug}.sota.io for subdomains.

Optionally associate the project with a public git repository at create-time by passing `git_url` (and optional `git_branch`). The association is informational — it shows up in the dashboard and the `sota deploy --git` CLI flag can default to it — but does NOT enable auto-deploy-on-push yet.

Input parameters:

- `git_branch` (string): Optional branch name (defaults to the repository default branch when omitted). Only meaningful when `git_url` is also set.
- `git_url` (string): Optional git repository URL to associate with this project (https://, git://, ssh://, or git@host:path). Informational only — does not trigger an automatic deploy.
- `name` (string, required): Name for the new project. A URL slug will be auto-generated (e.g. "My Cool App" becomes my-cool-app.sota.io)

### `delete-project` (~83 tokens)

Delete a project and all its deployments from sota.io. This action is PERMANENT and irreversible. It removes the project, all deployments, the managed PostgreSQL database, environment variables, and webhooks. The project slug will become available again after deletion.

Input parameters:

- `project_id` (string, required): Project ID (UUID) to delete. Use list-projects to find the ID

### `deploy` (~818 tokens)

Deploy an application to sota.io. The platform auto-detects your framework and builds a Docker image automatically:

\- Next.js: Detected via next.config.js/ts. Add output: 'standalone' to next.config for optimal builds.
\- Node.js: Detected via package.json with a "start" script. Works with Express, Fastify, Koa, Hapi, etc.
\- Python: Detected via requirements.txt or pyproject.toml. Works with Flask, FastAPI, Django.
\- Custom Dockerfile: If a Dockerfile exists in the project root, it takes priority over auto-detection. Use this for Go, Rust, Java, or any other language. The EXPOSE directive in the Dockerfile is used to detect the app port automatically.

THREE WAYS to supply the source code — pick EXACTLY ONE:

1\. **files** (inline source from AI):
   Pass a map of relative paths to UTF-8 text content. Best when you've just
   generated a small app in this conversation and want to deploy it without
   any filesystem step. Up to 200 files, 10 MB total. Include
   the framework manifest (package.json, requirements.txt, or Dockerfile)
   so auto-detection works.

2\. **git_url** (clone a public repo):
   Pass an https://, git://, ssh://, or git@host:path URL. We shallow-clone
   it (--depth=1 --single-branch) on the server and deploy. Optional
   git_branch picks a non-default branch. Only public repos are supported in
   v1. Max 200 MB after clone.

3\. **directory** (local filesystem):
   Pass an absolute path. Only works when the MCP client has filesystem
   access (Claude Code / CLI; not Claude.ai web). Defaults to the current
   working directory when omitted.

IMPORTANT: Your app MUST listen on the PORT environment variable. For auto-detected frameworks (Next.js, Node.js, Python) PORT is 8080. For custom Dockerfiles, the port is auto-detected from the EXPOSE directive (e.g. EXPOSE 3000 sets PORT=3000). If no EXPOSE is found, it defaults to 8080.

Every project includes a managed PostgreSQL 17 database. Six environment variables are auto-injected into your container…

Input parameters:

- `directory` (string): Absolute path to a local directory (only useful when the MCP client has filesystem access — e.g. Claude Code). Defaults to the current working directory when no other mode is given. Mutually exclusiv…
- `files` (object): Map of relative file paths to UTF-8 text content. Use when generating an app inline (e.g. from a Claude.ai web conversation). Include a framework manifest so auto-detection works. Mutually exclusive…
- `git_branch` (string): Optional branch name when using git_url. Defaults to the repository default branch.
- `git_url` (string): Public git repository URL to clone (https://, git://, ssh://, or git@host:path). Mutually exclusive with files and directory.
- `project_id` (string, required): Project ID (UUID) to deploy to. Use list-projects to find the ID.

### `get-logs` (~164 tokens)

Get build and runtime logs for a deployment. If no deployment_id is provided, returns logs for the latest deployment. Use this after calling deploy to monitor build progress and diagnose failures. Logs include: framework detection output, dependency installation, build steps, container startup, and health check results. If a deployment fails, check the logs for error details — common issues include missing dependencies, build errors, or the app not listening on the correct PORT (check the PORT env var — 8080 for auto-detected frameworks, or the EXPOSE value from Dockerfile).

Input parameters:

- `deployment_id` (string): Specific deployment ID (optional, defaults to latest). Use get-status to see recent deployment IDs
- `project_id` (string, required): Project ID (UUID) to get logs for

### `set-env` (~230 tokens)

Set an environment variable for a project. Variables are encrypted at rest (AES-256-GCM) and injected at container runtime. NOTE: DATABASE_URL, PGHOST, PGPORT, PGUSER, PGPASSWORD, and PGDATABASE are all auto-injected for the managed PostgreSQL database — you do NOT need to set any of them manually. The PORT variable is auto-managed: 8080 for auto-detected frameworks (Next.js, Node.js, Python), or auto-detected from the Dockerfile EXPOSE directive for custom Dockerfile builds. IMPORTANT: Changing env vars does NOT auto-redeploy. You must call deploy or use the redeploy API endpoint to apply changes. For Next.js apps, NEXT_PUBLIC_* variables must be set BEFORE deploying since they are embedded at build time.

Input parameters:

- `key` (string, required): Environment variable name (e.g., STRIPE_KEY, REDIS_URL, API_SECRET). Do NOT set DATABASE_URL — it is auto-managed
- `project_id` (string, required): Project ID (UUID)
- `value` (string, required): Environment variable value. Will be encrypted at rest

### `get-env` (~75 tokens)

List environment variables for a project. Values are masked for security. Auto-injected variables (DATABASE_URL, PGHOST, PGPORT, PGUSER, PGPASSWORD, PGDATABASE, PORT) may not appear in this list but are always available in the container at runtime.

Input parameters:

- `project_id` (string, required): Project ID (UUID)

### `rollback` (~94 tokens)

Rollback a project to its previous deployment. This instantly swaps the container image without rebuilding — the previous image is reused for near-instant rollback. Uses the same blue-green strategy for zero downtime. The database is NOT rolled back (data persists across deployments). Use this when a deployment introduces bugs or breaks the app.

Input parameters:

- `project_id` (string, required): Project ID (UUID) to rollback. Use list-projects to find the ID

### `get-status` (~124 tokens)

Get the current deployment status for a project, including the live URL (https://{slug}.sota.io), detected framework, and recent deployment history. Deployment statuses: pending (queued), building (build in progress), built (image ready), deploying (starting container + health checks), running (live and healthy), failed (build or health check error), stopped (replaced by newer deployment). Use this to verify a deployment succeeded after calling deploy.

Input parameters:

- `project_id` (string, required): Project ID (UUID) to check status for. Use list-projects to find the ID

### `add-domain` (~168 tokens)

Add a custom domain to a sota.io project. Each project supports up to 5 custom domains with automatic HTTPS via Let's Encrypt. Returns DNS setup instructions: for apex domains (example.com), add an A record pointing to 23.88.45.28; for subdomains (app.example.com), add a CNAME record pointing to {slug}.sota.io. Domain statuses: pending (waiting for DNS) → verified (SSL provisioning) → active (live with HTTPS). After DNS is configured, verification and SSL provisioning happen automatically.

Input parameters:

- `domain` (string, required): Domain name to add (e.g. "app.example.com" or "example.com")
- `project_id` (string, required): Project ID (UUID) to add the domain to. Use list-projects to find the ID

### `list-domains` (~78 tokens)

List all custom domains for a sota.io project. Shows domain name, status (pending/verified/active), and ID for each domain. Use get-domain with a domain ID to see DNS instructions and full details.

Input parameters:

- `project_id` (string, required): Project ID (UUID) to list domains for. Use list-projects to find the ID

### `get-domain` (~105 tokens)

Get details of a custom domain including its current status and DNS setup instructions. Domain statuses: pending (DNS not yet configured), verified (DNS confirmed, SSL provisioning), active (live with HTTPS). If status is 'pending', configure the DNS record as shown in the instructions.

Input parameters:

- `domain_id` (string, required): Domain ID (UUID). Use list-domains to find the ID
- `project_id` (string, required): Project ID (UUID). Use list-projects to find the ID

### `remove-domain` (~93 tokens)

Remove a custom domain from a sota.io project. This removes the domain mapping and its SSL certificate. The DNS records at your registrar are NOT automatically removed — clean those up manually. This action is immediate and irreversible.

Input parameters:

- `domain_id` (string, required): Domain ID (UUID). Use list-domains to find the ID
- `project_id` (string, required): Project ID (UUID). Use list-projects to find the ID

## Diagnostics

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

## Score history

- 2026-08-03: 78
- 2026-08-02: 78
- 2026-08-01: 77
- 2026-07-31: 77
- 2026-07-30: 72
- 2026-07-29: 72
- 2026-07-28: 71
- 2026-07-27: 70
- 2026-07-26: 70

## Links

- Remote endpoint: https://mcp.sota.io/mcp
- Repository: https://github.com/sota-deploy/mcp-server
- Changelog RSS feed: https://verifymcp.io/servers/io-sota-mcp/mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/io-sota-mcp/mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/io-sota-mcp/mcp