Skip to main content
Glama
LibreDesk MCP

LibreDesk MCP

by Passe12345

update_contact

Modify an existing LibreDesk contact's name, email, phone, country, or avatar by contact ID. Requires contacts:write permission; at least an email or phone number must be set.

Instructions

Update Contact Requires the contacts:write permission. PUT /api/v1/contacts/{id} Tags: Contacts

Input Schema

NameRequiredDescriptionDefault
idYes(path parameter)
emailNo(body) Contact's email address. Required when `phone_number` is empty. Send an empty value or the string `null` to clear it.
filesNo(body, file) New avatar image file to upload (max 10MB) — pass a file path inside the directory set by LIBREDESK_MCP_UPLOAD_DIR (uploads are refused while it is unset); the server will upload its contents.
countryNo(body) Contact's country as an ISO 3166-1 alpha-2 code. Send an empty value or the string `null` to clear it.
last_nameNo(body) Contact's last name
avatar_urlNo(body) URL of the contact's avatar image. Send an empty value or the string `null` to remove the avatar, or the existing value to keep it.
first_nameYes(body) Contact's first name
phone_numberNo(body) Contact's phone number. Required when `email` is empty. Send an empty value or the string `null` to clear it.
phone_number_country_codeNo(body) ISO country code. Send an empty value or the string `null` to clear it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.3/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full disclosure burden, yet it only states the required permission scope and that the call is a PUT to /api/v1/contacts/{id}. It never says what happens to fields omitted from the body (PUT semantics suggest replacement, but that is left to inference), whether the change is reversible, or what a failure looks like. The permission scope is the one genuinely useful behavioral fact.

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

Conciseness3/5

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

Very short and front-loaded, with no filler prose, but it is closer to a raw endpoint dump than a structured definition; the "Tags: Contacts" line contributes no decision-relevant information while the space that could have explained update semantics is unused.

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 9-parameter mutation tool with no annotations and no output schema, the definition is thin: it says nothing about partial-update behavior, side effects on related contact data, or the shape of a successful response. The permission and endpoint lines are the minimum, not enough for an agent to call this confidently.

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% and the schema already documents each body field, null-clearing behavior, and the email/phone mutual requirement, so no compensation is needed here. The description adds nothing about any of the 9 parameters, which is acceptable at full schema coverage but earns only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Update Contact" restates the tool name and title almost verbatim; the only additional content is the permission scope, the raw HTTP verb/path, and a "Tags: Contacts" line. Nothing states what an update covers (which fields, whether it is a partial or full replacement) or how it differs from the nearby update_contact_custom_attributes.

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 on when to use this instead of create_contact, update_contact_custom_attributes, or other contact mutations. The `contacts:write` permission line is a prerequisite, not a when-to-use signal, and no exclusions or alternatives are named.

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