Well

Upload statement bytes

well_upload_statement_bytes

Upload a bank statement file's BINARY CONTENT (PDF or image) as base64, so the file's real bytes reach Well without any out-of-band HTTP call.

Use it for PDF and image statements up to 5 MiB decoded (the base64 text may be roughly a third larger). Base64-encode the file's bytes EXACTLY — never re-encode a screenshot, a transcription, or a summary of the file. Optionally send the file's sha256 (hex); the server decodes, hashes, and rejects a mismatch, proving the bytes arrived intact.

The response carries content_sha256 and byte_length of the decoded payload — report them for verification. The parsed rows, totals, and import outcome arrive via well_get_statement_import_result with the returned document_id.

Text statements (.csv/.txt/.xml) whose contents are verbatim in this conversation can go through well_upload_statement_content instead. 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
`sha256`	No	The source file's SHA-256 (hex). When sent, a mismatch with the decoded bytes rejects the upload.
`filename`	Yes	The statement's file name, e.g. "statement.csv". Only its extension selects the format.
`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.
`content_base64`	Yes	The file's bytes, base64-encoded (RFC 4648; whitespace tolerated). Decoded cap: 5 MiB.
`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 declare readOnlyHint=false and destructiveHint=false; the description carries substantial behavioral disclosure: it is a write that lands in exactly one workspace, it enforces a 5 MiB decoded cap, verifies sha256 and rejects mismatches, and feeds the same import pipeline (detection, dedup, promotion) as an in-app upload. It also discloses what happens after upload (rows/totals via well_get_statement_import_result) and instructs reporting content_sha256/byte_length for verification. This far exceeds annotation coverage.

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 (three paragraphs) but justified by the tool's complexity — binary encoding, verification, pipeline behavior, and workspace semantics. It is front-loaded with the core purpose and constraints, and every sentence carries distinct information. Could trim minor redundancy around the pipeline mention, but overall efficient.

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 6-parameter mutation tool with an output schema, the description is remarkably complete: size limits, encoding exactness, integrity verification, response/verification instructions, sibling routing, per-call usage, workspace disambiguation, and post-upload outcome flow are all covered. Nothing an agent needs 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3, but the description adds real meaning: it clarifies that base64 must encode the file's exact bytes ('never re-encode a screenshot, a transcription, or a summary'), explains the sha256 mismatch-rejection flow, and contextualizes the workspace_id ambiguity. This is meaningful value beyond the schema's field docs, earning a 4.

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 precise verb+resource statement: 'Upload a bank statement file's BINARY CONTENT (PDF or image) as base64'. It explicitly differentiates from the sibling well_upload_statement_content by contrasting binary (PDF/image) vs text (.csv/.txt/.xml) statements, and names the alternative tool directly. An agent can distinguish this from all ~80 siblings without opening schemas.

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?

Usage is explicit: 'Use it for PDF and image statements up to 5 MiB decoded' and 'Text statements (.csv/.txt/.xml) whose contents are verbatim in this conversation can go through well_upload_statement_content instead.' It also states the one-call-per-file rule and notes when workspace_id must be supplied. Both the when and the when-not/alternative are spelled out.

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?