io.sota/mcp
REMOTE · MCP.SOTA.IO · 2 COMPONENTS · SCANNED AUG 3
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 →
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 Usability68
- 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 Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
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
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · mcp.sota.io
claude mcp add --transport http io-sota-mcp 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": {
"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.
- 2 Aug 26 +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.
- 31 Jul 26 +5
- 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
- 29 Jul 26 +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.
- 28 Jul 26 +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.
- 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 70
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 3 Aug 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 | 26 Jun 2026 | 24 Sept 2026 | RSA 4096 | SHA256-RSA | 573e37daa43f2a8f627adb0af840ee3032d |
| 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 |
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 |
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.
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.