Skip to main content
Glama

Metadata MCP Connector

Connect CRM

connect_crm

Get the OAuth redirect URL to connect a specific CRM system to the Metadata platform.

                USAGE INSTRUCTIONS FOR LLM:
                Use this tool to obtain the authorization URL that users need to visit to connect their CRM accounts.
                This tool returns a redirect URL that initiates the OAuth flow for the selected CRM system.

                WHEN TO USE THIS TOOL:
                - User asks to "connect [CRM name]"
                - User wants to "add [CRM] integration"
                - User needs to "link [CRM] account"
                - User wants to "authorize [CRM] access"
                - User asks "how do I connect my Salesforce/HubSpot CRM?"
                - User needs to "set up [CRM] connection"
                - After disconnecting a CRM and wanting to reconnect
                - User asks "give me the link to connect [CRM]"

                SUPPORTED CRM SYSTEMS:
                - salesforce: Connect Salesforce CRM
                - hubspot: Connect HubSpot CRM

                IMPORTANT WORKFLOW - MUST FOLLOW THESE STEPS:
                1. Call this tool to get the OAuth redirect URL
                2. Display the URL to the user clearly and instruct them to open it in their browser
                3. Explain that they need to complete the authorization process on the CRM's website
                4. IMPORTANT: Ask the user to return to the chat and confirm when they have completed the connection
                5. WAIT for the user's confirmation before proceeding with any other tasks
                6. Once the user confirms the connection is complete, acknowledge it and continue

                REQUIRED USER INTERACTION:
                - The user MUST visit the returned URL in their browser to complete OAuth authorization
                - The URL will redirect to the CRM's authorization page
                - After authorization, the user will be redirected back to Metadata platform
                - The connection will be active once the OAuth flow is completed successfully
                - YOU MUST WAIT for user confirmation before proceeding

                COMMON SCENARIOS:

                Scenario 1 - Connect Salesforce: "I want to connect my Salesforce CRM"
                → Call connect_crm with crm="salesforce"
                → Show URL to user: "Please open this URL to connect your Salesforce CRM: [URL]"
                → "After completing the authorization, please return here and let me know it's done so we can proceed."
                → WAIT for user confirmation

                Scenario 2 - Connect HubSpot: "Connect HubSpot CRM"
                → Call connect_crm with crm="hubspot"
                → Show URL to user with instructions
                → WAIT for user confirmation

                Scenario 3 - Reconnect workflow: "I want to reconnect my Salesforce with different credentials"
                → First disconnect existing connection if needed
                → Call connect_crm with crm="salesforce"
                → Provide the URL to user
                → WAIT for user confirmation

                RESPONSE FORMAT:
                Returns an object containing the redirect URL for OAuth authorization.
                Example: {"redirectUrl": "https://login.salesforce.com/services/oauth2/authorize?..."}

                EXAMPLE: "Connect Salesforce" → connect_crm(crm="salesforce")
                

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
crmYesThe CRM system to connect. Must be one of: salesforce, hubspot
acknowledge_data_accessNoSet true to confirm the person you are acting for asked to connect this CRM. The response is an OAuth authorization URL that starts a credential grant into their Metadata account. Without this the call is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already indicate non-read-only, open-world, non-destructive behavior. The description adds valuable behavioral context: it initiates an OAuth flow requiring user interaction, mandates waiting for user confirmation, and notes that the call is refused without acknowledge_data_access=true. It explains the redirect flow and eventual activation of the connection. However, it does not cover failure modes or what happens if the user does not confirm, leaving some gaps beyond the annotation profile.

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 long and detailed, with sections for usage, workflow, scenarios, and response format. It is well-organized and front-loaded with purpose, but it is verbose and includes repetitive instructions (e.g., repeated 'WAIT for user confirmation' across sections). Some content, such as the example response format, is redundant given the schema. It could be trimmed without losing essential guidance, so it does not earn a top score for conciseness.

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 tool with no output schema and a multi-step OAuth flow, the description is exceptionally complete. It explains the return value (object with redirectUrl), the required user interaction, the full workflow, and common scenarios. It covers all the information an agent needs to correctly invoke the tool and guide the user, fulfilling the description's burden given the lack of an output schema.

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 100% for both parameters, with clear enum values for crm and a thorough explanation of acknowledge_data_access in the schema itself. The description's examples (crm='salesforce') and scenario mentions reinforce the schema but do not add new semantic meaning. Since the schema already carries the parameter documentation, the baseline 3 applies.

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 clear verb and resource: 'Get the OAuth redirect URL to connect a specific CRM system'. It enumerates supported CRM systems (salesforce, hubspot) and explicitly distinguishes from generic channel connections (e.g., connect_channel) by focusing on CRM OAuth. The purpose is unambiguous and easily differentiates from sibling tools.

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 includes a dedicated 'WHEN TO USE THIS TOOL' section with concrete user intents (e.g., 'connect [CRM name]', 'add [CRM] integration') and a detailed workflow with numbered steps. It also provides common scenarios (Salesforce, HubSpot, reconnect) that illustrate exact invocation patterns. This gives the agent explicit guidance on when to call this tool versus alternatives.

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