Metadata MCP Connector

Get Integrations Status

get_integrations_status

Read-only

Get comprehensive integration connection status for all channels, martech platforms, and CRM systems in the Metadata platform.

                USAGE INSTRUCTIONS FOR LLM:
                Use this tool to identify which platforms and services are connected or disconnected from the Metadata platform.
                This is essential for understanding the current state of integrations and diagnosing connectivity issues.

                WHEN TO USE THIS TOOL:
                - User asks "which channels are connected?"
                - User wants to check "integration status"
                - User asks "is [platform name] connected?" (e.g., "is LinkedIn connected?", "is Facebook connected?")
                - User wants to know "what martech tools are integrated?"
                - User asks about "CRM connection status" or "which CRM is connected?"
                - User asks "show me all connected platforms"
                - User wants to troubleshoot "why campaigns aren't running" (often related to disconnected channels)
                - User needs to "check if [service] needs reconnection"
                - User asks about "available ad channels" or "active advertising platforms"

                EXPECTED RESPONSE FORMAT:
                Returns object with three main sections: channels, martech, apps

                Each integration has: connected (bool), enabled (bool), type (string), businessAccountId,
                businessAccountName, currency, connectedAt (ISO timestamp), userFullName, errors (array)

                CHANNELS: Array of advertising platforms (FACEBOOK, INSTAGRAM, LINKEDIN, GOOGLE_ADS, MICROSOFT_ADS, TWITTER, REDDIT)
                MARTECH: Object with crm (array), marketingAutomation (array), googleAnalytics (object)
                - CRM types: SALESFORCE, HUBSPOT
                - Marketing Automation: HUBSPOT, PARDOT, ELOQUA, MARKETO
                APPS: Array of third-party integrations (G2, SLACK with channelName/channelId)

                USE CASES:
                1. Audit and Compliance:
                   "Generate a report of all connected marketing platforms for security review"

                2. Integration Health Monitoring:
                   "Check if any integrations need token refresh or reconnection"

                3. Capability Discovery:
                   "What advertising channels can I use based on current connections?"

                COMMON SCENARIOS:

                Scenario 1 - Check channel: "Is Facebook connected?"
                → Parse response.channels, find type="FACEBOOK", check connected=true

                Scenario 2 - List connected channels: "Show me all connected advertising platforms"
                → Parse response.channels, filter where connected=true

                Scenario 3 - Disconnected integrations: "What needs reconnection?"
                → Check all sections for connected=false

                Scenario 4 - CRM status: "Is Salesforce connected?"
                → Parse response.martech.crm, find type="SALESFORCE", check connected=true

                OPTIONAL PARAMETERS: integrationType (CHANNEL/MARTECH/CRM), connectionStatus (CONNECTED/DISCONNECTED), platformName

                EXAMPLE: "What's the status of my integrations?" → Present summary of connected/disconnected by category

Input Schema

TableJSON Schema

Name	Required	Description	Default
`platformName`	No	Filter by specific platform name (e.g., 'Facebook', 'LinkedIn', 'Salesforce', 'HubSpot')

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read-only operation. The description adds value by detailing the response structure (sections, fields, types) and explaining how to interpret the data (e.g., finding connected channels). This goes beyond annotation basics, though it doesn't mention potential rate limits or authentication requirements, which are not typically shown in metadata.

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 quite long and verbose, with extensive sections (use cases, scenarios, expected response formats) that provide significant detail. However, it is well-organized with headers and bullet points, and the essential information is front-loaded. Some redundancy exists (e.g., repeated examples), but overall itearns its length.

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?

The description is exceptionally complete for a tool with one optional parameter and no output schema. It covers the response format in detail, including all sections and fields, provides concrete examples, and explains how to use the data. There is no missing information an agent would need to call this tool correctly.

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?

The schema has only one parameter (platformName) with a description provided, and schema coverage is 100%. The description adds more context by mentioning optional parameters like integrationType and connectionStatus (though these are not in the schema, possibly indicating a discrepancy), but the core platformName is well-documented. The description enhances understanding of what filtering is possible.

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 clearly states the tool's purpose: to get comprehensive integration connection status for channels, martech platforms, and CRM systems. It provides a detailed verb-object pair and explains what it returns, distinguishing it from tools like connect_channel or disconnect_channel.

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?

The description provides extensive usage instructions, including specific example queries, when-to-use cases, and a dedicated 'WHEN TO USE THIS TOOL' section with concrete scenarios. It also gives common scenarios and expected response formats, making it extremely clear when this tool is appropriate.

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

All Metadata MCP 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?