# Reported issues for qontoctl

Pod holds 19 of 137 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 [qontoctl](/mcp/qontoctl).

## Most discussed

### Invalid API response from /v2/clients

### Operating System

Windows

### Node.js Version

v24.15.0

### Steps to Reproduce

### Issue 1: `client_list` – `name` field returns `undefined`

1. Configure qontoctl with a Qonto account that has individual clients (with `first_name` / `last_name` instead of `name`)
2. Run `qontoctl client list` or call the `client_list` MCP tool

### Issue 2: `quote_list` – `discount.type` returns unexpected enum value

**Steps to Reproduce:**
1. Have quotes with discounts in your Qonto account
2. Run `qon

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/496) · 2026-05-07 · closed · external user · 5 comments

### (bug) E2E: cards/insurance/iban-certificate return HTTP 400 — investigation

## Summary

A handful of E2E tests fail with HTTP 400 errors that need individual investigation: cards listing (every test), insurance create, account iban-certificate (CLI + MCP), plus 1 HTTP 422 in transactions.

## Failing tests

### Cards (HTTP 400 on every `card list` test)
- `packages/e2e/src/cards/cli.e2e.test.ts > card list > lists cards with default output`
- `packages/e2e/src/cards/cli.e2e.test.ts > card list > lists cards as JSON`
- `packages/e2e/src/cards/cli.e2e.test.ts > card list 

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/489) · 2026-05-07 · closed · 3 comments

### (epic) E2E coverage for every Qonto API qontoctl uses

## Context

Surfaced from #438 (PSD2 SCA verification spike) which discovered 6 latent bugs (#444 #445 #446 #447 #448 + the consolidated #444 covering both trust/untrust) — all of them invisible to our existing test gates because the affected paths had no E2E coverage. The pattern: when an API is "covered" only by mocked unit tests, qontoctl's assumptions and Qonto's actual contract drift apart silently.

A subprocess-driven audit (read-only, captured in this PR's working tree as part of #438's 

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/449) · 2026-05-05 · open · 3 comments

### (fix) Card.card_level + status response enums too narrow — new Qonto values break card list/show (follow-up to #672)

## Problem

`CardSchema` (`packages/core/src/cards/schemas.ts`) validates several response fields as closed `z.enum([...])`. When the Qonto API returns a value **outside** the hardcoded set, the **entire** `CardSchema.parse()` throws — so `qontoctl card list` / `card show` / `card create` (and the MCP `card_*` tools) fail hard on an otherwise-valid card. This is the exact failure class #672 just fixed for `card_type`.

Two response enums model **open sets** Qonto actively grows and are still nar

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/678) · 2026-07-15 · closed · 2 comments

### MCP diagnose ignores server --profile and misreports missing credentials

### Operating System

macOS

### Node.js Version

v26.0.0 (MCP server runs qontoctl **2.0.5** via `npx qontoctl@latest`; behavior also inspected against the 2.0.4 Homebrew build — the relevant auth/config/MCP code is identical in both)

### Steps to Reproduce

1. Configure an MCP client to launch the server with a profile, and ensure **no** top-level `~/.qontoctl.yaml` exists (credentials live in a profile at `~/.qontoctl/<profile>.yaml`):

   ```json
   {
     "mcpServers": {
       "qontoctl":

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/658) · 2026-06-14 · closed · 2 comments

### Fix parallel client_invoice_send HTTP 422/EOF + breaking-change migration guide

# Fix parallel `client_invoice_send` HTTP 422/EOF (same defect class as #636) + breaking-change migration guide

## Background

**Parallel bug discovered during the #636 investigation; not previously reported.**

The MCP tool at `packages/mcp/src/tools/client-invoice.ts:269-278` and the CLI command for `client-invoice send` both transitively call `sendClientInvoice(client, id)` at `packages/core/src/client-invoices/service.ts:135-137`, which calls `client.requestVoid("POST", "/v2/client_invoices

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/639) · 2026-05-22 · closed · 2 comments

### Fix quote_send HTTP 422/EOF by sending required send_to + email_title payload

# Fix `quote_send` HTTP 422/EOF by sending required `send_to` + `email_title` payload

## Background

Addresses #636 arm 1 (`quote_send` fails with HTTP 422 `invalid_body: EOF`).

