Skip to main content
Glama

Update invoice design

well_update_invoice_design

Set one invoice's design: the layout it prints in, the ink, the language, whether a customer-portal address is printed, and which note, tax rate and payment means back the payment-terms, tax-regime, legal-mentions and payment-means rows.

REQUIRED: invoice_id. OPTIONAL (only pass fields you are changing; an omitted field is left unchanged):

  • design_layout, design_theme, design_locale, design_customer_portal — a choice from the closed set well_show_invoice_design returns under layouts and the inline field options.

  • design_payment_terms_note_id, design_tax_rate_id, design_legal_mentions_note_id, design_payment_means_id — the UUID of a note / tax rate / payment means ALREADY in this workspace, or null to clear the choice. A record from another workspace, or one that does not exist, is refused rather than silently ignored.

When a person selects a listed payment account, pass that account's payment_means_id as design_payment_means_id. Never call with only invoice_id: no design fields means nothing is saved. This does not mint a customer-portal address — it records the PREFERENCE a later mint reads. Call well_show_invoice_design first to see which payment means can carry one today.

Input Schema

NameRequiredDescriptionDefault
invoice_idYesThe UUID of the invoice to update.
design_themeNo
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.
design_layoutNo
design_localeNo
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.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
design_tax_rate_idNo
design_customer_portalNo
design_payment_means_idNo
design_payment_terms_note_idNo
design_legal_mentions_note_idNo

Output Schema

NameRequiredDescriptionDefault
codeNo
errorNo
successYes
invoice_idNo
failure_classNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
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. Changed2 schema fields changed
    • addedOutput schema / properties / code
      Added value: +{
      +  "const": "invoice_design_attributes_required",
      +  "type": "string"
      +}
    • addedOutput schema / properties / failure_class
      Added value: +{
      +  "enum": [
      +    "transient",
      +    "not_found",
      +    "bad_input",
      +    "refused",
      +    "unknown"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • removedInput schema / properties / design_accent
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "pattern": "^#[0-9a-fA-F]{6}$",
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ]
      -}
  3. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  4. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  5. Changed2 schema fields changed
    • changedInput schema / properties / design_layout / enum
      Previous value: -[
      -  "statement",
      -  "terminal",
      -  "proposal",
      -  "banking",
      -  "feenote",
      -  "studio",
      -  "masthead",
      -  "headline"
      -]New value: +[
      +  "statement",
      +  "terminal",
      +  "proposal",
      +  "banking",
      +  "feenote",
      +  "studio",
      +  "masthead",
      +  "headline",
      +  "template"
      +]
    • addedOutput schema / properties / newly_connected
      Added value: +{
      +  "description": "Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "type": "string"
      +      },
      +      "service_id": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "service_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / design_accent
      Added value: +{
      +  "anyOf": [
      +    {
      +      "pattern": "^#[0-9a-fA-F]{6}$",
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  7. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations (non-readonly, non-destructive, closed-world) by disclosing partial-update semantics (omitted = unchanged), null-to-clear behavior, refusal of non-existent or cross-workspace UUIDs rather than silent ignores, and the important distinction that this stores a preference for a later mint rather than minting a portal address. That last point is exactly the kind of non-obvious behavior an agent would otherwise get wrong.

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?

Front-loads the purpose, then a REQUIRED/OPTIONAL block, then the pitfalls — a clean structure. The first sentence is a long multi-clause run-on and the 'When a person selects a listed payment account' line is slightly prose-heavy, but nothing is redundant.

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?

With an output schema present, the description needn't explain returns, and it covers prerequisites, error refusal, and partial-update semantics thoroughly. The remaining hole is sibling routing — no guidance on when to use this versus the workspace-design or preview variants — in a list containing both.

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 only 38%, so the description carries real weight: it explains that enum-valued design fields draw from `well_show_invoice_design`'s `layouts` output, and that the *_id fields take UUIDs of existing workspace records or null. Minor gap: the 'inline field options' phrasing is vague and enum members themselves are left entirely to the schema.

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?

Opens with a specific verb+resource scoped to one invoice ('Set one invoice's design') and enumerates the concrete facets it controls (layout, theme, locale, portal address, linked note/tax-rate/payment-means rows). It implicitly separates itself from workspace-level design via 'one invoice's', though it never names `well_create_workspace_invoice_design` or `well_preview_invoice_design` explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational guidance: call `well_show_invoice_design` first, never call with only `invoice_id`, and pass only fields being changed. It also tells the agent how to translate a human choice of payment account into `design_payment_means_id`. Missing an explicit contrast with the workspace-default design tool, so an agent could still confuse per-invoice vs workspace-wide updates.

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