Skip to main content
Glama

Disconnect an integration

disconnect_integration
DestructiveIdempotent

Disconnect an integration: the stored secret or token is deleted (Search Console also revokes the Google grant; Shopify removes our script and webhooks). Imported payments and orders stay. Connecting again needs the person in the dashboard. Needs confirm: true; without it the tool only describes what it would do.

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

Input Schema

NameRequiredDescriptionDefault
siteNoSite domain (example.com), id or public id (tb_…). Optional with a site key, or when the account has one site.
confirmNoSet to true to really do it. Without it, the tool only describes what it would do.
providerYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses exactly what is destroyed (secret/token, Google grant, Shopify script and webhooks), what survives (imported payments and orders), and that the operation is gated behind a dry-run unless confirm is true. That is precisely the extra context the destructiveHint/idempotentHint flags cannot convey.

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?

Front-loaded with the effect and consequence, then the confirm gate — the ordering matches decision order. It is dense but every clause carries information; the two parenthetical provider notes are the only mildly heavy spots.

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 destructive, no-output-schema mutation tool, the description covers effect, side effects, data retention, irreversibility of reconnection, and the dry-run gate. An agent has enough to decide and call correctly without additional documentation.

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?

The confirm semantics are restated and the description attaches provider-specific behavior to the enum values (gsc, shopify), adding meaning the bare enum lacks. Schema coverage is 67% and the site parameter's role is left entirely to the schema, so it is good rather than complete.

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?

Names a specific verb and resource ('Disconnect an integration') and immediately states the concrete effect: the stored secret or token is deleted. The provider-specific consequences (Search Console revokes the Google grant; Shopify removes script and webhooks) make it unmistakable versus sibling read tools like get_integrations.

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?

Gives the operative precondition clearly ('Needs confirm: true; without it the tool only describes what it would do') and flags that re-connecting cannot be done through this tool — a person must do it in the dashboard. It does not explicitly name a sibling to check state first (e.g., get_integrations) or state when not to disconnect, so it falls short of full when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources