CRM Connector

Sync now

run_sync

Destructive

Integrations (between two systems): Use when a signed in CRM Connector customer wants one of their integrations to sync now, for example after fixing what made records fail. mode changes (the default) picks up what changed since the last sync; mode full reads and writes every record again, without duplicates, to repair records that did not sync correctly, and takes longer. Ask the person to confirm first. Needs the integration id from list_integrations. A sync starts at most once every 15 minutes per integration. Not for what a sync did (use get_sync_health).

Input Schema

Name	Required	Description	Default
`mode`	No	changes (the default) or full.	changes
`integration_id`	Yes	The id of the integration, as list_integrations returns it. Ask the person which integration they mean unless they named it in this conversation; never pick one yourself.

Output Schema

Name	Required	Description	Default
`status`	No
`message`	Yes
`outcome`	Yes
`conflicts`	No
`manageUrl`	No
`integrationId`	No
`openConflicts`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026

removedOutput schema / properties / choices

Removed value: -{
-  "items": {
-    "properties": {
-      "id": {
-        "format": "uuid",
-        "type": "string"
-      },
-      "name": {
-        "type": "string"
-      },
-      "system": {
-        "type": "string"
-      },
-      "systemName": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "id",
-      "system",
-      "systemName",
-      "name"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / choosePlanUrl

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedOutput schema / properties / connectLinks

Removed value: -{
-  "items": {
-    "properties": {
-      "system": {
-        "type": "string"
-      },
-      "systemName": {
-        "type": "string"
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "system",
-      "systemName",
-      "url"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

First observedOct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark the tool as non-read-only, open-world, non-idempotent, and destructive; the description adds crucial context beyond that. It explains what mode full does, that it rewrites every record without duplicates to repair failed records, that it takes longer, that confirmation is required, and that a sync starts at most once every 15 minutes per integration.

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 dense but front-loaded: it begins with the resource, then the use condition, then mode behavior, confirmation, id source, rate limit, and the excluded use case. Every sentence carries actionable information with no filler.

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?

With annotations and an output schema already present, the description still covers the full decision context: when to use it, how the modes differ, confirmation needs, required id source, rate limit, and the alternative for sync results. Nothing essential is missing for correct invocation.

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 100%, so the baseline is 3, but the description adds real meaning for the mode parameter by contrasting changes with full and describing the repair behavior and longer runtime. The integration_id guidance mostly reinforces the schema rather than adding new detail.

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: sync an integration now. It distinguishes this from the sibling get_sync_health by explicitly saying it is not for checking what a sync did.

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 names the exact situation for use: a signed-in CRM Connector customer wants an integration to sync now, for example after fixing failed records. It also explains the two modes, when to confirm with the person, where to get the integration id, the 15-minute rate limit, and which sibling to use instead for sync results.

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

All CRM Connector 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.

Resources

Need Help?