Unified.to MCP Server

Activate integration

activate_unified_integration

DestructiveIdempotent

Activate an integration in one environment of this workspace, or change the settings of one already active there. This changes the workspace: once it is active, end users can authorize the integration in that environment through the Authorization component or an authorization URL. Each environment is separate: Production, Sandbox (Synthetic Data) or a custom one such as a development environment (see list_unified_environments). For an OAuth 2 integration, pass your own app's client_id and client_secret, or use Unified.to's OAuth 2 credentials where the integration has them (has_unified_oauth2_credentials in list_unified_integrations): leave the credentials out on a first activation, or set use_unified_oauth_credentials to switch back to them. The dashboard offers Unified.to's credentials only outside Production; register your own app for Production. Settings you leave out keep their current values. Needs a workspace admin's API key. Returns the integration's saved settings with secrets redacted.

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": {
      "integration_type": "<integration_type>",
      "env": "<env>"
    },
    "name": "activate_unified_integration"
  }
}

Input Schema

Name	Required	Description
`env`	Yes	The environment to activate it in: "Production", "Sandbox" (Synthetic Data) or a custom environment name
`auth_type`	No	Force one authentication method when the integration supports several. Leave out to keep the current or default method.
`client_id`	No	Your own OAuth 2 app's client ID
`categories`	No	The categories to enable (e.g. ["crm"]). On a first activation, defaults to every category the integration supports.
`permissions`	No	The Unified permission scopes to enable (e.g. ["crm_deal_read", "crm_deal_write", "crm_contact_read"]). They are requested when an authorization URL has no `scopes`. On a first activation, defaults to every permission of the enabled categories.
`client_secret`	No	Your own OAuth 2 app's client secret. It is stored encrypted and never returned.
`integration_type`	Yes	The integration, by its `type` from `list_unified_integrations` (e.g. "hubspot")
`use_unified_oauth_credentials`	No	Set true to use Unified.to's OAuth 2 credentials instead of your own; clears any stored client ID and secret

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses the downstream effect (end users can then authorize via the Authorization component or an authorization URL), that the call requires a workspace admin's API key, that omitted settings retain current values, and that the response returns saved settings with secrets redacted and client_secret never returned. Nothing here contradicts readOnlyHint=false, idempotentHint=true, or destructiveHint=true.

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 purpose and workspace-wide effect are front-loaded in the first two sentences, then environment scoping, then credential handling, then auth requirement and return shape. It is dense and long for a tool description, but each sentence carries decision-relevant information rather than restating the name.

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 mutation tool with no output schema and 8 parameters, the description still covers authorization prerequisites, environment isolation, defaulting behavior, secret handling, and what the response contains. An agent has enough to call it correctly without guessing.

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 coverage is already 100%, so the baseline is 3, but the description earns extra credit by adding semantics the schema does not: credentials omitted on first activation versus setting use_unified_oauth_credentials to revert, and that permissions are only requested when an authorization URL carries no scopes. It stops short of tying every parameter to its default behavior explicitly (e.g. auth_type interaction).

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 opens with a specific verb+resource and dual scope: activating an integration in one environment, or changing settings of one already active there. That distinguishes it cleanly from deactivate_unified_integration and from create_unified_connection, which lives in the sibling list.

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 routes the agent to the right prerequisite tools by name (list_unified_environments, list_unified_integrations, has_unified_oauth2_credentials) and gives explicit conditional rules: leave credentials out on a first activation, set use_unified_oauth_credentials to switch back, register your own app for Production because the dashboard offers Unified.to credentials only outside Production.

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

All Unified.to MCP Server tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?