Skip to main content
Glama
doitintl

DoiT MCP Server

Official
by doitintl

update_customer

Destructive

Update customer settings and contact details via merge-patch, covering currency, MFA requirement, allowed invite domains, contact emails, and URL slug.

Instructions

Read and update your organization's general settings. Partially updates the general settings and contact info of the customer identified by {customerId}. {customerId} must match the customer resolved from the bearer token; a token scoped to a different customer gets 403, even if that customer would otherwise be reachable through a reseller/MTS relationship. Requires the Settings permission and DoiT API access (platform:externalApi); updating allowedInviteDomains additionally requires the UsersManager permission.

The request body must use application/merge-patch+json (RFC 7396): an omitted field leaves the current value unchanged, and an explicit null also leaves it unchanged, except for urlSlug, where an explicit empty string removes the customer's active URL slug rather than leaving it unchanged.

Fields are nested exactly as getCustomer returns them - currency and allowedInviteDomains under settings, emails under contact - so every value is read and written at the same path. settings.currency accepts only the codes listed in the schema and cannot be cleared; allowedInviteDomains and contact.emails are cleared with an empty array.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contactNoCustomer point-of-contact details. Shared by the `getCustomer` response and the `updateCustomer` request body so a value is always read and written at the same path.
urlSlugNoThe customer's URL display name. An explicit empty string removes the active slug; a non-empty value must be 3-12 characters of lowercase letters, digits, or dashes, starting and ending with a letter or digit, and must be unique across all customers.
settingsNoCustomer settings. Shared by the `getCustomer` response and the `updateCustomer` request body so a value is always read and written at the same path. `currency` accepts only the listed codes; any other value is rejected with `400`. Unlike `urlSlug` and `allowedInviteDomains` it cannot be cleared - no value unsets it.
customerIdYes
customerContextNoScope the request to a specific customer by ID. Required for DoiT employees (whose token isn't tied to a single customer); omit for direct customer users.
Behavior4/5

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

Annotations already indicate `readOnlyHint: false`, `openWorldHint: true`, and `destructiveHint: true`, which signal mutation and potential destruction. The description goes beyond annotations by detailing the merge-patch behavior (omitted or null leaves unchanged, with exception for `urlSlug`), permission requirements, and the restriction that `currency` cannot be cleared. It does not mention rate limits or idempotency, but the provided context is substantial. No contradiction with annotations.

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 dense but well-structured: first paragraph sets the purpose and permissions, second explains the merge-patch semantics with edge cases, and third ties to `getCustomer` structure and specific field behaviors. It is front-loaded with the core action and prerequisites. Some redundancy with the schema descriptions exists (e.g., field nesting information), but the additional clarity justifies the length.

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 (nested objects, permissions, merge-patch behavior, clearing semantics), the description is thorough. It lacks an output schema so it doesn't explicitly describe return values, but the description focuses on the request side. It covers key edge cases (urlSlug clearing, currency non-clearable, permissions) and references `getCustomer` for symmetry, making it complete enough for agents to invoke correctly.

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 80% and the schema includes detailed descriptions for most parameters (e.g., `urlSlug` constraints, `mfaRequired` behavior, `allowedInviteDomains` permissions). The description adds meaningful context beyond the schema by explaining the merge-patch semantics, clearing behavior, and nested structure consistency with `getCustomer`. It also clarifies the `customerContext` parameter's role for DoiT employees. Given the high schema coverage, the description mostly reinforces and boosts clarity, but not all parameters (e.g., `contact.emails` detailed constraints) are fully elaborated in the description itself.

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 that the tool reads and updates general settings, and precisely describes the partial update semantics for the customer identified by `{customerId}`. It explicitly names the resource (customer) and the operation (partially update), and ties it to the sibling `getCustomer` tool, distinguishing it as the write counterpart.

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 when-to-use guidance: it's for updating settings/contact info of the customer matching the bearer token. It states when it must NOT be used (different customer yields 403), requires the `Settings` permission and external API access, and notes the extra `UsersManager` permission for `allowedInviteDomains`. It also explains the merge-patch semantics and how to clear fields, which is essential for correct usage.

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/doitintl/doit-mcp-server'

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