well_record_claim
shallowio.github.WellApp-ai/well-mcp · Verify this server
Record a claim: start following a refund the person asked a supplier for, one task per supplier credit note. The task keeps the credit note, the supplier, the amount and the day the refund is expected, shows in the person's task list and turns red when that day passes. It closes by itself when a confirmed payment covers the credit note. It writes only inside Well and sends nothing to anyone. Call it on the workspace that holds the credit notes, with the `credit_note_ids` (one to 10 invoice ids of supplier credit notes) and `expected_by`, the day the refund is expected (YYYY-MM-DD, from today to 180 days ahead). Well copies the amount, the currency and the supplier from each credit note: the call carries none of them. Call it only after the send call for the same credit notes returned `success: true`, or returned an `approval_url` for the person to approve. Never call it for a claim the person declined, for an email shown as text only, for a credit note you could not prove is owed, or on your own guess. Read `claims`, one item per credit note, with `outcome`: - `recorded`: the task is written (`claim`: the task id, the supplier, the amount, the currency, the day the refund is expected, the status). - `already_recorded`: this credit note already has a live claim (`claim`); nothing was written. - `refused`: nothing was written. `reason` says why: `credit_note_not_found` (no such invoice in this workspace), `not_a_credit_note` (the document is not a credit note), `not_a_supplier_credit_note` (the credit note is not proved to be on the company's purchase side: it is a sale, both legs are the company's own, neither is, or the receiver is missing or not proved to be the company), `duplicate` (the credit note is a folded duplicate; claim the document it was folded into), `own_company_unset` (no own company of the workspace is established yet, so the side cannot be proved), `own_set_incomplete` (the workspace's own companies could not all be read, so the side cannot be proved now), `supplier_unknown` (the credit note names no supplier), `amount_unknown` (the credit note has no total), `already_settled` (a confirmed payment already covers it), `expected_by_out_of_range` (the day is before today or more than 180 days ahead). When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.
1 trials · measured 1 day ago
well_record_claim scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against io.github.WellApp-ai/well-mcp, measured 18 Oct 2026 under methodology v0.2.0. Every measured component scored 100.
Component breakdown
| Component | Weight | Value |
|---|---|---|
| Reliability | 35% | not applicable |
| Schema integrity | 25% | 100.0 |
| Failure behaviour | 15% | not applicable |
| Latency | 15% | not applicable |
| Concurrency | 10% | not applicable |
Tool details
- Transport
- remote
- Credential class
- gated
- Input schema
- not declared
- Output schema
- not declared
- Side-effect classification
- unclassified
Score history
| Day | Score | Tier | Methodology |
|---|---|---|---|
| 2026-10-18 | 100.0 | shallow | v0.2.0 |
Probe evidence
| Probe | Outcomes |
|---|---|
| schema_integrity | pass: 1 |
Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.
Embed this score
Available for every tool, scored or not — not a verification perk. Always links back to this page.
[](https://vouch.tools/tools/cfb3a350-6549-458a-ac57-3d9b54084074)