Skip to main content
Glama
krovacloud

@krovacloud/mcp

Official
by krovacloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Domain Settings

update_domain
Idempotent

Change a custom domain's edge proxy settings: choose origin scheme (http/https) or PROXY protocol header, and omit fields to keep current values.

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

TableJSON 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

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and openWorldHint=true, so the mutation/safety profile is covered. The description adds one trait not present in the annotations: that this is a patch-style operation where omitted settings retain their current values, and that at least one setting must be supplied. It does not restate the risk context (TLS mismatch, 409 on mixed PROXY protocol) that lives in the schema, but the annotations lower the bar.

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 with the resource named first, then the accepted settings, then the constraint. Zero filler and nothing buried.

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?

For a mutation tool with no output schema but full schema description coverage and annotations, the description supplies the patch-semantics contract an agent needs. The conflict/refusal behaviors are documented in the schema parameters rather than the description, which is acceptable but leaves the top-level entry slightly thin.

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% and both enum parameters carry rich, self-contained descriptions (defaults, failure modes, the 409 confirm flow). The description only restates the two settings at a conceptual level, so the schema does the heavy lifting and a baseline 3 is appropriate.

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?

The description names a specific verb ("Change") and resource ("a custom domain's proxy settings") and enumerates exactly the two settings it touches: origin scheme and PROXY protocol header. Against siblings like create_domain and delete_domain, the update semantics are unambiguous.

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?

It gives invocation-level guidance ("Pass at least one; a setting you leave out keeps its current value"), which clarifies partial-update behavior, but there is no when-to-use/when-not guidance or reference to alternative tools for domain configuration. Usage is implied rather than framed.

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