The MCP tool at `packages/mcp/src/tools/quote.ts:229-250` and CLI command at `packages/cli/src/commands/quote.ts:179-193` call `client.requestVoid("POST", "/v2/quotes/${id}/send")` with no body. The Qonto API at `POST /v2/quotes/{id}/send` requires a JSON body with `send_to` (array of recipient emails) and `email_title

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/638) · 2026-05-22 · closed · 2 comments

### Introduce packages/core/src/quotes/service.ts + typed send payload schemas (foundation)

# Introduce `packages/core/src/quotes/service.ts` + typed send payload schemas (foundation)

## Background

Two send endpoints in this repo currently fail with HTTP 422 `invalid_body: EOF`:

1. `quote_send` (MCP) / `qontoctl quote send` (CLI) — reported as #636 arm 1.
2. `client_invoice_send` (MCP) / `qontoctl client-invoice send` (CLI) — parallel bug discovered during the #636 investigation; not previously reported.

Root cause for both: implementations call `client.requestVoid("POST", ".../sen

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/637) · 2026-05-22 · closed · 2 comments

## Most recent

### Evaluate independent per-package versioning (Changesets) to decouple @qontoctl/mcp majors from the umbrella

## Context

The **v3.0.0** release (#663) surfaced a versioning-model question worth tracking. QontoCtl is **lockstep-versioned**: a single git tag stamps all four published packages (`@qontoctl/core`, `@qontoctl/cli`, `@qontoctl/mcp`, `qontoctl`) the same version, and the umbrella version = `max(per-package impact)` per [`docs/release-runbook.md`](docs/release-runbook.md) § Versioning.

#663 broke only the **`@qontoctl/mcp` programmatic API** (`createServer` / `runStdioServer` signature) — the 

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/665) · 2026-06-16 · open · 0 comments

### Consolidate MCP config resolution so `diagnose` consumes a pre-resolved selection (structural fix for the #658→#661 divergence bug-class)

## Context

The MCP `diagnose` tool re-resolves config **independently** of the data tools: it calls `resolveConfig(resolveOptions ?? buildMcpResolveOptions())` (via `resolveProfileConfig` in `packages/mcp/src/tools/diagnose.ts`), rather than consuming an already-resolved config selection that the data-tool `getClient` also uses. As a result, **every** server-construction site must *remember* to thread `resolveOptions` into `diagnose` to keep it in lockstep with `getClient`.

This is the structu

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/663) · 2026-06-15 · closed · 1 comment

### Standalone `qontoctl-mcp` diagnose isn't startup-frozen in lockstep with the data tools (sibling of #658)

## Context

Surfaced while rescanning the **#658** bug class — the MCP `diagnose` tool resolving config through a *different path* than its sibling data tools. PR #659 closed #658 for the **umbrella** `qontoctl mcp` entry point by threading the launch's `resolveOptions` (`{ path?, profile? }`) into `registerDiagnoseTools`, putting `diagnose` in lockstep with the data-tool `getClient`.

This is the **standalone-entry-point sibling**: the same "diagnose resolves differently than the data tools" sh

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/661) · 2026-06-15 · closed · 1 comment

### (feat) qontoctl diagnose — user-facing healthcheck CLI command + MCP tool

## Context

qontoctl users hitting `401/403/422` have no fast way to learn **why** — `auth status` covers OAuth state alone, but nothing surfaces org-level config (scopes, feature flags, plan limits, sandbox routing) in one place. Result: source-diving, guesswork, support friction. `diagnose` is the first command to run when something doesn't work.

This is the implementation of the design at [docs/designs/qontoctl-diagnose.md](docs/designs/qontoctl-diagnose.md). PRD: [docs/prds/qontoctl-diagnos

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/578) · 2026-05-12 · closed · 1 comment

### (test) E2E for card SCA write paths blocked by sandbox plan (follow-up to #556)

## Context

Follow-up to #556. E2E coverage for 3 of 8 `card` SCA-gated write endpoints is deferred because the Qonto sandbox returns non-200 responses despite all `card.write` scopes being granted on the OAuth token.

