# Reported issues for datanika-mcp

Pod holds 18 of 31 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 [datanika-mcp](/mcp/datanika-mcp).

## Most discussed

### [Engineering] P0: mcp 2.x breaks the image — datanika-mcp's unpinned dep clobbers core's mcp<2, /mcp unmounted, all deploys blocked

> **This blocks every production deploy.** Found when a monitoring-only promotion (#601) failed on the box. Nothing about that change was related; any deploy today would have hit this.

## Symptom

`deploy-pointer.yml` → `Deploy the app via blue/green swap` fails its post-swap assertion:

```
15:59:08   public /mcp unauth -> 404 (expect 401; 200 means it fell through to the SPA)
15:59:08 FATAL: /mcp returned 404
```

The app itself is healthy — `/healthz`, `/readyz`, `/` all 200 on the new colou

[Read the thread](https://github.com/datanika-io/datanika-core/issues/602) · 2026-08-29 · closed · 7 comments

### [QA] S1: prod runs 4 Reflex workers with per-process state — 48% of reconnects are served a stale session (root cause of #472/#529)

**S1 — reproduced on production, 2026-08-30, without a browser.**

Production runs the Reflex backend as **4 independent worker processes** with a
**per-process** state store. A client that reconnects lands on a different process
roughly half the time and is served a state that has lost earlier writes. Since
`AuthState.access_token` is a plain server-side state var and `check_auth` does
`if not self.access_token: return rx.redirect("/login")`, a stale read **is** a logout.

This is the cause of 

[Read the thread](https://github.com/datanika-io/datanika-core/issues/646) · 2026-08-30 · closed · 4 comments

### [QA] e2e-staging failure on e8198d1

**Run:** https://github.com/datanika-io/datanika-core/actions/runs/33344167976
**Commit:** `e8198d1`
**Message:** [Engineering] Route every Connection lookup through an org-scoped accessor
**Report:** playwright-report artifact on the run page

Only the GATING tier can open this — informational specs do not fail the job (core#521).

[Read the thread](https://github.com/datanika-io/datanika-core/issues/740) · 2026-08-31 · closed · external user · 2 comments

### [Growth] List datanika-mcp in the MCP registries (discoverability)

Part of the **AI-first agent-surface wave** (coordinator-routed 2026-07-18). Quick win — free discoverability where agents/users browse for tools.

**Gap:** we have a working MCP server but it's unlisted, so nobody browsing MCP directories finds Datanika.

## Scope (registry landscape verified 2026-07-18)
1. **Publish to the official MCP registry first** — `registry.modelcontextprotocol.io` (Anthropic/GitHub/Microsoft/PulseMCP metaregistry). It **feeds** the directories + clients, so do it first

[Read the thread](https://github.com/datanika-io/datanika-core/issues/355) · 2026-07-18 · closed · 2 comments

### [Infra P0] Post-deploy smoke gate — app.datanika.io after ci.yml

## Summary

Add a **post-deploy smoke gate** as a new job in `.github/workflows/ci.yml` that runs after the `Deploy` step on push to `master`, curls a curated list of URLs on `https://app.datanika.io`, asserts `200 + non-empty body` (plus per-URL content-type and body-substring checks), and **fails the workflow on any miss**. Same task in parallel on the landing side: datanika-landing (separate tracking issue, same source-of-truth).

Paired issue: `datanika-landing#<TBD, see cross-ref>` adds the

[Read the thread](https://github.com/datanika-io/datanika-core/issues/125) · 2026-04-14 · closed · 2 comments

### [Product] Chrome autofills the user's Datanika password into connector credential fields — and Google Ads then sends it to Google as a header

Found on **production** while capturing a `02-add-connection` screenshot for the Google Ads guide.
**I caught it because the screenshot I was about to publish contained credentials I had never
typed.** The shot was deleted, not shipped.

## Symptom

Open **Connections → New Connection → type `google_ads`** on `app.datanika.io` in Chrome, with the
Datanika site password saved in the browser (the ordinary state for any returning user). Without
touching either field:

- **`Customer ID`** is pre-fil

[Read the thread](https://github.com/datanika-io/datanika-core/issues/618) · 2026-08-29 · closed · 1 comment

### [Infra] deploy-bluegreen.sh: FATAL paths bypass the ERR rollback trap, leaving prod half-deployed on the new colour

> Found during the #601 promotion, which failed at a post-swap assertion and **left production on the new colour with `/mcp` down**, instead of rolling back. Root cause of the deploy failure itself is #602; this issue is about the deploy script's behaviour when an assertion fails.

## 1. The FATAL paths bypass the rollback trap

`scripts/deploy-bluegreen.sh` arms a rollback:

```bash
trap 'rollback' ERR          # line 107
```

but every assertion failure exits like this:

```bash
[ "$MCP" = 401

[Read the thread](https://github.com/datanika-io/datanika-core/issues/603) · 2026-08-29 · closed · 1 comment

### [QA] MongoDB source cannot authenticate: the connection URI sets no authSource, so users in admin are rejected

## Authenticated MongoDB connections cannot authenticate

`_build_mongodb_source` (`dlt_runner.py:760`) builds:

```python
uri = f"mongodb://{quote_plus(user)}:{quote_plus(password)}@{host}:{port}/{database}"
```

The database in the path is also the **authentication database**. MongoDB users are conventionally created in `admin` — that is what `MONGO_INITDB_ROOT_USERNAME` does in the official image, and what MongoDB Atlas and every managed provider do. So unless the user happens to exist *insid

[Read the thread](https://github.com/datanika-io/datanika-core/issues/550) · 2026-07-22 · closed · 1 comment

## Most recent

### datanika-mcp: the transport's stateless mode and its private-attribute reach-through both need guards

> Filed by Infra while deciding the `mcp` 2.x question left open by #602. **Nothing is broken and
> nothing is exploitable today** — this is about two invariants that currently hold by accident.

## 1. `stateless=True` is load-bearing, and nothing says so

`datanika-mcp/src/datanika_mcp/server.py:492-496`:

```python
manager = StreamableHTTPSessionManager(
    app=mcp._mcp_server,
    stateless=True,
    json_response=True,
)
```

While auditing the pinned `mcp` version I checked our exposure to

[Read the thread](https://github.com/datanika-io/datanika-core/issues/645) · 2026-08-30 · open · 0 comments

### [Engineering] OpenAPI P2 — spec URL-fetch behind the §7 SSRF guards

OpenAPI connector **P2, first slice** (SPEC_OPENAPI_CONNECTOR §9): accept a **spec URL** at `POST /api/v1/connections/openapi/parse`, not just a pasted document.

## Why this slice first

- It is the piece that was **hard-gated on the #338 egress residuals** — the guard's own docstring named "before enabling the OpenAPI-P2 URL-fetch feature" as a deferral condition. #404 closed those, so this is unblocked in a way it wasn't yesterday.
- It is the security-critical half of P2 (§7 is a ship gate, 

[Read the thread](https://github.com/datanika-io/datanika-core/issues/410) · 2026-07-21 · closed · 0 comments

### [Engineering] Hosted /mcp write refusal tells the caller to restart a server they don't run

Found while verifying the hosted flow end-to-end against production for the docs ([landing#261](https://github.com/datanika-io/datanika-landing/issues/261)).

Calling a write tool over the hosted `/mcp` endpoint returns:

```
Error executing tool create_connection: Write access required for 'create_connection'.
Restart the server with --allow-write to enable mutations.
```

The refusal itself is correct — `services/mcp_routes.py` builds every hosted session as `DatanikaSession(client=client, all

[Read the thread](https://github.com/datanika-io/datanika-core/issues/409) · 2026-07-21 · closed · 0 comments

### Add glama.json + datanika-mcp/Dockerfile — unblocks the awesome-mcp-servers backlink (refs #355)

Two small files in `datanika-core`. They are the last gate on the one high-value dofollow backlink we are chasing (`punkpeye/awesome-mcp-servers` PR [#10453](https://github.com/punkpeye/awesome-mcp-servers/pull/10453), 70k+ stars).

## Why this is blocked on core

The awesome-mcp maintainer bot gates the merge on a Glama listing that **passes its checks**, plus a score badge. Status as of 2026-07-21:

- ✅ Glama listing is **live and approved**: https://glama.ai/mcp/servers/datanika-io/datanika-c

[Read the thread](https://github.com/datanika-io/datanika-core/issues/402) · 2026-07-21 · closed · 0 comments

### [Product] Remote-MCP P2 — OAuth consent screen (/oauth/consent)

The last piece of Remote-MCP P2 (#393): the screen a user sees when Claude.ai / ChatGPT / Cursor asks to connect to their Datanika org. SPEC_REMOTE_MCP §10 assigns the consent UI to Product.

**The protocol is already built and merged-pending** — this is a page against a fixed API contract, not a design-it-yourself feature. Nothing about it is blocked.

## The flow it sits in

1. The MCP client sends the user to `GET /oauth/authorize?...` on the backend.
2. The backend validates the request (cli

[Read the thread](https://github.com/datanika-io/datanika-core/issues/394) · 2026-07-21 · closed · 0 comments

### [Engineering] Remote-MCP P2 — OAuth 2.1 authorization server (one-click Add Datanika)

Remote-MCP **P2** per [`SPEC_REMOTE_MCP.md`](../blob/dev/plans) §5.3/§7/§8/§10: Datanika becomes the OAuth 2.1 **Authorization Server** for its own `/mcp` Resource Server, so Claude.ai / ChatGPT / Cursor can add Datanika with one click instead of a pasted API key.

## §11.2 decision gate — own AS vs managed AS

The spec deferred this: *"re-validate own-AS vs a managed AS (e.g. WorkOS) **at the point P2 actually starts**"*. Re-validated now, **verdict unchanged: own AS.**

- A managed AS is a ven

[Read the thread](https://github.com/datanika-io/datanika-core/issues/393) · 2026-07-21 · closed · 0 comments

### [Engineering] Settle the MCP registry name (io.datanika/datanika-mcp) + add the mcp-name README marker

Unblocks the official-registry publish (refs #355).

Growth's DNS auth for the `io.datanika` namespace is **done** (apex TXT on datanika.io, key in `secrets/mcp-registry-dns.env`), but `mcp-publisher publish` 400s: the registry requires the string `mcp-name: io.datanika/datanika-mcp` in the **published PyPI README** to prove package ownership, and the committed `datanika-mcp/server.json` still declares the old GitHub-namespace name `io.github.datanika-io/datanika-mcp` (that route was abandoned —

[Read the thread](https://github.com/datanika-io/datanika-core/issues/391) · 2026-07-21 · closed · 0 comments

### Remote MCP: every hosted tool call times out (30s) — blocking httpx.Client self-call deadlocks the event loop

## Summary

The hosted remote-MCP endpoint (`https://app.datanika.io/mcp`) now routes correctly to the backend (Infra fixed the Apache proxy, 2026-07-21), and the **MCP protocol layer works** — but **every tool call fails with a 30s timeout**, so Remote MCP P1 is functionally unusable in prod.

```
POST /mcp  tools/call {"name":"list_connections"}  -> 200
{"jsonrpc":"2.0","id":3,"result":{"content":[{"type":"text",
 "text":"Error executing tool list_connections: timed out"}],"isError":true}}
```

[Read the thread](https://github.com/datanika-io/datanika-core/issues/388) · 2026-07-21 · closed · 0 comments

### Remote-MCP P1 (step 2): mount /mcp Streamable-HTTP + bearer=API-key verifier (read-only)

Second half of Remote-MCP **P1** (#363), building on the de-globalized tool surface (#369).

Mount a **Streamable-HTTP** MCP endpoint at `/mcp` (**stateless-JSON** per SPEC_REMOTE_MCP §11.1) on the existing Starlette backend (`app._api.routes`), with the session manager's lifespan run via `rx.App.register_lifespan_task`. A thin **bearer-token ASGI middleware** binds a **per-request, read-only** `DatanikaSession(DatanikaClient("127.0.0.1:8000", key))` via the step-1 contextvar — so org isolation 

[Read the thread](https://github.com/datanika-io/datanika-core/issues/370) · 2026-07-20 · closed · 0 comments

### [Engineering] Remote MCP P1 — Streamable-HTTP /mcp, read-only, bearer=API key

Implementation of **P1** from the signed-off [`SPEC_REMOTE_MCP.md`](../blob/dev/plans/engineering/SPEC_REMOTE_MCP.md) (CEO sign-off 2026-07-19; all 5 §11 questions resolved). Flagship: one tool surface, two transports — remote Streamable-HTTP MCP at `app.datanika.io/mcp`, no local install.

**P1 deliberately ships the transport without the OAuth build** (bearer = an existing Datanika API key). OAuth 2.1 AS is P2; write tools are P3.

## Scope (P1 — per SPEC §7 / §11)
1. **De-globalize the tool s

[Read the thread](https://github.com/datanika-io/datanika-core/issues/363) · 2026-07-19 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/datanika-io/datanika-core/issues).