@krovacloud/mcp

Official

by krovacloud

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Attach Domain

create_domain

Attach a custom domain to a Cube, route it to an in-Cube port, and get the DNS records required to activate it.

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

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

Behavior5/5

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

Annotations only declare the generic profile (not read-only, not destructive, not idempotent, open-world), yet the description adds the operationally critical behavior: the call returns the domain plus required DNS records, the domain is non-functional until those records exist, record counts differ for subdomains vs wildcards, and grey-cloud is mandatory on Cloudflare or certificate issuance fails. That is exactly the kind of consequence-level detail annotations cannot convey.

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

Conciseness4/5

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

Purpose is front-loaded in the first clause, followed by return-value notes and then the failure modes, which is a sensible order. It is dense and every sentence carries information, though the Cloudflare/certificate sentence could be tightened slightly.

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

Completeness5/5

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

There is no output schema, and the description explicitly covers what is returned (domain plus DNS records) and what the agent must do with it. For a 7-parameter mutation with a 409 edge case already documented in the schema, this is complete enough to call correctly.

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 coverage is 100% and the schema itself thoroughly documents port, originScheme, proxyProtocol, and confirmMixedProxyProtocol, so the description does not need to compensate. It adds only indirect color (port routing, record implications) and never clarifies any individual parameter beyond what the schema states, so the baseline of 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?

"Attach a custom domain to a Cube, routing it to an in-Cube port" gives a specific verb (attach), resource (custom domain), and target (in-Cube port), which distinguishes it cleanly from siblings like update_domain, list_domains, and create_tcp_mapping. An agent can pick this over the alternatives without opening the schema.

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

Usage Guidelines3/5

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

The description gives strong post-call guidance (relay the DNS records verbatim, CNAME vs three records for wildcards, grey-cloud requirement) but never states when to choose this over update_domain or delete_domain, nor any prerequisites for calling it. Usage context is implied by the verb but no explicit alternatives or exclusions are named.

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