Empirical probe 2026-05-12 against sandbox org \`0909-future-club-2702\` via both CLI and MCP paths:

| Endpoint | Sandbox Result |
|---|---|
| \`POST /v2/cards/bulk\` (CLI: \`card bulk-create\`, MCP: \`card_bulk_create\`) | 404 not_found |
| \`PUT /v2/cards/{id}/options\` (CLI: \

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/570) · 2026-05-12 · open · 2 comments

### (test) E2E for getTransferProof — deferred from #554 (sandbox blocker)

## Context

Deferred from #554 (Category A Group 6 sub-issue of #458).

Sandbox blocker: Qonto sandbox `0909-future-club-2702` returns `404 not_found` from `GET /v2/sepa/transfers/{id}/proof` for ALL 10 most-recent `status: settled` transfers (empirical probe 2026-05-12).

## Probe evidence

```
=== 019e1c5f-abd6-7c3a-bf7f-0f0775115243 ===
Qonto API error (HTTP 404):
  - not_found: Not found
=== 019e1c5f-99b7-7dbf-83c5-2582939474f2 ===
Qonto API error (HTTP 404):
  - not_found: Not found
=== 019

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/565) · 2026-05-12 · closed · 1 comment

### (test) E2E for card SCA write paths (#458 sub H)

## Context

Sub-item of #458 — Category A Group 6 (SCA-gated write paths). See [audit-refresh comment](https://github.com/alexey-pelykh/qontoctl/issues/458#issuecomment-4430156150).

Existing coverage in `packages/e2e/src/cards/` is list/show/iframe-url (api-key gate). Both CLI (`card/*.ts`) and MCP (`card.ts` — 12 wraps for 11 write tools, dense coverage) already wrap correctly with SCA — no code fix needed.

3 destructive endpoints are `ACCEPTED_GAP` (terminal state — would consume the test ca

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/556) · 2026-05-12 · closed · 1 comment

### (test) E2E for request SCA write paths (#458 sub G)

## Context

Sub-item of #458 — Category A Group 6 (SCA-gated write paths). See [audit-refresh comment](https://github.com/alexey-pelykh/qontoctl/issues/458#issuecomment-4430156150).

No `packages/e2e/src/requests/` directory yet. **Capability-gated**: gracefully skips with a 403 fallback when the sandbox plan lacks the `request` feature. Both CLI (`request/{approve,decline,create-flash-card,create-multi-transfer,create-virtual-card}.ts`) and MCP (`request.ts`) already wrap correctly with SCA — n

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/555) · 2026-05-12 · closed · 1 comment

### (test) E2E for transfer SCA write paths + audit AC #4 (#458 sub F)

## Context

Sub-item of #458 — Category A Group 6 (SCA-gated write paths). See [audit-refresh comment](https://github.com/alexey-pelykh/qontoctl/issues/458#issuecomment-4430156150).

Existing coverage in `packages/e2e/src/transfers/` is `list`/`show` only. `createTransfer` is **already exercised end-to-end** by `packages/e2e/src/sca-continuation/{cli,mcp}.e2e.test.ts` — three OAuth+sandbox+SCA tests (wait=false / wait=5 / wait=10 inline-poll). No duplication needed.

**Audit AC #4 (Notable Findi

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/554) · 2026-05-12 · closed · 1 comment

### (test) E2E for bank-account SCA write paths (#458 sub E)

## Context

Sub-item of #458 — Category A Group 6 (SCA-gated write paths). See [audit-refresh comment](https://github.com/alexey-pelykh/qontoctl/issues/458#issuecomment-4430156150).

The audit refresh surfaced a real code defect: **MCP `accounts.ts` has 0 `executeWithMcpSca` wraps** even though the CLI counterpart `account.ts` wraps all 3 write subcommands. If SCA triggers on these MCP calls, the tool will fail with an unhandled 428.

**SCOPE NARROWED 2026-05-12**: only the MCP wrap fix is in sc

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/553) · 2026-05-12 · closed · 1 comment

### (test) E2E for beneficiary SCA write paths (#458 sub C)

## Context

Sub-item of #458 — Category A Group 6 (SCA-gated write paths). See [audit-refresh comment](https://github.com/alexey-pelykh/qontoctl/issues/458#issuecomment-4430156150).

Existing beneficiary read coverage lives in `packages/e2e/src/commands/beneficiary.e2e.test.ts` (api-key gate, `list`/`show` only) — no separate `beneficiaries/` directory yet. CLI `beneficiary/add.ts` and `beneficiary/update.ts` wrap with SCA; MCP `beneficiary.ts` wraps all 4 write tools — no code fix needed.

Note

[Read the thread](https://github.com/alexey-pelykh/qontoctl/issues/551) · 2026-05-12 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/alexey-pelykh/qontoctl/issues).