Add to CRM

Add a person to the CRM

add_person_to_crm

Add a person to the customer's connected CRM. It looks the person up from the profile link, e-mail or name given, checks the CRM first so nobody is added twice, and saves what it found with the customer's usual field settings and default tags. A record with the same name is reported as a possible match and nothing is added until add_anyway is set. Uses one lookup credit when an e-mail address is found.

Input Schema

Name	Required	Description
`name`	No	the person's full name; give it with a company when there is no profile link or e-mail
`tags`	No	tags to put on the record, in addition to the customer's default tags
`email`	No	an e-mail address the person is known by
`company`	No	the company the person works for
`use_email`	No	one of the addresses found, to save as the person's main e-mail instead of the best one
`add_anyway`	No	true to add the person although a possible match exists, once that match is known to be a different person
`profile_url`	No	link to the person's public profile page
`include_phone`	No	also look for a mobile number; this uses extra credits, so set it only when the customer wants a phone number saved

Output Schema

Name	Required	Description
`crm`	No	the CRM the person was added to, or checked
`record`	No	the new record, or the one already there
`status`	No	added, already_in_crm, possible_matches, not_found or pending
`contact`	No	what was found for the person and saved
`not_saved`	No	fields the CRM did not take, when any
`credits_left`	No
`credits_used`	No
`possible_matches`	No	records that share the person's name and may or may not be the same person

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the deduplication check, the possible-match gating via add_anyway, the use of the customer's field settings and default tags, and credit consumption for e-mail lookups and phone discovery. This is rich behavioral context for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences: purpose first, then workflow and gating, then credit cost. Every sentence adds useful information without redundancy.

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?

Given the output schema and annotations, the description covers the essential workflow, side effects, and cost. A minor gap is the lack of reference to the sibling confirm_possible_match for resolving flagged matches, but the add_anyway override is clearly explained.

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%, so the schema already documents all eight parameters. The description adds light context about which fields drive the lookup and how add_anyway works, but does not meaningfully expand on parameter semantics beyond what the schema provides.

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?

States a specific verb and resource: 'Add a person to the customer's connected CRM.' It is clearly singular and distinguishable from add_company_to_crm, though it does not explicitly call out the bulk sibling add_people_to_crm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the lookup sources and the duplicate-check behavior, but it never states when to prefer this tool over alternatives such as add_people_to_crm or find_person_in_crm. Usage is implied rather than explicitly guided.

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

All Add to CRM 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.