{ "mcpServers": { "qontoctl": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}.cursor/mcp.jsonServidor MCP
- Transporte
- stdio
- Status
- Local
Potencialize seu agente
O comando do próprio publicador. Não é um endpoint do PlugMCP.
Host a copy with our keys and logs.
npx -y [email protected]O Claude Code não tem link de instalação para um comando local. Copie o comando abaixo e execute-o em um terminal.
claude mcp add qontoctl -- npx -y qontoctl@3.0.1Execute em um terminal.
{ "mcpServers": { "qontoctl": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}claude_desktop_config.json
URL remota ou um comando na sua máquina? Como as duas instalações diferem
Rodar no PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
AbrirCLI and MCP server for the Qonto banking API.
This project is brought to you by Alexey Pelykh.
Unofficial project. QontoCtl is independent and not affiliated with, endorsed by, or supported by Qonto. See the Disclaimer.
QontoCtl lets AI assistants (Claude, etc.) interact with Qonto through the Model Context Protocol. It can:
QontoCtl is an independent, unofficial project — not affiliated with or endorsed by Qonto.
Qonto ships its own official MCP server — hosted, free on every plan, and installable in a tap from Claude, ChatGPT, Cursor, and more. If you want to talk to your finances — "show my balances", "chart last month's spending", "draft an invoice" — it's an excellent, well-made option.
QontoCtl is built for a different job: automating Qonto, not just chatting with it.
The official MCP is a hosted assistant you log into as a user. QontoCtl is a local, open-source toolkit — a CLI, an MCP server, and a library — that runs on your own machine with your own credentials, including as a headless service account.
Comparison based on Qonto's public MCP documentation as of July 2026.
* Transfers to untrusted payees still require your Strong Customer Authentication approval, as they must. QontoCtl handles the SCA continuation so scripted flows — to trusted beneficiaries and between your own accounts — complete without a human at the terminal.
QontoCtl also supports multiple Qonto organizations from one setup via named profiles — handy for accountants, holding companies, and anyone running the books for several entities.
The official MCP talks to Qonto. QontoCtl automates it. Many people will use both — the official MCP in a chat window, QontoCtl in a pipeline.
npm install -g qontoctl
Or run directly with npx:
npx qontoctl --help
Or install via Homebrew:
brew install qontoctl/tap/qontoctl
# 1. Install
npm install -g qontoctl
# 2. Create a profile with your Qonto API credentials
qontoctl profile add mycompany
# 3. Test the connection
qontoctl profile test --profile mycompany
# 4. List your accounts
qontoctl account list --profile mycompany
QontoCtl implements the Model Context Protocol (MCP), letting AI assistants interact with your Qonto account through natural language.
Add to your Claude Desktop configuration (claude_desktop_config.json):
{
"mcpServers": {
"qontoctl": {
"command": "npx",
"args": ["qontoctl", "mcp"]
}
}
}
claude mcp add qontoctl -- npx qontoctl mcp
Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"qontoctl": {
"command": "npx",
"args": ["qontoctl", "mcp"]
}
}
}
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"qontoctl": {
"command": "npx",
"args": ["qontoctl", "mcp"]
}
}
}
The MCP server has no CLI flags. To load credentials from a config file other than ~/.qontoctl.yaml, set QONTOCTL_CONFIG_FILE in the host's env block:
{
"mcpServers": {
"qontoctl": {
"command": "npx",
"args": ["qontoctl", "mcp"],
"env": {
"QONTOCTL_CONFIG_FILE": "/abs/path/to/qontoctl.yaml",
},
},
},
}
The path is captured at server startup. See docs/configuration.md for the full resolution chain.
Once configured, you can ask your AI assistant things like:
Some Qonto write operations — creating a transfer, modifying a card, approving a request — require Strong Customer Authentication (SCA): the user has to approve the request in the Qonto mobile app before it executes. QontoCtl wraps every SCA-gated MCP write tool with a continuation flow so the LLM client never has to reimplement polling.
When an SCA-gated tool (e.g. transfer_create, card_create, beneficiary_trust, request_approve) hits a 428 SCA challenge, the wrapper polls the SCA session inline. If the user approves within the polling window, the tool returns the operation's success result transparently — the LLM never sees the SCA round-trip. If polling times out (or polling is disabled), the tool returns a structured SCA-pending response carrying the session token and instructions to continue.
Every wrapped tool exposes two optional input fields for this flow:
wait — maximum seconds to poll inline before falling back to the pending response.sca_session_token — bind a previously approved SCA challenge to a retry.wait knobThe 120 upper bound is the hard ceiling enforced via Zod at the input boundary. The practical ceiling is your MCP host's request timeout — Claude Desktop hardcodes ≈ 60 s and Cursor's effective limit is ≈ 30 s, so values above those will surface as host-side timeouts before the wrapper resolves. Use a small wait (e.g. 5-10) when the LLM expects the user to be present and willing to approve immediately. Use wait: false (or wait: 0) for pure two-step flows where the LLM and the user converse out-of-band between the SCA challenge and the retry.
When polling does not resolve, the SCA-pending response carries:
"SCA required. The user must approve this operation on their Qonto mobile app."Session token: <token> line (token validity: 15 minutes from issuance).The LLM (or the user) can then:
sca_session_show tool, passing the captured token. It returns waiting, allow, or deny.allow, passing the same parameters plus sca_session_token: "<token>". The wrapper invokes the operation exactly once with the token bound — no second poll happens.PSD2 dynamic linking. The SCA session token is bound to the original request parameters (amount, payee). Reusing a token against a different operation is rejected by Qonto. Reissue an SCA challenge by calling the original tool again whenever the parameters need to change.
sca_session_token)When sca_session_token is set on a wrapped write tool, the wrapper:
X-Qonto-Sca-Session-Token header.This is the path used by step (2) of the two-step fallback. It is also useful when the LLM client implements its own polling cadence and only needs the wrapper to retry with an already-captured approval.
Sandbox accounts cannot enroll a real paired device, so SCA challenges in sandbox use a mock flow. After receiving a pending response, simulate the user's decision with the sca_session_mock_decision tool (sandbox-only — refuses to run when no staging token is configured). See docs/sandbox-testing.md for the full sandbox setup.
Earlier QontoCtl builds (pre-@qontoctl/mcp SCA continuation) returned a free-form text response on 428 with no continuation hooks. Callers parsing that response should adopt the structured flow:
The pending response's textual format is stable, so callers that need to extract the token programmatically can match against the Session token: line — but using sca_session_show directly avoids relying on the response prose.
First command to try when something doesn't work:
qontoctl diagnose— a read-only healthcheck across config, credentials, scopes, organization metadata, and host routing.
QontoCtl supports two authentication methods:
All configuration files use the same YAML format:
# API Key authentication
api-key:
organization-slug: acme-corp-4821
secret-key: your-secret-key
# OAuth 2.0 authentication (see docs/oauth-setup.md)
oauth:
client-id: your-client-id
client-secret: your-client-secret
The CLI resolves the config file in this order (highest priority first):
--config <path> flagQONTOCTL_CONFIG_FILE env var~/.qontoctl/{name}.yaml (when --profile <name> is given)~/.qontoctl.yaml (home default)When --config is supplied alongside QONTOCTL_CONFIG_FILE or --profile and the resolved paths disagree, --config wins and a warning is emitted on stderr so the override is visible.
No current-directory discovery. The CLI does not scan the working directory for
.qontoctl.yaml. For repo-local config, use adirenvshim that exportsQONTOCTL_CONFIG_FILE="$PWD/.qontoctl.yaml", or pass--config ./.qontoctl.yamlexplicitly per invocation.
Per-field overrides apply on top of the loaded file:
--profile: QONTOCTL_* env vars override file values--profile acme: QONTOCTL_ACME_* env vars override file valuesFor the full reference (precedence rules per entry point, profile semantics, migration from CWD discovery), see docs/configuration.md.
Environment variables override file values. They carry inputs (static configuration) the tool reads but never writes back; runtime-mutable state (refresh tokens, token expiry, granted scopes) lives in the file only. See the note on QONTOCTL_ACCESS_TOKEN below.
Without --profile:
With --profile <name>, prefix becomes QONTOCTL_{NAME}_ (uppercased, hyphens replaced with underscores). For example, --profile acme reads QONTOCTL_ACME_ORGANIZATION_SLUG.
QONTOCTL_ACCESS_TOKENsemantics: when set, the env-supplied bearer is used for the current invocation only. Proactive token refresh is not attempted, and refreshed tokens are not persisted to disk (mirrorsAWS_SESSION_TOKEN). If the token has expired the API surfaces a401; re-issue the token externally.
QONTOCTL_REFRESH_TOKENis intentionally not supported. Refresh tokens are runtime-mutable state — every refresh produces a new value the tool must write back somewhere — and env vars carry inputs, not state. Use file-based credentials (~/.qontoctl.yamlor a profile) for OAuth flows that need refresh, or stick with API-key env vars in CI.
The --verbose and --debug flags enable wire-level logging to stderr:
qontoctl --verbose transaction list # request/response summaries
qontoctl --debug transaction list # full headers and response bodies
Security note:
--debuglogs full API response bodies. Known sensitive fields (IBAN, BIC, balance) are automatically redacted, but responses may still contain other financial data. Do not use--debugin shared environments or pipe debug output to files accessible by others.
qontoctl is an independent project not affiliated with, endorsed by, or officially connected to Qonto. It runs on your own machine with your own credentials.
"Qonto" and the Qonto logo are trademarks of Olinda SAS (the company operating Qonto); qontoctl uses the name only to describe the service it interoperates with.
@qontoctl/core as a library (importing it into your code) means your combined
work is covered by AGPL-3.0. If you distribute that combined work, you must make its
source available under AGPL-compatible terms.{ "mcpServers": { "qontoctl": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}Ferramentas
Ainda não há lista de ferramentas. Servidores remotos recebem uma após a primeira verificação de saúde.
Perguntas frequentes
Copie nesta página a configuração stdio para Cursor, Claude Desktop, Claude Code ou VS Code. Ela usa a instalação do publicador, não um proxy do PlugMCP.
Este registro não lista nenhuma variável de ambiente obrigatória.
Qontoctl roda localmente via stdio.
Última verificação: 2026-10-28. The complete CLI & MCP for Qonto