Skip to main content
Glama
alexd73

PlanfixMCP

by alexd73

update_contact

Update a contact or company by its number, modifying details like name, emails, phones, addresses, and custom fields in Planfix.

Instructions

Обновить контакт по номеру

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoContact/company number. For create requests this field is usually omitted.
nameNoFirst name of a contact or name of a company.
siteNoWebsite URL of the contact/company.
emailNoPrimary email address of the contact or company.
filesNoExisting Planfix files attached to the contact/company. Each item must contain an existing file id.
groupNoContact group. Specify an existing group by id.
skypeNoSkype username.
genderNoContact gender. Use Female, Male, or NotDefined.
phonesNoContact phone numbers. Each phone contains a number and phone type.
silentNoSilent mode
addressNoPostal address of the contact/company.
midnameNoMiddle name of the contact.
viberIdNoViber identifier associated with the contact/company.
contactsNoContacts linked to this company. Specify existing contact/company numbers.
facebookNoFacebook profile/page link.
id__pathYesNumber of contact (Path parameter)
lastnameNoLast name of the contact.
positionNoJob title or position of the contact.
telegramNoTelegram username or profile link.
templateNoContact/company template. Specify an existing contact template by number.
timezoneNoIANA Time Zone Database identifier (TZID).
birthDateNoContact birth date. May be provided as a TimePoint-like object with date or as a supported date string.
companiesNoCompanies linked to this contact. Specify existing contact/company numbers.
instagramNoInstagram profile link.
isCompanyNoWhether the record is a company rather than an individual contact.
isDeletedNoWhether the contact/company is deleted.
telegramIdNoTelegram identifier associated with the contact/company.
descriptionNoDescription or notes for the contact/company.
supervisorsNoContact supervisors. Specify employees or contacts in users and groups in groups. Employee/contact identifiers must be prefixed, for example user:5 or contact:92.
languageCodeNoPlanfix interface language code for the contact/company.
sourceObjectIdNoUnique identifier of the specific object in the third-party application or system.
customFieldDataNoCustom field values for the contact/company. Each item contains a custom field id in field.id and its value.
sourceDataVersionNoVersion of the object data in the third-party application or system.
communicationLanguageCodeNoPreferred communication language code.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNo
failuresNo
Behavior1/5

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

There are no annotations, so the description carries full burden. It only states the operation ('update') without disclosing side effects, permissions, partial-update semantics, or any other behavioral traits beyond the verb itself.

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 description is a single, short sentence that immediately conveys the core action and identifier. It has no fluff or redundant information, earning its place.

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

Completeness2/5

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

For a tool with 34 parameters, an output schema, and sibling tools, the one-line description is insufficient. It omits that the endpoint also updates companies, that only provided fields are changed, and any other high-level context a user would need.

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 34 parameters. The description's 'by number' adds no new meaning beyond the id__path parameter's existing description, thus it meets the baseline.

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?

The description 'Обновить контакт по номеру' clearly states the action ('update') and resource ('contact'), and adds the scope 'by number' to indicate the identification method. It distinguishes the tool from create_contact and contact_by_id, though it does not explicitly mention sibling alternatives.

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?

No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The description is a single phrase without any contextual advice about the update workflow.

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/alexd73/PlanfixMCP'

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