Well

Set accounting settings

well_upsert_accounting_settings

Destructive

Set the workspace's accounting settings: fiscal year start month, first fiscal year start date, country, base currency, accounting framework, chart-of-accounts confirmation, the incorporation date, and the tax ID (value and type together).

Provide only the fields you are changing; omitted fields are left untouched. An empty call (no fields) is refused. tax_id_value and tax_id_type must be provided together.

Only a workspace owner or admin may set the accounting settings. A caller without that role is refused, not silently ignored.

Changing the fiscal year start month moves the whole fiscal calendar, so it is REFUSED when a period is locked or a close is in progress — the tool surfaces that refusal rather than forcing it. When the change is allowed, it soft-deletes the workspace's regenerable DRAFT journal entries so they re-mint on the new coordinates; VALIDATED and LOCKED entries are never touched.

These are accounting-critical values. Confirm each one with the user before calling and never guess them — do not infer a country, currency, framework, start month, or tax ID the user did not state.

The tax ID here updates the workspace's anchored company and its settings mirror together, so the two never drift. To set WHICH company is anchored, use well_set_own_company; to set that company's tax ID, use this tool.

Input Schema

TableJSON Schema

Name	Required	Description
`country`	No	ISO 3166-1 alpha-2 country code.
`tax_id_type`	No	The tax id's type (SIREN, VAT, EIN, …). Provide it together with tax_id_value.
`tax_id_value`	No	The company's tax id value. Provide it together with tax_id_type; one without the other is refused.
`workspace_id`	No	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.
`base_currency`	No	ISO 4217 currency code.
`coa_confirmed`	No	Whether the chart of accounts has been confirmed.
`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.
`idempotency_key`	No	Optional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
`incorporation_date`	No	The company's incorporation / registration date as YYYY-MM-DD, or null to clear it.
`accounting_framework`	No	The accounting framework the books follow.
`fiscal_year_start_month`	No	Calendar month (1-12) the fiscal year starts on, or null to clear it.
`first_fiscal_year_start_date`	No	First fiscal year start date as YYYY-MM-DD, or null to clear it.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`country`	No
`success`	Yes
`tax_id_type`	No
`tax_id_value`	No
`base_currency`	No
`coa_confirmed`	No
`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.
`incorporation_date`	No
`accounting_framework`	No
`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.
`fiscal_year_start_month`	No
`first_fiscal_year_start_date`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 22, 2026

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

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

Changed6 schema fields changedSep 15, 2026

addedInput schema / properties / incorporation_date

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The company's incorporation / registration date as YYYY-MM-DD, or null to clear it."
+}

addedInput schema / properties / tax_id_type

Added value: +{
+  "description": "The tax id's type (SIREN, VAT, EIN, …). Provide it together with tax_id_value.",
+  "type": "string"
+}

addedInput schema / properties / tax_id_value

Added value: +{
+  "description": "The company's tax id value. Provide it together with tax_id_type; one without the other is refused.",
+  "maxLength": 50,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / incorporation_date

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / tax_id_type

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / tax_id_value

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

Changed1 schema field changedAug 31, 2026

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

AddedAug 27, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations' destructiveHint, the description discloses substantial behavior: partial updates leave omitted fields untouched, fiscal-year changes are refused when periods are locked or closes are in progress, and allowed changes soft-delete only regenerable DRAFT journal entries while leaving VALIDATED and LOCKED entries untouched. It also explains that the tax ID updates the anchored company and its settings mirror together.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but dense and front-loaded: the first sentence states the purpose and enumerates the affected fields, and every subsequent sentence adds operational or safety-relevant guidance. It avoids redundant schema restatement and remains readable despite covering many edge cases.

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?

Given the tool's destructive hint, 12 parameters, and no required fields, the description is unusually complete: it covers partial-update semantics, refusal conditions, role requirements, side effects on journal entries, user-confirmation expectations, and the relationship to a sibling tool. The output schema exists, so lack of return-value explanation is acceptable.

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 description does not need to restate parameter formats. It adds valuable interaction semantics the schema cannot express: omitted fields are left untouched, an empty call is refused, tax_id_value and tax_id_type must be provided together, and changing fiscal_year_start_month has side effects on journal entries.

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 opens with a specific verb and resource: 'Set the workspace's accounting settings' followed by an explicit list of the fields involved. It also distinguishes itself from the closely related sibling well_set_own_company by stating that this tool sets the tax ID while the sibling sets which company is anchored.

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 invocation conditions: only workspace owners or admins may call it, unauthorized callers are refused, and empty calls are refused. It also gives an alternative ('To set WHICH company is anchored, use well_set_own_company') and strong guidance to confirm values with the user before calling.

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?