Reported issues for e-arveldaja-mcp

Pod holds 18 of 25 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to e-arveldaja-mcp.

Most discussed

Refactor MCP tool surface around guided workflows

Context

The MCP server currently exposes a broad low-level tool surface. A local scan counted 115 registered tools across setup, CRUD, reference data, imports, reconciliation, reporting, receipt processing, workflow recommendation, and audit operations. The breadth is useful for power users, but it creates selection friction for agent clients and hides the intended safe workflow path.

The goal is to add merged, mode-based guided tools whi

Read the thread · 2026-05-06 · closed · 5 comments

process_receipt_batch bypasses the documented document-flow contract

Problem

The MCP server's own instructions document a strict purchase-invoice flow:

extract_pdf_invoice → validate_invoice_data → resolve_supplier → detect_duplicate_purchase_invoice → suggest_booking → approval checkpoint → create_purchase_invoice_from_pdf (with file_path for auto-upload) → confirm_purchase_invoice

In practice process_receipt_batch:

Does not call detect_duplicate_purchase_invoice per file.
Does not call suggest_booking with the resolved clients_id (falls bac

Read the thread · 2026-04-25 · closed · 3 comments

Add mode-based CAMT, Wise, and receipt wrapper tools

Problem

Import flows expose parse/dry-run/execute phases as separate or boolean-driven tool choices. New wrappers should make workflow phase explicit while preserving old tools.

Scope

Add process_camt053(mode: "parse" | "dry_run" | "execute").
Consider import_wise_statement(mode: "dry_run" | "execute") only if it reduces client confusion; keep import_wise_transactions.
Add `receipt_batch(mode: "scan" | "dry_run" | "crea

Read the thread · 2026-05-06 · closed · 2 comments

Add workflow_action_v1 contract tests for materializing dry runs

Context

Approval cards and next-action selection are central to the UX and safety model. The recent receipt dry-run bug happened because a tool-level dry-run counter was not carried into the accounting inbox workflow summary. Similar drift can happen across CAMT, Wise, receipt batch, transaction classification, and reconciliation flows.

Proposed scope

Add contract tests for workflow_action_v1 across all dry-run workflows that can produce pending materialization.
Cover both clean a

Read the thread · 2026-05-03 · closed · 2 comments

Request: Register in Anthropic MCP Registry for Cowork support

Tsau. Mu kolleeg Claude kirjutab: "I've been using e-arveldaja-mcp with Claude Code and it works great. However, I'd love to use it directly from the Anthropic Cowork desktop app.

Cowork only loads MCP servers that are registered in the Anthropic MCP Registry. MCPs added via claude mcp add (Claude Code CLI) are not picked up by Cowork — only registry-listed ones are available there.

Would you consider submitting e-arveldaja-mcp to the Anthropic MCP Regist

Read the thread · 2026-04-03 · closed · external user · 2 comments

Extract service boundaries and shared record helpers

Problem

Workflow code currently repeats record-inspection helpers (isRecord, numberAt, stringAt, arrayAt, recordAt, stringArrayAt) across several modules. The accounting inbox autopilot was also coupled to MCP tool registration and JSON text responses.

Scope

Stabilize src/tools/accounting-inbox-autopilot-service.ts.
Add or finish focused tests in src/tools/accounting-inbox-autopilot-service.test.ts.
Create `sr

Read the thread · 2026-05-06 · closed · 1 comment

Add merged accounting inbox tool

Problem

prepare_accounting_inbox and run_accounting_inbox_dry_runs have the same inputs and represent two modes of the same workflow. Agent clients have to choose between two names when the safer abstraction is one workflow tool with an explicit mode.

Scope

Add accounting_inbox in src/tools/accounting-inbox.ts.
Support mode: "scan" | "dry_run", defaulting to scan.
Keep prepare_accounting_inbox and run_accounting_inbox_dry_runs as

Read the thread · 2026-05-06 · closed · 1 comment

Clean up CRUD/reference registration and documentation

Problem

src/tools/crud-tools.ts is a large mixed registration module containing entity CRUD and reference-data lookups. The public names are useful, but the internal organization makes further work risky.

Scope

Add a registered-tool snapshot test so refactors do not silently drop public tools.
Extract reference-data registrations into a focused module.
Keep existing CRUD names and schemas intact.
Update README, CHANGELO

Read the thread · 2026-05-06 · closed · 1 comment

Most recent

Unify reconciliation and classification workflow entry points

Problem

The bank workflow has overlapping tools for invoice matching, exact-match confirmation, inter-account transfer cleanup, unmatched classification, and broad unconfirmed transaction analysis. Clients need a clearer recommended path.

Scope

Add reconcile_bank_transactions with explicit modes for suggest, dry-run auto-confirm, execute auto-confirm, and inter-account dry-run.
Evaluate folding `analyze_unconfirmed_t

Read the thread · 2026-05-06 · closed · 1 comment

Merge workflow continuation and review-action planning

Problem

continue_accounting_workflow, resolve_accounting_review_item, and prepare_accounting_review_action are all phases of the same workflow state machine. Keeping them as separate top-level choices makes the client decide too much.

Scope

Extend continue_accounting_workflow with action: "next" | "resolve_review" | "prepare_action".
Reuse existing resolveReviewItemPlan and prepareReviewAction internals.
Keep

Read the thread · 2026-05-06 · closed · 1 comment

Split CRUD tool registration by domain

Context

src/tools/crud-tools.ts registers many unrelated entities in one large module: clients, products, journals, transactions, sale invoices, purchase invoices, and readonly reference lists. The shared patterns are useful, but the file size makes review and targeted changes harder.

Proposed scope

Split CRUD tool registration by domain while preserving public tool names and schemas.
Extract shared guards and registration helpers for list/get/create/update/delete/confirm/invalida

Read the thread · 2026-05-03 · closed · 1 comment

Make workflow prompts use one source of truth

Context

Workflow guidance exists in multiple surfaces: src/prompts.ts, markdown files under workflows/, and command files under .claude/commands/. Tests check some alignment, but edits still require touching several places and can drift from the actual tool contract.

Proposed scope

Define one source of truth for each workflow prompt.
Generate or validate the MCP prompt text, workflow markdown, and command markdown from that source.
Keep approval-first language and `workflow_

Read the thread · 2026-05-03 · closed · 1 comment

Introduce typed test fixtures for accounting workflow tests

Context

Several test files build large API mocks inline and use broad as any casts. That keeps tests flexible, but it also hides drift between mock payloads and real tool expectations. The accounting inbox regression test needed another large inline API mock to reach one workflow branch.

Proposed scope

Add typed fixture builders for common API surfaces: clients, readonly defaults, purchase invoices, transactions, journals, and MCP server registration.
Add workspace/document fixtur

Read the thread · 2026-05-03 · closed · 1 comment

Split receipt inbox batch processing into focused services

Context

src/tools/receipt-inbox.ts is a large module that combines document discovery, OCR/document parsing, invoice extraction, supplier resolution, duplicate detection, transaction matching, booking suggestion, batch summary building, audit metadata, and create-mode execution. This makes small behavior changes risky because preview and execution logic are interleaved.

Proposed scope

Split receipt batch processing into focused services:
- document/file discovery
- extraction an

Read the thread · 2026-05-03 · closed · 1 comment

Refactor accounting inbox autopilot into a service pipeline

Context

The accounting inbox flow still has too much orchestration logic in src/tools/accounting-inbox.ts. The first small extraction moved receipt dry-run preview logic into src/tools/accounting-inbox-autopilot.ts, but the main tool still mixes scanning, recommendation planning, internal tool dispatch, dry-run summarization, pending-materialization gates, and workflow-envelope assembly.

Proposed scope

Extract the autopilot loop behind run_accounting_inbox_dry_runs into a servic

Read the thread · 2026-05-03 · closed · 1 comment

payment_receipt result has no machine-readable referenced_invoice_number

Follow-up from PR #21 review (MEDIUM finding).

Problem

PR #21 introduced the payment_receipt classification to stop double-booking Anthropic / Stripe-style payment confirmations. The note pushed onto notes[] mentions the underlying invoice number when present, but the ReceiptBatchFileResult itself has no typed field for the cross-reference.

A natural follow-up — auto-attach payment receipts to the underlying invoice via upload_invoice_document — will need the cross-reference progra

Read the thread · 2026-04-25 · closed · 1 comment

Self-match guard misses own-company client records that lack a VAT number

Follow-up from PR #21 review.

Problem

resolveSupplierInternal.isSelfClient (introduced in PR #21 / issue #14) checks client.invoice_vat_no === ownVat. If the active company's row in clients has a NULL or stale invoice_vat_no but its code matches the company's actual registry code, a registry-code lookup will still return the active company as a supplier.

Real-world cases where this hits:

A young Estonian OÜ that registers for VAT later — the client record was created before VAT

Read the thread · 2026-04-25 · closed · 1 comment

llm_fallback.recommended is too eager to say 'no' — confidence should reflect plausibility, not just field presence

Problem

For the Anthropic invoice where the supplier was incorrectly resolved to the buyer's own company, the dry run still reported:

llm_fallback.recommended: false
llm_fallback.reason: Deterministic extraction found the minimum fields needed for invoice review.

The criterion is "no missing required fields", which is a presence check, not a plausibility check.

Proposed fix

Replace llm_fallback.recommended: bool with confidence: low | medium | high (keep recommended as a d

Read the thread · 2026-04-25 · closed · 1 comment

The remaining reports are on the project's issue tracker.