Skip to main content
Glama
ptaramona

Conduyt MCP Server

by ptaramona
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

conduyt_update_contact

Update an existing contact's name, email, phone, company, status, timezone, and custom fields. Merge custom field values while leaving omitted keys unchanged.

Instructions

Update an existing contact's fields — name, email, phone, company, custom fields. customFields merge into existing values (omit a key to leave it unchanged).

Input Schema

NameRequiredDescriptionDefault
idYesContact UUID
emailNoUpdated email
phoneNoUpdated phone
sourceNoCorrect the lead's first-touch source (normally first-write-wins and set at creation — update only to FIX bad attribution). Pass null to clear.
companyNoUpdated company name
lastNameNoUpdated last name
timezoneNoIANA timezone override (e.g. America/Denver); pass null to clear the override and re-derive from ZIP → area code → state
firstNameNoUpdated first name
customFieldsNoStructured custom-field values to merge, keyed by field key. Omit a key to leave it unchanged.
masterStatusNoLifecycle status of the LEAD (master record), distinct from any deal's status: 'open' (default), 'won', 'lost', 'abandoned', 'disqualified', or an account-defined custom status. A terminal status (won/lost/abandoned/disqualified) SILENCES all outbound automations for this contact — drips, sequences, and scheduled sends stop. Use conduyt_get_lifecycle_settings to see the account's configured statuses.
custom_fieldsNoAlias for customFields (snake_case). Provide only one of customFields / custom_fields.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.71.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the burden, and it does add one valuable behavioral trait: customFields merge rather than overwrite (omit a key to leave it unchanged). However, it omits other important behavioral facts present in the schema — that masterStatus terminal values silence automations and that 'source' is normally first-write-wins.

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?

Two tight sentences, field list front-loaded and the merge caveat immediately after. No filler, though the field enumeration is partly redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-param mutation tool with no annotations and no output schema, the description adequately conveys purpose and the customFields merge rule, and the schema covers parameter detail. It nonetheless leaves behavioral gaps (automation-silencing via masterStatus, source-correction semantics) unstated in prose.

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 11 parameters. The description's note about customFields merging repeats what the schema's own customFields description states, adding no meaning beyond the schema. Baseline 3 is appropriate.

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 (Update) and resource (existing contact's fields) plus the main updatable fields. It's clearly distinguishable from conduyt_create_contact and conduyt_delete_contact, but does not mention how it differs from conduyt_update_deal or conduyt_bulk_update_contacts.

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

Usage Guidelines2/5

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

The word 'existing' implies this is for modifying an already-created contact, but there is no explicit when-to-use guidance, no mention of alternatives like conduyt_bulk_update_contacts for many records, and no prerequisites stated.

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

Deploy Server

Other Tools