Skip to main content
Glama
Sign In
@krovacloud/mcp

@krovacloud/mcp

Official
by krovacloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Domain Settings

update_domain
DestructiveIdempotent

Change a custom domain's proxy settings—origin scheme (HTTP/HTTPS) and PROXY protocol header—while omitted values stay unchanged.

Instructions

Change a custom domain's proxy settings: the origin scheme (the transport the edge uses to reach the Cube) and the PROXY protocol header. Pass at least one; a setting you leave out keeps its current value.

Input Schema

NameRequiredDescriptionDefault
cubeIdYesThe Cube id to operate on.
spaceIdNoKrova Cloud Space id. Optional if KROVA_SPACE_ID is set as the server default.
mappingIdYesThe domain mapping id (see list_domains).
originSchemeNoScheme 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.
proxyProtocolNoPROXY 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.
confirmMixedProxyProtocolNoSet 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.

  1. Changed4 schema fields changedv0.3.11
    • 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"
+}
    • changedInput schema / required
      Previous value: -[
-  "cubeId",
-  "mappingId",
-  "originScheme"
-]New value: +[
+  "cubeId",
+  "mappingId"
+]
  2. First observedv0.3.6

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely carried for it. The description adds the genuinely new partial-update behavior (omitted fields retain current values), but omits the highest-stakes trait — the change is applied with no validation and can take the domain offline until reverted — which lives only in the schema.

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?

Two tight sentences: the first names the operation and its scope, the second states the partial-update contract. Nothing is padded and the most decision-relevant fact (which settings change) is front-loaded.

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

Completeness3/5

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

For a destructive, open-world mutation with six parameters and no output schema, the description covers intent and partial-update semantics but leaves the workflow-critical bits — that omitted settings persist, that confirmMixedProxyProtocol may be required after a 409, and that a bad value breaks the domain immediately — to the schema text.

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%, so enum meanings, defaults, port derivation, and the confirmMixedProxyProtocol escape hatch are all documented in the schema itself. The description only restates that originScheme and proxyProtocol are the updatable fields and adds nothing about confirmMixedProxyProtocol or spaceId, 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?

"Change a custom domain's proxy settings" gives a specific verb, a specific resource, and names the exact two settings in scope (origin scheme and PROXY protocol header). No sibling tool in the list does this — create_domain/delete_domain are clearly different operations — so an agent can discriminate 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?

"Pass at least one; a setting you leave out keeps its current value" establishes partial-update semantics, which is real guidance an agent would otherwise have to guess. It does not state prerequisites (domain must already exist, obtain mappingId via list_domains) or the mixed-PROXY 409 retry path, which are only found in the parameter descriptions.

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

Deploy Server

Other Tools