Skip to main content
Glama

Update company

well_update_company
Destructive

Update an existing company in the current workspace.

Use this tool when the user asks to change, fix, rename, or edit a company's fields.

REQUIRED: company_id OPTIONAL (only include fields the user wants changed): name, description, domain, registered_name, trade_name, tax_id_value, tax_id_type, registry_country (ISO 3166-1 alpha-2, e.g. "FR"), business_type, registered_value, registry_name, locale (ISO 639-1 two-letter language code, e.g. "en", "fr" — not "en_US").

CATEGORIES (a counterparty's industry): pass category_ids — the COMPLETE set of category ids the company should carry. It REPLACES the current set: ids you leave out are unlinked, and [] clears every category. Omit the field to leave the categories untouched. Read the catalog first with well_query_records({ root: "categories", whereClause: { category_type: { _eq: "company" } } }) and pass ids from it — an id that is not a category_type = "company" row is refused, and this tool never creates a category.

NOT CHANGEABLE via this tool: emails, phones, locations, linked people, media. Those require dedicated tools (not yet available).

PROVENANCE: decision says HOW the set was chosen. accepted_suggestion — the user let a category the classifier had already proposed stand, without touching it. explicit — the user chose the labels.

A request the user typed is always an explicit choice, so never send accepted_suggestion from a conversation. The affirmation belongs to the categorization card, where a pre-filled picker the reader leaves alone is the only thing that can be let stand; a user who names a category in words has chosen it, even when they say they agree with a suggestion. Omit the field and the write is explicit.

The server checks an accepted_suggestion claim against the company's own pending proposals and returns explicit when the written set matches none of them, so the claim can never manufacture classifier provenance.

Returns { success: true, company_id, name } on success — plus category_count, the number of categories the company carries afterwards, and decision, the provenance the server settled on, when the call passed category_ids. Returns { success: false, error } on failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoCompany name
domainNoPrimary website domain (e.g. acme.com)
localeNoPreferred language as an ISO 639-1 two-letter code (e.g. en, fr, de). Pass null to clear.
decisionNoHow the user arrived at `category_ids`. Omit it: a request the user typed is an explicit choice, and accepted_suggestion belongs to the categorization card. See the description.
company_idYesThe UUID of the company to update (required)
trade_nameNoTrading name / DBA
descriptionNoBrief company description; pass null to clear
tax_id_typeNoTax identifier type (VAT, SIRET, EIN, ...)
category_idsNoThe COMPLETE set of company-category ids this company should carry. Replaces the current set; [] clears it; omit to leave categories unchanged.
tax_id_valueNoTax identifier value (VAT, SIRET, EIN, ...)
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
business_typeNoBusiness type / legal form
registry_nameNoRegistry name
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
registered_nameNoOfficial registered legal name
registered_valueNoRegistry identifier value
registry_countryNoISO 3166-1 alpha-2 country code of the registry (e.g. FR, US)
ledger_default_sourceNoHow the AP/AR pick was made. The only value this write accepts is `human_override`: the person chose the account from the chart of accounts. Optional, and it defaults to `human_override`, so a plain assign needs it not at all.
account_payable_default_idNoThe counterparty's default account-payable ledger account (a vendor payable, FR PCG 401). Set it for a counterparty you pay. Omit to leave it; null clears it. Read the ids with `well_list_ledger_accounts`.
account_receivable_default_idNoThe counterparty's default account-receivable ledger account (a customer receivable, FR PCG 411). Set it for a counterparty that pays you. Omit to leave it; null clears it. Must differ from the payable default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
errorNo
successYes
decisionNo
company_idNo
category_countNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / account_payable_default_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "format": "uuid",
      +      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The counterparty's default account-payable ledger account (a vendor payable, FR PCG 401). Set it for a counterparty you pay. Omit to leave it; null clears it. Read the ids with `well_list_ledger_accounts`."
      +}
    • addedInput schema / properties / account_receivable_default_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "format": "uuid",
      +      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The counterparty's default account-receivable ledger account (a customer receivable, FR PCG 411). Set it for a counterparty that pays you. Omit to leave it; null clears it. Must differ from the payable default."
      +}
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.",
      +  "type": "string"
      +}
    • addedInput schema / properties / ledger_default_source
      Added value: +{
      +  "description": "How the AP/AR pick was made. The only value this write accepts is `human_override`: the person chose the account from the chart of accounts. Optional, and it defaults to `human_override`, so a plain assign needs it not at all.",
      +  "enum": [
      +    "human_override"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_note
      Added value: +{
      +  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_source
      Added value: +{
      +  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
      +  "enum": [
      +    "host_meta",
      +    "argument",
      +    "minted"
      +  ],
      +  "type": "string"
      +}
  2. Changed7 schema fields changed
    • addedInput schema / properties / decision
      Added value: +{
      +  "description": "How the user arrived at `category_ids`. Omit it: a request the user typed is an explicit choice, and accepted_suggestion belongs to the categorization card. See the description.",
      +  "enum": [
      +    "accepted_suggestion",
      +    "explicit"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / description / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 250,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / domain / anyOf
      Previous value: -[
      -  {
      -    "maxLength": 255,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 500,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / registered_value / anyOf
      Previous value: -[
      -  {
      -    "maxLength": 50,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 100,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / tax_id_value / anyOf
      Previous value: -[
      -  {
      -    "maxLength": 50,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 255,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / trade_name / anyOf
      Previous value: -[
      -  {
      -    "maxLength": 255,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 100,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedOutput schema / properties / decision
      Added value: +{
      +  "enum": [
      +    "accepted_suggestion",
      +    "explicit"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / description / anyOf
      Previous value: -[
      -  {
      -    "maxLength": 1000,
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  4. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Target workspace. Omit to use the only authorized workspace, or (for read tools) to query all authorized workspaces grouped by workspace. Required for write tools when the token authorizes more than one workspace."New value: +"Target workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which."
  5. Changed2 schema fields changed
    • addedInput schema / properties / category_ids
      Added value: +{
      +  "description": "The COMPLETE set of company-category ids this company should carry. Replaces the current set; [] clears it; omit to leave categories unchanged.",
      +  "items": {
      +    "format": "uuid",
      +    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +    "type": "string"
      +  },
      +  "maxItems": 20,
      +  "type": "array"
      +}
    • addedOutput schema / properties / category_count
      Added value: +{
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
  6. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations provide destructiveHint=true and readOnlyHint=false; the description adds precisely what the annotations cannot: category_ids REPLACES the whole set (unlinking omitted ids), [] clears all, and null clears individual fields — concretely specifying what 'destructive' means here. It also discloses the server-side provenance check (an accepted_suggestion claim that matches no pending proposal is downgraded to explicit) and idempotency/retry behavior. 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?

Well-structured with bold section headers, front-loaded purpose, and required/optional summary; at roughly 650 words for a 21-parameter tool, the length is mostly earned. The provenance section repeats the explicit-vs-accepted_suggestion distinction three times and could be tightened, which prevents a 5.

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

Completeness5/5

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

For the most complex tool in the set — 21 params, full-replacement category semantics, provenance validation, multi-workspace writes — the description covers when to use it, what not to touch, prerequisites, exact success shape ({ success: true, company_id, name } plus category_count and decision), and failure shape. Nothing an agent needs to call it correctly is left to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), yet the description carries semantics the schema omits or defers: the decision schema literally says 'See the description' and the description delivers the full provenance rules; category_ids gets the validation rule (ids must be category_type='company' or they are refused; the tool never creates categories); workspace_id gets its multi-workspace ambiguity explained ('a write lands in exactly one workspace and this call would not say which'). This materially changes how the agent invokes the tool.

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?

States a specific verb+resource+scope: 'Update an existing company in the current workspace,' with an explicit trigger set ('change, fix, rename, or edit a company's fields'). The 'existing' qualifier separates it from well_create_company, and the NOT CHANGEABLE list (emails, phones, locations, linked people, media) draws a clear boundary against sibling tools. An agent can distinguish this from the ~85 siblings immediately.

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?

Contains an explicit when-to-use sentence ('Use this tool when the user asks to change, fix, rename, or edit...'), an explicit when-not list ('NOT CHANGEABLE via this tool: emails, phones... require dedicated tools'), and a named prerequisite/alternative tool (read the categories catalog first with well_query_records). This is textbook-explicit routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources