CRM Connector

Resolve an integration conflict

resolve_integration_conflict

DestructiveIdempotent

Integrations (between two systems): Use after get_integration_health with include conflicts, once the person chose. choice sync makes the record that also matches the one the shared record follows from the next sync; choice keep_apart leaves both records as they are and stops asking. Both can be undone in CRM Connector. Ask the person to confirm first.

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_id": "<integration_id>",
      "conflict_id": "<conflict_id>",
      "choice": "<choice>"
    },
    "name": "resolve_integration_conflict"
  }
}

Input Schema

Name	Required	Description
`choice`	Yes	sync or keep_apart.
`conflict_id`	Yes	The id of the conflict, as get_integration_health returns it with include conflicts.
`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.

AddedNov 5, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the description earns credit for adding what annotations cannot: that both choices are reversible ('can be undone in CRM Connector') and that keep_apart stops future prompts. The sync explanation ('makes the record that also matches the one the shared record follows from the next sync') is garbled enough that an agent may not confidently predict the exact merge behavior.

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 description is short and front-loads the prerequisite, but the sync clause is a long nested relative construction ('the record that also matches the one the shared record follows from') that costs more parsing effort than it saves. No filler sentences, but one clause should be rewritten for readability.

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 destructive, irreversible-looking mutation the description supplies the essentials: prerequisite tool, confirmation requirement, per-choice consequences, and reversibility. Return values need not be explained since an output schema exists. The only gap is the imprecise description of what 'sync' actually merges or overwrites.

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 a baseline of 3 applies, but the description goes further by explaining the real-world consequence of each enum value of 'choice' rather than just restating 'sync or keep_apart'. The meaning of integration_id/conflict_id is left entirely to the schema, which already handles them well.

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 names the resource (an integration conflict between two systems) and explains the two possible outcomes (sync vs keep_apart), letting an agent distinguish it from get_integration_health and other integration siblings. It never states the action in a clean verb form in the first sentence — 'Use after get_integration_health...' is a usage instruction, and the actual effect must be inferred from the choice semantics.

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 prerequisite and sequencing ('Use after get_integration_health with include conflicts') and a hard gate ('once the person chose', 'Ask the person to confirm first'), which prevents premature invocation. It lacks explicit when-not-to-use guidance, but the confirmation requirement covers the main misuse risk.

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?