Well

List missing-invoice owners

well_list_missing_invoice_owners

Read-only

List the settled expense TRANSACTIONS a past period is still missing a supplier invoice for, one row per line, each with its current owner SET. Use it for "who owes the missing invoices?" and as the input to well_assign_missing_invoice_owners.

Each row reports its TRANSACTION owner SET. An empty owners set means no transaction owner set was found; it does not prove that no card rule or other legacy owner exists. The bucket is no_owner_set, assigned_to_me, or assigned_to_others, computed from that set against the calling person. This lists the SAME missing invoices well_list_missing_invoices shows, but flattened to lines you can assign; there is no per-card grouping and no scope: "card".

Name the period ONE way: { calendar_year, calendar_month }, { fiscal_year, fiscal_period }, or periods: [...] for several months (1-12), or name NO period to use the months selected on the period card in this conversation. Every month must have ended.

Each row carries transaction_id (pass it to well_assign_missing_invoice_owners), date, description, counterparty (name, id, and logo when a provider was matched), amount, currency, and base_amount. Rows with no owner set come first, then the caller's own, then those owned only by others; no_owner_set_count, assigned_to_me_count, and assigned_to_others_count summarize the split over the returned rows.

The rows per counterparty are a BOUNDED sample (sampled: true), so row_count may be fewer than transaction_count — the window's true total — and transactions_omitted is the difference. Use it to assign owners, not to count a period's total gaps; well_list_missing_invoices carries the full per-counterparty totals.

This tool reads the user's data and changes none of it.

When the token authorizes one workspace, call this directly — no other tool call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

TableJSON Schema

Name	Required	Description
`periods`	No	Several calendar months in one call, 1-12. Each month costs one separate read, so name only the months you need. Duplicates are refused.
`fiscal_year`	No	Fiscal year (the calendar year the workspace's fiscal year STARTED in).
`workspace_id`	No	Target workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
`calendar_year`	No	Calendar year, e.g. 2026.
`fiscal_period`	No	Fiscal period, 1-12. The adjustment period (13) is refused: it has no calendar month.
`calendar_month`	No	Calendar month, 1 = January … 12 = December.
`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.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`sampled`	No	True always: each counterparty's rows are a bounded sample, so a counterparty whose every gap fell outside the sample is under-represented. Use it to assign owners, not to count a period's total gaps.
`success`	Yes
`next_step`	No	What to do with the card this result renders. Added by the dispatcher when the card asks for a click.
`row_count`	No	Transaction rows returned in `transactions` (a bounded sample per counterparty).
`me_person_id`	No	The calling person, against which each row's `bucket` is computed; null when the token carries no person.
`transactions`	Yes	The missing-invoice lines, with no owner set first, then the caller's own, then those owned only by others.
`base_currency`	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.
`periods_covered`	No	The months the result covers, oldest first.
`transaction_count`	No	Total missing-invoice transactions the window holds across all counterparties, sampled or not.
`no_owner_set_count`	No	Returned rows with no transaction owner set.
`resolved_workspace`	No	The workspace that answered, when the caller named none and the token authorizes several.
`assigned_to_me_count`	No	Returned rows whose transaction owner set includes the caller.
`conversation_id_note`	No	Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.
`transactions_omitted`	No	Missing-invoice transactions the window holds beyond the returned sample (`transaction_count` − `row_count`).
`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.
`assigned_to_others_count`	No	Returned rows whose transaction owner set includes only other people.

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

Changed4 schema fields changedSep 10, 2026

addedOutput schema / properties / next_step

Added value: +{
+  "description": "What to do with the card this result renders. Added by the dispatcher when the card asks for a click.",
+  "type": "string"
+}

added

Output schema / properties / transactions / items / properties / counterparty / properties / matched_connector_service_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The connector standing for a `connect` route; null for a route with no matched connector."
+}

addedOutput schema / properties / transactions / items / properties / counterparty / properties / mode

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "agent",
+        "connect",
+        "upload"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "How the missing document can be collected, after the same downgrade rules the missing-invoices card applies; null when no route resolved. Word the retrieval affordance off this, never off a name."
+}

changedOutput schema / properties / transactions / items / properties / counterparty / required

Previous value: -[
-  "company_id",
-  "name",
-  "logo_url"
-]New value: +[
+  "company_id",
+  "name",
+  "logo_url",
+  "mode",
+  "matched_connector_service_id"
+]

AddedSep 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'This tool reads the user's data and changes none of it.' Beyond annotations, it discloses important behavioral traits: empty owners set does not prove no legacy owner exists, rows are a bounded sample (sampled: true) so row_count may be less than transaction_count, and the period-card fallback when no period is named. It also explains the ordering of rows and the meaning of the bucket values, which is exactly the kind of context annotations cannot carry.

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 paragraph earns its place: purpose, row semantics, period selection, output fields, sampling caveat, and workspace routing. It is front-loaded with the core purpose and the key distinction from the sibling. It could be tightened slightly, but for a tool with this many behavioral caveats the length is justified.

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, the rich output schema, and the 100% schema coverage, the description covers everything an agent needs to call it correctly: what it returns, how rows are ordered, what the counts mean, the sampling caveat, the period-card fallback, and the workspace_id rule. The output schema exists, so the description need not enumerate return fields, but it still names the key fields and their purpose. Nothing 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 description coverage is 100%, so the schema already documents every parameter. The description adds value by explaining the period-naming alternatives as a coherent choice ('Name the period ONE way: ... or name NO period to use the months selected on the period card'), and by clarifying that every month must have ended. It also tells the agent to pass transaction_id to the assignment tool, which adds meaning beyond the schema. A 4 is appropriate because the description complements rather than merely repeats the schema.

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 states a specific verb ('List'), a precise resource ('settled expense TRANSACTIONS a past period is still missing a supplier invoice for'), and the output shape ('one row per line, each with its current owner SET'). It also explicitly distinguishes itself from the sibling well_list_missing_invoices ('same missing invoices ... but flattened to lines you can assign; there is no per-card grouping and no scope: "card"'), so an agent can tell them 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?

The description gives explicit when-to-use ('who owes the missing invoices?') and names the intended downstream sibling (well_assign_missing_invoice_owners). It also gives clear exclusions: use well_list_missing_invoices for full per-counterparty totals, and it explains when to pass workspace_id (multi-workspace tokens) versus calling directly (single-workspace tokens). This is unusually complete routing guidance.

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?