io.sota/mcp
REMOTE · MCP.SOTA.IO · 2 COMPONENTS · SCANNED SEP 20
EU-native PaaS for AI agents — deploy web apps with one sentence, managed Postgres, GDPR by default.
Available components
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. How we score → Why this is hard to score →
Endpoint Security89
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- 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. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability70
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the io.sota/mcp server?
io.sota/mcp is a hosted endpoint at https://mcp.sota.io/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.
remote · mcp.sota.io
claude mcp add --transport http io-sota-mcp 'https://mcp.sota.io/mcp'
{
"mcpServers": {
"io-sota-mcp": {
"url": "https://mcp.sota.io/mcp"
}
}
} {
"servers": {
"io-sota-mcp": {
"type": "http",
"url": "https://mcp.sota.io/mcp"
}
}
} [mcp_servers.io-sota-mcp] url = "https://mcp.sota.io/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"io-sota-mcp": {
"type": "remote",
"url": "https://mcp.sota.io/mcp",
"enabled": true
}
}
} openclaw mcp add io-sota-mcp --url 'https://mcp.sota.io/mcp' --transport streamable-http
mcp_servers:
io-sota-mcp:
url: "https://mcp.sota.io/mcp" {
"McpServers": {
"io-sota-mcp": {
"Transport": "http",
"Url": "https://mcp.sota.io/mcp"
}
}
} assistant mcp add io-sota-mcp -t streamable-http -u 'https://mcp.sota.io/mcp'
{
"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.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 26 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Aug 26 +1
- Stability: 0.97 → pass security
- 23 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 0
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Probed https://mcp.sota.io/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=sota.io | CN=YR1,O=Let's Encrypt,C=US | 25 Aug 2026 | 23 Nov 2026 | RSA 4096 | SHA256-RSA | 58bfe6372334bac45942e849b82d91c4c84 |
| SANs: *.sota.io, sota.io | ||||||
| CN=YR1,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | a20253f15f2691c05dc1ce13b9bcca4e |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.sota.io. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| io. | present | 57355 | 8 | Verified |
| sota.io. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer realm="https://mcp.sota.io", error="missing_token", resource_metadata="https://mcp.sota.io/.well-known/oauth-protected-resource"
Bearer realm="https://mcp.sota.io", error="missing_token", resource_metadata="https://mcp.sota.io/.well-known/oauth-protected-resource" Protected resource metadata
| Document | https://mcp.sota.io/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://mcp.sota.io |
| Authorisation server | https://mcp.sota.io/auth/v1 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.sota.io/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.sota.io/mcp | HTTPS enforced | 301 | https://mcp.sota.io/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add-domain ~168
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.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name to add (e.g. "app.example.com" or "example.com") |
| project_id | string | yes | Project ID (UUID) to add the domain to. Use list-projects to find the ID |
No output schema declared.
No examples provided.
create_account ~261
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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | – | The 6-digit code from the confirmation email. Provide on the second call to complete signup. Omit on the first call. |
| string | yes | A real email address. We send the confirmation code here. Throwaway / disposable email services are blocked. |
No output schema declared.
No examples provided.
create-project ~407
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Name for the new project. A URL slug will be auto-generated (e.g. "My Cool App" becomes my-cool-app.sota.io) |
No output schema declared.
No examples provided.
delete-project ~83
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.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | Project ID (UUID) to delete. Use list-projects to find the ID |
No output schema declared.
No examples provided.
deploy ~818
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…
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | yes | Project ID (UUID) to deploy to. Use list-projects to find the ID. |
No output schema declared.
No examples provided.
get-domain ~105
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.
| Name | Type | Req | Description |
|---|---|---|---|
| domain_id | string | yes | Domain ID (UUID). Use list-domains to find the ID |
| project_id | string | yes | Project ID (UUID). Use list-projects to find the ID |
No output schema declared.
No examples provided.
get-env ~75
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.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | Project ID (UUID) |
No output schema declared.
No examples provided.
get-logs ~164
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).
| Name | Type | Req | Description |
|---|---|---|---|
| deployment_id | string | – | Specific deployment ID (optional, defaults to latest). Use get-status to see recent deployment IDs |
| project_id | string | yes | Project ID (UUID) to get logs for |
No output schema declared.
No examples provided.
get-status ~124
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.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | Project ID (UUID) to check status for. Use list-projects to find the ID |
No output schema declared.
No examples provided.
list-domains ~78
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.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | Project ID (UUID) to list domains for. Use list-projects to find the ID |
No output schema declared.
No examples provided.
list-projects ~107
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).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
remove-domain ~93
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.
| Name | Type | Req | Description |
|---|---|---|---|
| domain_id | string | yes | Domain ID (UUID). Use list-domains to find the ID |
| project_id | string | yes | Project ID (UUID). Use list-projects to find the ID |
No output schema declared.
No examples provided.
rollback ~94
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.
| Name | Type | Req | Description |
|---|---|---|---|
| project_id | string | yes | Project ID (UUID) to rollback. Use list-projects to find the ID |
No output schema declared.
No examples provided.
set-env ~230
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.
| Name | Type | Req | Description |
|---|---|---|---|
| key | string | yes | Environment variable name (e.g., STRIPE_KEY, REDIS_URL, API_SECRET). Do NOT set DATABASE_URL — it is auto-managed |
| project_id | string | yes | Project ID (UUID) |
| value | string | yes | Environment variable value. Will be encrypted at rest |
No output schema declared.
No examples provided.
What is the io.sota/mcp server?
io.sota/mcp is listed in the public MCP registry as io.sota/mcp. EU-native PaaS for AI agents, deploy web apps with one sentence, managed Postgres, GDPR by default. This page covers its hosted endpoint (https://mcp.sota.io/mcp).
Is the io.sota/mcp server safe to use?
io.sota/mcp scores 90 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 io.sota/mcp server expose?
io.sota/mcp exposes 14 tools: create_account, list-projects, create-project, delete-project, deploy, and 9 more. Their descriptions and schemas cost roughly 2,807 tokens of context every time the server is loaded.
Does the io.sota/mcp server require authentication?
Yes. io.sota/mcp 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 io.sota/mcp server still maintained?
io.sota/mcp is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.