Well

Assign account

well_assign_account

Destructive

Attach a bank account to a company, and say whether the workspace owns it.

Use this when an account carries no company, or when its ownership is still unknown — the two states a figure that walks account ownership cannot be computed over.

REQUIRED: account_id, plus at least one of company_id or ownership.

ownership is one of:

"workspace" — the business's own account
"counterparty" — someone else's, seen on an invoice or a payment
"unknown" — not yet classified

This changes figures, not just a label. An account marked "workspace" puts its transactions inside the internal-transfer rule: a movement with both legs on owned accounts stops counting as money leaving the business. Marking a counterparty's account as the workspace's own therefore removes real spend from the burn, quietly and consistently, with no error anywhere.

So do not guess it. An account's owner cannot be read off its name, its bank, or the company that appears most often beside it. Ask, or leave it unknown — "not yet classified" is a truthful state and a wrong classification is not.

company_id must name a company in the SAME workspace as the account; a company from another workspace is refused rather than resolved. Pass company_id: null to detach.

Returns { success: true, account_id, ownership, company_id } on success.

Input Schema

TableJSON Schema

Name	Required	Description
`ownership`	No	Whether the workspace owns the account: "workspace", "counterparty", or "unknown".
`account_id`	Yes	The UUID of the account to assign (required)
`company_id`	No	The company that owns the account, in the same workspace. `null` detaches it.
`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.
`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.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`success`	Yes
`ownership`	No
`account_id`	No
`company_id`	No
`company_name`	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.
`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.

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

AddedSep 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations already mark this as destructive, and the description goes well beyond that by explaining exactly what changes: 'This changes figures, not just a label.' It details how marking an account as workspace affects the internal-transfer rule and can quietly remove real spend from burn, and it notes that cross-workspace companies are refused rather than resolved. No contradiction found.

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?

The description is longer than average but well-structured: purpose first, then use case, then required-field rule, enum semantics, and a prominent warning in bold. Nearly every sentence earns its place, though the cautionary section could be tightened slightly without losing impact.

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 that this is a write tool with cross-entity side effects, the description covers when to call it, prerequisites, enum semantics, constraints, error behavior, detach semantics, and the return shape. It is complete enough for an agent to invoke it correctly without needing additional context.

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%, but the description adds critical semantics beyond it: the constraint 'account_id, plus at least one of company_id or ownership' is not in the schema's required list. It also explains the meaning of each ownership enum value and clarifies that passing company_id: null detaches, which adds real value over the schema descriptions.

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: 'Attach a bank account to a company, and say whether the workspace owns it.' This clearly distinguishes it from the sibling well_assign_missing_invoice_owners, which targets invoice ownership, not account ownership.

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 explicitly says to use this tool when an account carries no company or when ownership is still unknown. It also warns against guessing and tells the user to leave ownership as 'unknown' instead. However, it does not name concrete sibling alternatives for other scenarios, so the when-not guidance is implicit rather than fully explicit.

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?