CRM Connector

Send a request to CRM Connector

send_request

Integrations and AI Agents: Use when the person wants something CRM Connector does not offer yet, to ask for it for them, for either product: an integration with a system it does not connect yet (kind integration), or AI Agents set up for their system on their account, which is how every system gets it (kind ai_access: read for AI Analyst, read_write for AI Agent, which also runs automations; get_ai_agents_info explains the difference; add budget when they named one for the one-off setup). For AI Agents the setup is quoted and arranged with them; once it is done the system is enabled for their account and they sign in to it in CRM Connector, where they choose their package. Before calling it, show the person exactly what will be sent and ask them to confirm. Needs no sign in: when the person signed in to CRM Connector their account email is used; otherwise ask for their email and pass it. CRM Connector answers every request by email, usually within one working day. When they prefer a form, the same requests can be made at https://crm-connector.com/platform/request-integration and https://crm-connector.com/platform/ai-access#request.

Input Schema

Name	Required	Description
`kind`	Yes	integration for a system to connect, ai_access for AI Agents on a system.
`name`	No	The person's name, when they gave it.
`email`	No	The person's email, so CRM Connector can answer. Leave it out when they are signed in.
`access`	No	For AI Agents: read (AI Analyst), or read_write (AI Agent) to also change records.
`budget`	No	For AI Agents: the budget the person has in mind for the one-off setup, in their own words, when they gave one.
`system`	Yes	The system the request is about, as the person names it.
`company`	No	The person's company, when they gave it.
`details`	No	What the person wants to do, in their own words: what should sync, or what the assistant should do in the system.
`connect_with`	No	For an integration: the system it should sync with, when the person said so.

Output Schema

Name	Required	Description	Default
`sent`	Yes
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish that this is a non-read-only, non-destructive, non-idempotent write action. The description adds important behavior beyond annotations: no sign-in is required because the signed-in account email may be used, the person must confirm exactly what will be sent, the setup may be quoted, and CRM Connector answers by email usually within one working day.

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?

The key purpose and usage trigger are front-loaded, and the dense detail reflects a multi-step request workflow with nine parameters. It is somewhat long and runs several clauses together, but most sentences carry actionable information rather than repetition.

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?

Given the tool complexity, nine parameters, and an output schema, the description covers the important non-schema context an agent needs: confirmation before sending, sign-in versus email handling, request kinds, AI Agents setup process, expected email response, and form alternatives.

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 schema already documents all parameters. The description still adds useful semantic context beyond the schema, such as omitting email when the person is signed in, using read for AI Analyst and read_write for AI Agent, and passing a budget only when the person named one.

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: send a request to CRM Connector for either an integration or AI Agents setup. It distinguishes the two request kinds clearly and explicitly names get_ai_agents_info as the sibling that explains the AI Agents distinction.

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 clearly says when to use the tool: when the person wants something CRM Connector does not yet offer, either an integration or AI Agents. It also gives prerequisites and alternatives, including showing the request for confirmation, handling sign-in/email, and pointing to the form-based request pages.

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?