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

Behavior5/5

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

Annotations only say the tool is a non-read-only, non-destructive write, so the description carries the burden and does it thoroughly. It discloses best-effort fidelity, that content_sha256 and byte_length reflect what the server received, that rows/outcomes arrive separately via well_get_statement_import_result, and that the document enters the same import pipeline as an in-app upload.

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 dense but every sentence earns its place: purpose, fidelity warning, reporting requirement, follow-up result retrieval, exclusions, and security constraint. It is front-loaded with the core action and alternatives, and the length is justified by the tool's nuance.

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?

The description covers use case, constraints, fidelity behavior, server-verification reporting, follow-up result retrieval, and format exclusions. With an output schema present, the lack of return-value detail is fine; nothing an agent needs to invoke this safely and correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains filename, content_text, workspace_id, and idempotency_key. The description reinforces the verbatim requirement and 1 MiB limit, but it adds little parameter-level meaning beyond what the schema provides.

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's TEXT CONTENT directly from the conversation, as an alternative to out-of-band POST. It clearly distinguishes from well_create_statement_upload and well_upload_statement_bytes, so there is no ambiguity about which sibling tool is intended.

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 states when to use this tool: small text files (.csv, .txt, .xml) whose contents are verbatim in conversation and under 1 MiB. It also gives exclusions and alternatives: PDFs/images must go to well_upload_statement_bytes, and XML with DOCTYPE/ENTITY declarations is rejected.

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?