Well

Preview invoice design

well_preview_invoice_design

Read-only

Draw invoice designs with the given settings, as the sheet markup the PDF path prints. The invoice-design card calls this when it opens and when a setting changes; it changes nothing.

REQUIRED: layout, theme, locale — the choices well_show_invoice_design returns. OPTIONAL: invoice_id (the invoice being designed: its parties, lines, totals and reference are drawn instead of a sample), payment_means_id (with invoice_id, the chosen account whose coordinates the draft prints), layouts (further designs to draw with the same settings), tax (the chosen regime's percent, whether it exempts, and its name), payment_terms_note_id (the chosen payment-terms note: its full text prints with its variables filled, as on the PDF), payment_means_label (only for a payment means that prints bank coordinates), legal_mentions_note_id (the chosen legal-mentions note: its full text prints with its variables filled, as on the PDF).

Returns data.sheets, one entry per design with its layout, its paper and its sheet_html. The requested layout comes first. The dark theme is a class the mounting page puts on the sheet's wrapper, so sheet_html is the same for both themes.

Input Schema

Name	Required	Description
`tax`	No	The chosen tax regime.
`theme`	Yes	The ink the page is printed in.
`layout`	Yes	The design to draw: one of the compiled designs.
`locale`	Yes	The language and number format of the page.
`layouts`	No	Further designs to draw with the same settings, beside `layout`.
`invoice_id`	No	The invoice being designed. Without it, a sample invoice is drawn.
`workspace_id`	No	Target 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_id`	No	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.
`workspace_scope`	No	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.
`payment_means_id`	No	The chosen payment means. With invoice_id, the draft prints its coordinates.
`payment_means_label`	No	The chosen payment means' name, only when it prints bank coordinates.
`payment_terms_note_id`	No	The chosen payment-terms note. Its full text prints with its variables filled, as on the PDF.
`legal_mentions_note_id`	No	The chosen legal-mentions note. Its full text prints with its variables filled, as on the PDF.

Output Schema

Name	Required	Description
`data`	No
`error`	No
`success`	Yes
`conversation_id`	No	The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
`newly_connected`	No	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.
`resolved_workspace`	No	The workspace that answered, when the caller named none and the token authorizes several.
`conversation_id_note`	No	Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.
`conversation_id_source`	No	Where 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.

Changed2 schema fields changedOct 28, 2026
- 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"
+]
```

Changed1 schema field changedOct 12, 2026

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."

Changed1 schema field changedOct 8, 2026

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"
+}

Changed2 schema fields changedOct 6, 2026

changedInput schema / properties / layout / description

Previous value: -"The design: one of the document_slugs well_list_generative_documents returns."New value: +"The design to draw: one of the compiled designs."

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"
+}

AddedOct 2, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuinely non-obvious behavior — that the dark theme is only a wrapper class, so sheet_html is identical for both themes, and that data.sheets returns one entry per design with the requested layout first. It does not discuss permissions, rate limits, or failure modes, keeping it below a 5.

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 core action and read-only nature, then organizes required vs optional in a scannable block. The parenthetical parameter explanations are dense, but every clause carries information rather than repeating the schema.

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 and readOnly annotations set, the description fills the remaining gaps: it explains what data.sheets contains, ordering, and how theme affects sheet_html. Given the 13 parameters (11 optional) and nested tax object, it is complete enough 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 100%, so the baseline is 3, but the description earns more by explaining what several optional params actually affect — invoice_id replaces the sample invoice's parties/lines/totals, payment_means_id prints the chosen account's coordinates, note ids print full text with variables filled — context the schema descriptions only gesture at.

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?

States a specific verb and resource — 'Draw invoice designs ... as the sheet markup the PDF path prints' — which is precise enough to distinguish it from the create/update invoice-design siblings. It references well_show_invoice_design as the source of the required choices, but doesn't explicitly contrast with well_preview_invoice_fetch or well_show_invoice_design itself, so it stops short of full sibling differentiation.

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

Usage Guidelines3/5

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

Says the invoice-design card calls this when it opens and when a setting changes, which implies context, but gives no explicit guidance on when an agent should reach for this tool versus well_show_invoice_design or well_preview_invoice_fetch. The 'it changes nothing' note clarifies it is a side-effect-free preview, which partially compensates.

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

All Well tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?