Skip to main content
Glama
optimize-overseas

LACRM MCP Server

Edit Contact

edit_contact

Update an existing contact or company in Less Annoying CRM by providing the contact ID and fields to change. Modify details like name, email, phone, or custom fields while leaving other data untouched.

Instructions

Update an existing contact or company in Less Annoying CRM.

PREREQUISITES (call these first):

  1. get_contact_schema (or get_company_schema) → see available fields, their types, and formats

  2. search_contacts or get_contact → find/verify valid contact_id

Use this tool to modify contact details like name, email, phone, etc. Only include fields you want to change - other fields remain unchanged.

Supports flat-string shortcuts: use email_address, phone_number, or website_url for single values. Supports custom_field_names for name-based custom field resolution.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoFull name
emailNoEmail addresses (replaces all existing)
phoneNoPhone numbers (replaces all existing)
addressNoAddresses (replaces all existing)
websiteNoWebsite URLs
birthdayNoBirthday in yyyy-mm-dd format
addressesNoAlias for "address" (replaces all existing).
job_titleNoJob title
contact_idYesThe ContactId of the record to edit
is_companyNoChange record type
assigned_toNoUser ID to reassign to
website_urlNoSingle website URL. For multiple websites, use website array instead.
company_nameNoCompany name
phone_numberNoSingle phone number (auto-converts to Work type). For multiple phones, use phone array instead.
custom_fieldsNoCustom field values to update keyed by field ID. Mutually exclusive with custom_field_names.
email_addressNoSingle email address (auto-converts to Work type). For multiple emails, use email array instead.
background_infoNoAdditional notes
custom_field_namesNoCustom field values keyed by field name (case-insensitive; validated against the account fields + dropdown options, then written by name). Mutually exclusive with custom_fields.
Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses partial update semantics, flat-string shortcuts for email/phone/website, and name-based custom field resolution. However, it does not describe error cases, return values, or potential side effects of is_company changes, leaving some gaps in transparency.

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?

The description is concise and well-structured, opening with the primary purpose, then clearly listing prerequisites, usage intent, and key behaviors. Every sentence adds value without redundancy, making efficient use of space.

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 tool's complexity (18 parameters, nested objects, no output schema), the description adequately covers prerequisites, partial updates, and shortcut semantics. It does not explain return values or validation behavior, but for an update tool with such rich schema descriptions, it is reasonably complete.

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 each parameter. The description adds meaningful semantics by explaining the flat-string shortcuts (email_address, phone_number, website_url) and how custom_field_names resolve differently from custom_fields. This goes beyond the raw schema descriptions.

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 'Update an existing contact or company in Less Annoying CRM' with a specific verb and resource. It distinguishes itself from sibling tools like create_contact, delete_contact, and get_contact by explicitly framing the operation as a modification of an existing record.

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 explicit prerequisites, naming specific tools to call first (get_contact_schema, get_company_schema, search_contacts, get_contact) to obtain necessary schema and contact_id. It also states when to use the tool ('Use this tool to modify contact details') and clarifies partial update behavior ('Only include fields you want to change').

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/optimize-overseas/lacrm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server