Ankra

Prepare service disconnection

prepare_service_disconnection

Prepare disconnecting one application environment from a managed service that keeps running for its other applications (step one of a disconnect). It records a review and returns what the application loses - the connection variables, DATABASE_URL or another protocol's names when this service gives them - that the shared credential is not revoked and how to make sure the application can no longer authenticate, which deployed workloads read the connection Secret (those Ankra attached roll on the next deploy, those wired by hand must be changed by a person), whether the namespace loses network access to the service, and that the application keeps working until it is deployed again. Nothing changes. When the service gives the conventional names and another service of the same kind is connected, the plan lists the choices and must be prepared again with connection_names_instance_id or connection_names_none before it can be confirmed. Requires applications.deploy, clusters.operate on the service's cluster and clusters.operate and clusters.read on the application's.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "instance_id": "<instance_id>",
      "consumer_id": "<consumer_id>",
      "expected_generation": "<expected_generation>",
      "timing": "<timing>"
    },
    "name": "prepare_service_disconnection"
  }
}

Input Schema

Name	Required	Description
`timing`	Yes	When the disconnection takes effect: after_next_deploy (the application keeps working until it is deployed again). now is refused while every application of the service shares one credential.
`consumer_id`	Yes	The consumer to disconnect: its id (UUID) among the instance's consumers from get_service_instance.
`instance_id`	Yes	Service instance id (UUID) from list_service_instances.
`expected_generation`	Yes	The instance generation the user reviewed, from get_service_instance.
`keep_network_access`	No	True keeps the application's namespace admitted on the service's client port; false (the default) takes it off once no pod reads the connection.
`connection_names_none`	No	Only when the review asks for it: true when no service gives the application its conventional names from now on.
`connection_names_instance_id`	No	Only when the review asks for it: the other connected service (UUID, from connection_names.choices) that gives the application its conventional names from now on.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the tool records a review, returns what the application loses, leaves the shared credential unrevoked, identifies workloads reading the connection Secret, and explains how manually wired workloads differ from Ankra-attached ones. It also notes network-access impact and that the application keeps working until redeployed, which is substantial behavioral context for a non-read-only preparation tool.

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?

The description is front-loaded with purpose and scope, and most of its length is justified by the tool's complexity. It is dense and consists of a very long sentence with nested clauses, so structure could be improved, but there is little empty wording.

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?

For a complex preparation tool with no output schema, the description covers the review outcome, credential and Secret implications, network-access behavior, deployment timing, naming ambiguity, and required permissions. An agent has enough context to call it correctly and understand the safe, non-mutating nature of the plan.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning about the connection_names choice being surfaced by the plan and requiring a re-prepare before confirmation. It reinforces timing behavior and expected-generation review context, though most individual parameter meaning still comes from the schema.

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 states a specific verb and resource: preparing to disconnect one application environment from a managed service while the service continues for others. It explicitly frames this as step one of a disconnect and distinguishes it from the confirmation step, making the scope clear 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 Guidelines5/5

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

It explains when to use this preparation step, that it must be prepared again with connection_names_instance_id or connection_names_none when conventional names are ambiguous, and that this happens before the disconnection can be confirmed. Required permissions are also listed, giving the agent clear routing and prerequisite guidance.

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

All Ankra tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.