CRM Connector

Get integration health

get_integration_health

Read-onlyIdempotent

Integrations (between two systems): Use when a signed in CRM Connector customer asks how their syncs are doing: what failed, why records did not arrive, what is waiting, when an integration last ran or which conflicts wait for a choice. Returns, for all integrations or one, the failed records grouped by reason with a count per integration and record type, the records waiting on a related record, and totals. With an integration_id, include recent_syncs adds its latest syncs (moment, outcome and per record type what was read, written, skipped and failed) and include conflicts adds the conflicts waiting: two records that match one record, of which only one can sync, named only to a person who allowed managing integrations. Failure reasons never quote record contents. Not for listing integrations (use list_integrations) or for fixing anything: it only reads; resolve a conflict with resolve_integration_conflict and start a sync with run_integration.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_integration_health"
  }
}

Input Schema

Name	Required	Description
`days`	No	How many days back to look, 1 to 30.
`limit`	No	With include recent_syncs: how many of the latest syncs, 1 to 20.
`include`	No	Optional, with an integration_id: recent_syncs for its latest syncs, conflicts for the conflicts waiting.
`integration_id`	No	Optional id of one integration, as list_integrations returns it; needed for include. Leave it out for all integrations.

Output Schema

Name	Required	Description	Default
`health`	Yes
`conflicts`	Yes
`recentSyncs`	Yes
`conflictsNotRead`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds real behavioral context: it only reads, failure reasons never quote record contents, and conflict names are visible only to a person allowed to manage integrations. It also spells out the conditional enrichment of include (recent_syncs / conflicts) and the per-record-type read/written/skipped/failed breakdown.

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 use case, then results, then exclusions — a sensible order with no filler sentences. It is dense and some clauses repeat themselves (waiting records described twice as 'waiting on a related record' and 'conflicts waiting'), keeping it short of perfect.

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 read-only, four-parameter tool with an output schema, the description covers trigger, scope, conditional return payloads, permissions caveats and routing to siblings. Nothing an agent needs in order to call it correctly is missing.

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 goes further by explaining the dependency semantics: include only applies with an integration_id, and limit and the recent_syncs expansion are conditional on that combination. It could still state what days bounds explicitly, but the interaction between parameters is clearly conveyed.

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 (integration health) and enumerates the concrete questions it answers: what failed, why records did not arrive, what is waiting, when an integration last ran, which conflicts wait. It explicitly distinguishes itself from list_integrations, resolve_integration_conflict and run_integration, so an agent can route without opening the schema.

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?

Gives an explicit trigger condition (a signed-in CRM Connector customer asking how their syncs are doing) plus two negative cases with named alternatives: not for listing integrations (list_integrations) and not for fixing anything (resolve_integration_conflict, run_integration). When-to-use, when-not-to-use and alternatives are all present.

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?