kinsta_tools_force-https_setSet the Force HTTPS status for a Kinsta environment to enforce secure connections, redirect to primary domain, or disable it.
Set the Force HTTPS status for an environment.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| env_id | Yes | The environment ID |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The openWorldHint=true annotation signals potential side effects, but the description adds no context about consequences—e.g., whether changing status affects existing redirects, takes time to propagate, or impacts primary-domain routing. The distinct meanings of ENABLED_FOR_ALL vs ENABLED_REDIRECT_TO_PRIMARY are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that is front-loaded and free of filler. It is efficient, though it could be expanded to carry more value without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 and only 50% schema coverage, the description is too thin. The critical enum semantics and side effects are unexplained, leaving an agent under-equipped to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%—only env_id has a description. The type parameter has an enum but no explanation of what each value does, and the description does not compensate by clarifying the enum semantics, which is the core decision an agent must make.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Set) plus resource (Force HTTPS status) and scope (an environment), making the action clear. It distinguishes itself from the sibling kinsta_tools_force-https_get via the verb, though it doesn't name that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the get counterpart or how the three enum states should be chosen. An agent must infer the appropriate usage entirely from the enum names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.