Well

Upload statement content

well_upload_statement_content

Upload a bank statement's TEXT CONTENT (a .csv, .txt, or .xml file) directly, as an alternative to well_create_statement_upload's out-of-band file POST.

Use it when the user's statement is a small text file whose contents are verbatim in this conversation (1 MiB decoded limit). Send the content EXACTLY as you received it — never reformat, summarize, transcribe from memory, or reconstruct rows. A mangled relay imports wrong financial data.

This path is BEST-EFFORT fidelity: what Well ingests is what you relayed, not a byte-verified copy of the user's file. The response carries content_sha256 and byte_length of what the server received — report them so a corrupted relay is visible. The parsed rows, totals, and import outcome arrive via well_get_statement_import_result with the returned document_id, not in this response.

PDFs and images NEVER go here (the model cannot relay their bytes faithfully) — use well_upload_statement_bytes. XML with DOCTYPE/ENTITY declarations is rejected. Upload one statement file per call — call this tool once per file. The document enters the same import pipeline as an in-app upload (detection, dedup, promotion).

Input Schema

TableJSON Schema

Name	Required	Description
`filename`	Yes	The statement's file name, e.g. "statement.csv". Only its extension selects the format.
`content_text`	Yes	The file's full text content, verbatim. UTF-8 encoded on the wire; capped at 1 MiB decoded.
`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
`byte_length`	No
`document_id`	No	Poll well_get_statement_import_result with this id for the import outcome.
`deduplicated`	No	True when an identical document was already in the workspace — nothing was imported twice.
`content_sha256`	No	SHA-256 (hex) of the payload the server received — compare against your source to verify fidelity.
`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 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only mark readOnlyHint=false and destructiveHint=false. The description goes far beyond by warning 'this path is BEST-EFFORT fidelity' and instructing the agent to report content_sha256 and byte_length so a corrupted relay is visible. It also discloses that parsed rows arrive via well_get_statement_import_result, not in this response, and that it enters the same import pipeline. This adds critical behavioral context not available from structured data.

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 long but every sentence earns its place. It front-loads the core purpose and usage condition, then covers exclusions, limitations, and response handling in a logical order. While it could be trimmed slightly, the density of actionable detail justifies the length without being redundant.

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 complexity (5 params, one binary sibling, an out-of-band alternative, and a downstream import result), the description covers everything an agent needs to call it correctly: exact-content relay, size cap, rejection rules, one-per-file constraint, how to obtain the import result, and how to handle workspace/conversation scoping. The presence of an output schema further reduces the burden, yet the description still explains what to expect and report.

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. The description adds material value beyond the schema: it mandates 'Send the content EXACTLY as you received it — never reformat, summarize, transcribe from memory, or reconstruct rows,' explains that the filename extension selects format, clarifies workspace_id selection when multiple workspaces are authorized, and specifies how conversation_id should be sourced. These are operational semantics an agent could not infer from the parameter names alone.

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 by stating a specific verb and resource: 'Upload a bank statement's TEXT CONTENT' and positions it as an alternative to well_create_statement_upload's out-of-band POST. It explicitly distinguishes it from well_upload_statement_bytes for binary files, so an agent can immediately tell which of the two sibling tools to use based on file type.

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?

Gives explicit conditions for use: 'Use it when the user's statement is a small text file whose contents are verbatim in this conversation (1 MiB decoded limit).' It also states clear exclusions: 'PDFs and images NEVER go here' and names the alternative tool, plus rejects XML with DOCTYPE/ENTITY declarations. Even the one-file-per-call rule is spelled out. Nothing is left to inference.

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?