Skip to main content
Glama

integrations_write

Destructive

Add, change or remove an integration on an agent, exactly like the dashboard. assign_to_agent also updates an existing setup (call it again with new settings); remove_from_agent removes it. settings by type — google_calendar / outlook_calendar: { connectionId, calendarId, calendarName?, timezone? ("Europe/London" or "GMT+1"), label?, description?, methods? (create-event, check-availability, lookup-events, update-event, delete-event), bookingMode? ("route" = caller picks one calendar, "union" = any free calendar), defaultCallerTimezone? ("" = same as calendar, "ask", or a zone), disableMeetLink? (google, in-person) } — up to 5 calendars per agent; remove one with { calendarId } or all with {}. google_sheets: { connectionId, sheetId, sheetTabName, method: "read" | "lookup" | "write", sheetName?, sheetDescription?, headerRowIndex?, headerDescriptions? {column: meaning}, identifierColumn?, identityFields? { phone, email, name, custom, customLabel } } — up to 5 sheets; remove one with { sheetId }. airtable: { connectionId, baseId, tableId?, method?, fieldDescriptions?, identifierField? }. shopify: { connectionId }. calendly: { connectionId }. zoho_crm: { config } (draft it with zoho_auto_configure; config.logTranscript keeps a note with the real messages, including human replies from WhatsApp/dashboard). gmail / outlook_mail / zoho_mail (the agent answers that inbox): { connectionId, whenToReply? (always | keywords | sentiment | manual), replyDelayMinutes?, replyRule?, humanNotifyRule?, replyLength? (short | medium | long | auto), replyTone?, keywords?, ignoreKeywords?, humanTakeoverEnabled?, humanTakeoverTimeoutMinutes?, notifyWorkspaceOwners? } — also starts inbound notifications. Get ids from integrations_read (all_connections, resources). After assigning, verify with integrations_read agent_integrations and integrations_test. Actions: assign_to_agent — add or update an integration on an agent Needs: agentId, type, settings. | remove_from_agent — remove an integration (or one calendar / sheet / inbox) from an agent Needs: agentId, type. | calendly_save_event_types — choose which Calendly event types agents may offer Needs: connectionId, selectedEventTypes. | calendly_assign_agents — give agents the Calendly booking ability Needs: connectionId, agentIds. | calendly_remove_agent — remove Calendly from an agent Needs: agentId. | google_calendar_disconnect — disconnect a Google Calendar account (confirm first; refused while agents use it unless force) Needs: connectionId. | outlook_disconnect — disconnect an Outlook account (confirm first) Needs: connectionId. | zoho_disconnect — disconnect a Zoho account (confirm first) Needs: connectionId. | zoho_auto_configure — let AI draft a Zoho sync config from the CRM fields (does not save) Needs: connectionId. | zoho_test_lookup — try a config against the CRM with a phone / email, without saving Needs: config. | zoho_save_agent_config — save the Zoho sync config on an agent Needs: agentId, config. | zoho_remove_agent — remove Zoho CRM from an agent Needs: agentId.

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": {
      "action": "<action>"
    },
    "name": "integrations_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNocompact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
typeNoFor assign_to_agent / remove_from_agent.
emailNoFor zoho_test_lookup: an email to look the person up by.
forceNoFor google_calendar_disconnect: disconnect even if agents still use the connection.
orgIdNoOptional organization scope.
phoneNoFor zoho_test_lookup: a phone number to look the person up by.
actionYes
configNoZoho agent sync config (as returned by zoho_agent_config / zoho_auto_configure). To turn the message log on or off, read the current config, flip logTranscript, and save the whole config back.
customNoFor zoho_test_lookup: extra lookup values.
agentIdNoFor assign_to_agent / remove_from_agent / calendly_remove_agent / zoho_save_agent_config / zoho_remove_agent: the agent.
agentIdsNoFor calendly_assign_agents.
settingsNoFor assign_to_agent / remove_from_agent: the shape for the chosen type (assign) — each option is titled with its type.
connectionIdNoIntegration connection id (from integrations_read all_connections).
instructionsNoFor zoho_auto_configure: what the sync should do, in plain words.
moduleApiNamesNoFor zoho_auto_configure: up to 5 modules.
selectedEventTypesNoFor calendly_save_event_types: event type objects from integrations_read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real operational context: disconnects require confirmation and are refused while agents still use the connection unless force is passed, and zoho_auto_configure explicitly does not save. Per-type cardinality limits (up to 5 calendars, up to 5 sheets) are also disclosed, which an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the read/verify routing are front-loaded, which is good, but the middle is a single dense run-on enumerating every settings shape, much of which duplicates the schema. The trailing action list is well formatted with per-action requirements, so the waste is localized to the settings block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter, nested, 12-action mutation tool with no output schema, the description covers prerequisites (where ids come from), the draft-then-save Zoho workflow, and how to verify results afterwards. It stops short of describing any failure or error behavior beyond the force-refusal case.

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 94%, so the schema already carries nearly all parameter meaning, including enum explanations like bookingMode route/union and createPolicy. The description's per-type settings breakdown largely restates the schema, though the removal shorthand ("remove one with { calendarId } or all with {}") adds a small clarification on top of the title-only schemas.

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 opening sentence gives a specific verb and resource ("Add, change or remove an integration on an agent") and distinguishes it from integrations_read/integrations_test by pointing at them for id lookup and verification. However, the body reveals the tool also performs disconnects, Calendly event-type management and Zoho config drafting, so the stated purpose under-describes the actual scope of the 12-action dispatcher.

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?

Explicit routing is provided: get ids from integrations_read (all_connections, resources), verify afterwards with integrations_read agent_integrations and integrations_test, and draft Zoho configs with zoho_auto_configure before saving. What is missing is any when-not guidance, e.g. when to prefer remove_from_agent versus a full *_disconnect, or when force is appropriate.

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