PixelFlow

Disconnect integration

disconnect_integration

DestructiveIdempotent

Disconnect an integration such as Stripe or Calendly from a site and return which one was removed. Its webhook is removed and its events stop being sent to ad platforms. Reconnecting is done from the dashboard. Use it when the user asks to stop sending conversions from that integration.

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": {
      "site_id": "<site_id>",
      "integration_id": "<integration_id>"
    },
    "name": "disconnect_integration"
  }
}

Input Schema

Name	Required	Description	Default
`site_id`	Yes	Site to act on, as returned by list_sites.
`integration_id`	Yes	Integration id: the `trigger_id` of an integration row in list_triggers.

Output Schema

Name	Required	Description
`type`	Yes	Integration name, such as stripe.
`disconnected`	Yes	Whether the integration was removed. Always true on success.
`integration_id`	Yes	Id of the removed integration.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 2, 2026

changedInput schema / properties / integration_id / description

Previous value: -"Integration id from list_triggers"New value: +"Integration id: the `trigger_id` of an integration row in list_triggers."

changedInput schema / properties / integration_id / type
```
Previous value: -"number"New value: +"integer"
```

removedInput schema / properties / site

Removed value: -{
-  "description": "Domain, id, or external id from list_sites",
-  "type": "string"
-}

addedInput schema / properties / site_id

Added value: +{
+  "description": "Site to act on, as returned by list_sites.",
+  "type": "integer"
+}

changedInput schema / required

Previous value: -[
-  "site",
-  "integration_id"
-]New value: +[
+  "site_id",
+  "integration_id"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "disconnected": {
+      "description": "Whether the integration was removed. Always true on success.",
+      "type": "boolean"
+    },
+    "integration_id": {
+      "description": "Id of the removed integration.",
+      "type": "integer"
+    },
+    "type": {
+      "description": "Integration name, such as stripe.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "disconnected",
+    "integration_id",
+    "type"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds valuable behavioral detail beyond them: the webhook is removed, events stop being sent to ad platforms, and reconnection must be done from the dashboard. This gives the agent concrete consequences of the destructive action.

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?

The description is four short sentences, front-loaded with the core action and return value. Every sentence adds useful information about consequences, recovery, or usage timing, with no wasted text.

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?

The tool has an output schema, rich annotations, and fully documented parameters. The description complements these by stating what gets destroyed and how reconnection works, leaving no critical gaps for correct invocation.

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 parameters are fully documented in the schema itself, including cross-references to list_sites and list_triggers. The description does not add further parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'Disconnect an integration such as Stripe or Calendly from a site,' and adds what is returned. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like delete_trigger or update_integration.

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?

It gives an explicit usage cue: 'Use it when the user asks to stop sending conversions from that integration.' It also notes that reconnecting happens from the dashboard, which helps set expectations. However, it does not list when-not-to-use conditions or name alternative tools such as delete_trigger.

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

All PixelFlow 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.