@krovacloud/mcp

Official

Overview Schema Source Related Servers Discussions Admin

Attach Domain

create_domain

Attach a custom domain to a Cube and route it to an in-Cube port. Returns the domain and required DNS records; publish them verbatim for the domain to work.

Instructions

Attach a custom domain to a Cube, routing it to an in-Cube port. Returns the domain AND the DNS records the user must publish — tell them the records verbatim, host and value, because the domain does nothing until those exist. An ordinary subdomain needs one CNAME; a wildcard needs three. Any record with mustBeGrey must be DNS-only (grey cloud) on Cloudflare; a proxied one hides the record and certificate issuance fails.

Input Schema

TableJSON Schema

Name	Required	Description
`port`	Yes	The in-Cube port to route to.
`cubeId`	Yes	The Cube id to operate on.
`domain`	Yes	The domain name to attach (e.g. app.example.com).
`spaceId`	No	Krova Cloud Space id. Optional if KROVA_SPACE_ID is set as the server default.
`originScheme`	No	Scheme the edge speaks to the Cube on. "http" (default) is cleartext. Use "https" only when the Cube terminates TLS itself — a control panel holding its own certificate, or an app listening on HTTPS — because such an app answers plain HTTP with a redirect and cannot be reached over cleartext. Visitors are on HTTPS either way. The dial port is derived: https on the default port 80 connects on 443. Applied as saved, with no check: if nothing in the Cube answers HTTPS for this domain, visitors get an error page until it is set back to http.
`proxyProtocol`	No	PROXY protocol header the edge sends at the start of every connection to the Cube, naming the visitor, so an app reads the visitor's address from the connection itself (as on a plain VPS) instead of X-Real-IP / X-Forwarded-For. "v1" is a line of text, "v2" is binary, "off" (the default) sends none. The app must accept PROXY protocol on this port before it is turned on, or every request to the domain fails; it is applied as saved, with no check. Every domain on the same Cube port needs the same setting: a save that would mix them is refused with 409 unless confirmMixedProxyProtocol is true.
`confirmMixedProxyProtocol`	No	Set true only when the user confirms that the app handles both settings on this port (or is mid-migration): it lets a save go ahead that leaves domains on the same Cube port with different proxyProtocol settings. The 409 that asks for it names the other domains; relay them before asking.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.11Sep 30, 2026

addedInput schema / properties / confirmMixedProxyProtocol

Added value: +{
+  "description": "Set true only when the user confirms that the app handles both settings on this port (or is mid-migration): it lets a save go ahead that leaves domains on the same Cube port with different proxyProtocol settings. The 409 that asks for it names the other domains; relay them before asking.",
+  "type": "boolean"
+}

changedInput schema / properties / originScheme / description

Previous value: -"Scheme the edge speaks to the Cube on. \"http\" (default) is cleartext. Use \"https\" only when the Cube terminates TLS itself — a control panel holding its own certificate, or an app listening on HTTPS — because such an app answers plain HTTP with a redirect and cannot be reached over cleartext. Visitors are on HTTPS either way. The dial port is derived: https on the default port 80 connects on 443. Verified against the Cube before it is applied; if the domain does not serve, the route is left on http."New value: +"Scheme the edge speaks to the Cube on. \"http\" (default) is cleartext. Use \"https\" only when the Cube terminates TLS itself — a control panel holding its own certificate, or an app listening on HTTPS — because such an app answers plain HTTP with a redirect and cannot be reached over cleartext. Visitors are on HTTPS either way. The dial port is derived: https on the default port 80 connects on 443. Applied as saved, with no check: if nothing in the Cube answers HTTPS for this domain, visitors get an error page until it is set back to http."

addedInput schema / properties / proxyProtocol

Added value: +{
+  "description": "PROXY protocol header the edge sends at the start of every connection to the Cube, naming the visitor, so an app reads the visitor's address from the connection itself (as on a plain VPS) instead of X-Real-IP / X-Forwarded-For. \"v1\" is a line of text, \"v2\" is binary, \"off\" (the default) sends none. The app must accept PROXY protocol on this port before it is turned on, or every request to the domain fails; it is applied as saved, with no check. Every domain on the same Cube port needs the same setting: a save that would mix them is refused with 409 unless confirmMixedProxyProtocol is true.",
+  "enum": [
+    "v1",
+    "v2",
+    "off"
+  ],
+  "type": "string"
+}

First observedv0.3.6Sep 5, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare this is a non-idempotent mutation (readOnlyHint=false, idempotentHint=false). The description adds substantial context beyond that: the tool returns DNS records the caller must relay verbatim, the domain is inert until those exist, and a proxied record breaks certificate issuance. It omits the idempotency implication (re-calling creates another attempt) and any auth/permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, all load-bearing: purpose first, then return payload, then the operational requirement, then the failure-mode caveat. No filler and the critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by explaining the returned domain and DNS records. Combined with the safety annotations and 100% schema coverage, an agent has enough to invoke it correctly, though permission prerequisites and duplicate-call behavior remain unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema itself documents every parameter including the nuanced originScheme, proxyProtocol, and confirmMixedProxyProtocol notes. The description reinforces the port-routing concept but adds no syntax or format detail the schema lacks, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Attach a custom domain to a Cube, routing it to an in-Cube port') and immediately identifies its return payload. An agent can distinguish this from update_domain, delete_domain, and get_domain_records without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong conditional guidance: subdomain vs wildcard record counts, and the Cloudflare grey-cloud requirement that selects between DNS-only and proxied. However, it never names the sibling alternatives (e.g. update_domain to modify an existing domain) or states explicit when-not conditions, so routing between siblings is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Attach Domain

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools