Skip to main content
Glama

Get workspace invoice design offer

well_get_workspace_invoice_design_offer
Read-only

Read what a built invoice template would reuse from the invoice it was built from, before the user keeps it as the workspace's design.

Pass the template's document_id. The result lists the logo cut from the invoice (logo_present), the legal mentions text printed on it (legal_mentions, one line per line), the company that issued the invoice (issuer_name), and issuer_relation: own_company when that company is the workspace's own, other_company when it is a different company such as a supplier, unknown when nothing proves whose invoice it was. starts_kept is true only for own_company.

Show the user this list in plain words BEFORE the keep: the mentions text itself, the issuer's name, and, when issuer_relation is not own_company, say that the invoice is not the workspace's own. Ask whether to keep or remove the logo and whether to keep or remove the mentions; for other_company or unknown, both start as removed. When legal_mentions_unverified is true, the reading found no mentions on an invoice that is not the workspace's own, yet the template may still print a footer copied from it: tell the user so, and offer a revision that removes that footer before the keep. Then call well_create_workspace_invoice_design with the answers, the same issuer_relation and the same offer_token. This tool changes nothing.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
document_idYesThe built template the user may keep.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
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.
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.

Output Schema

NameRequiredDescriptionDefault
errorNo
successYes
issuer_nameNoThe company that issued the invoice, as the page names it.
offer_tokenNoNames this offer. Pass it unchanged to the keep: a keep with another token is refused.
starts_keptNoWhether the logo and the mentions start as kept: only for the workspace's own invoice.
logo_presentNoWhether a logo was cut from the invoice.
legal_mentionsNoThe legal mentions printed on the invoice, or null when it prints none.
refusal_reasonNoThe WellError code when the read is refused.
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
issuer_relationNoWhether that company is the workspace's own, another company, or unproven.
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.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
template_document_idNo
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.
legal_mentions_unverifiedNoTrue when the invoice is not the workspace's own and the reading found no legal mentions on it: the template may still print a footer copied from the invoice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedOutput schema / properties / issuer_name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / issuer_name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / legal_mentions / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / legal_mentions / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. 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."
  3. 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"
      +}
  4. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly and non-destructive, and the description reinforces with 'This tool changes nothing'. Beyond that it discloses the offer_token handoff requirement, multi-workspace token behavior ('this read will not guess which one you mean'), the meaning of issuer_relation values, starts_kept only for own_company, and the legal_mentions_unverified edge case with its remediation — behavior the annotations do not cover.

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 front-loaded: purpose, then return fields, then the user-facing procedure, then token handling. It is long, and some UX scripting (how to phrase the warning) is verbose, but nearly every sentence carries operational instructions an agent must follow.

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 a read gate preceding a mutation, the definition covers purpose, returned fields, user confirmation flow, edge cases, and the exact next call. An output schema exists, so the field enumeration is bonus rather than a gap, and nothing needed to invoke it correctly is missing.

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 coverage is 100%, so document_id, workspace_id, conversation_id and workspace_scope are already fully documented. The description reinforces document_id ('Pass the template's document_id') and the workspace_id branching, but adds little that the schema does not already say.

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 first sentence names a specific verb and resource ('Read what a built invoice template would reuse from the invoice it was built from') and pins its position in the workflow ('before the user keeps it as the workspace's design'). It is distinguishable from well_create_workspace_invoice_design, which it explicitly names as the follow-up step.

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?

It states clearly when to call it, what to present to the user first, and exactly which tool to call next with which arguments ('well_create_workspace_invoice_design with the answers, the same issuer_relation and the same offer_token'). Token-count branching for workspace_id is spelled out. It does not explicitly exclude nearby reads such as well_preview_invoice_design or well_show_invoice_design.

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