well_enqueue_invoice_fetch

io.github.WellApp-ai/well-mcp · Verify this server

Queue invoice collection for named counterparties. This creates one durable backlog task per counterparty. The browser agent (a provider with a blueprint) or the manual-upload route picks up each task later. Call this tool only after the user explicitly confirms the launch. Never call it on your own initiative. Get counterparty_company_ids from well_list_missing_invoices. This tool takes no period argument: a collection task belongs to a counterparty, not a month. A repeat call for a counterparty that already has a non-terminal task reuses that task (already_active: true) instead of creating a second one. provider.has_blueprint on an enqueued row states which counterparties a browser agent will visit, and which fall back to manual upload. Creating the tasks launches nothing in the browser. Inside Well the tasks page and the chat card start and track them. From outside Well, hand the user the collect_url from well_preview_invoice_fetch to start the runs. That link never covers every enqueued counterparty. One link names at most 25 portals, so a counterparty past that ceiling appears in well_preview_invoice_fetch's collect_url_omits instead of on the link. A counterparty with provider: null has no portal at all and is routed to manual upload. A counterparty with an address the link cannot carry appears in collect_url_unaddressable. Never tell the user the link covers a counterparty it does not name. Use well_preview_invoice_fetch first to see what a fetch would cover — it is read-only and launches nothing. Use well_enqueue_close_invoice_fetch instead of this tool when you are inside a close run: it is the same action, scoped to that run's flow_run_id. Use this tool outside a close run. Report the counts back to the user: how many tasks were enqueued, how many of those were already active, and how many counterparties were skipped, with each skip's reason.