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

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (which only indicate a write and non-destructive operation), the description discloses meaningful behavior: server-side decode and hash verification, rejection on sha256 mismatch, response fields content_sha256 and byte_length, and routing of import results through well_get_statement_import_result. It also warns against re-encoding screenshots or transcriptions, which is valuable operational context.

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?

Although longer than typical descriptions, every sentence earns its place: scope, size limit, encoding requirement, integrity verification, response handling, import-result routing, and alternative tool. The critical binary-vs-text distinction is front-loaded, and the structure is logical.

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 and the presence of a full output schema, the description is complete. It covers the exact payload semantics, size constraints, verification behavior, post-upload flow, and relationship to the sibling text-upload tool. Nothing call-critical 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%, so the baseline is 3. The description adds real value beyond the schema by stressing exact base64 encoding, warning against re-encoding non-file content, noting that filename extension selects format, and explaining the sha256 integrity check. This pushes it above baseline.

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: uploading a bank statement file's BINARY CONTENT as base64. It clearly distinguishes this binary/PDF/image path from the text-based sibling well_upload_statement_content, so an agent can tell the two apart 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?

It explicitly says to use this tool for PDF and image statements up to 5 MiB, and that text statements whose contents are verbatim should go through well_upload_statement_content instead. This gives the agent both the positive condition and the named alternative, with no inference required.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: CRUD for companies, people, and invoices; financial analytics (cash, cost, runway, holdings); connector management and invocation; schema discovery; querying; reconciliation; and contact channel management. No two tools could be confused for the same action.

Naming Consistency5/5

All tools follow the `well_verb_noun` pattern with consistent verb choices (create, get, list, update, delete, add, remove, run, resolve, query, invoke). The naming is predictable and makes the tool's purpose immediately clear.

Tool Count4/5

With 26 tools, the set is slightly above the ideal 3-15 range, but every tool earns its place given the breadth of the domain (CRM, invoicing, financial analytics, reconciliation, connector management). The count is well-scoped and not excessive.

Completeness4/5

The tool surface covers core CRUD, financial KPIs, reconciliation, and connector management. Minor gaps exist (e.g., no direct tool to update contact channels or manage accounts), but the query and schema tools allow agents to work around them, and the primary workflows are fully supported.

Resources

Need Help?