# Reported issues for Frisian MCP (Django)

Pod holds 19 of 42 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 [Frisian MCP (Django)](/mcp/frisian-mcp-django).

## Most discussed

### Synthetic requests carry no URL resolver context, so URLPath and Namespace versioning silently resolve to the default version

## Summary

The synthetic request frisian-mcp builds carries **no URL resolver context** — no `resolver_match`, and no route kwargs. Two of DRF's four versioning schemes read exactly that context, so on a host using either, the version resolves to the scheme's `default_version` rather than the version the route would have selected.

This affects **discovery and dispatch equally**. It is a pre-existing structural limitation, not a regression.

> ⚠️ **Status: statically derived, not reproduced.** 

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/77) · 2026-08-29 · open · outside contributor · 1 comment

### [Bug]: frisian_mcp_oauth.0003 cannot be applied on MySQL — UniqueConstraint is 3x over the index limit, blocking every MySQL host

## Summary

`frisian_mcp_oauth.0003_oauthauthorizeconsent` cannot be applied on MySQL:

```
MySQLdb.OperationalError: (1071, 'Specified key was too long; max key length is 3072 bytes')
```

**frisian-mcp therefore cannot be installed to completion on any MySQL-backed
Django host.** Found while installing into Open edX (Verawood, MySQL 8.4),
which is blocked outright.

## The cause, measured

```python
migrations.AddConstraint(
    model_name="oauthauthorizeconsent",
    constraint=models.UniqueC

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/72) · 2026-08-27 · open · outside contributor · 2 comments

### [Bug]: Dispatcher description counts the unfiltered route registry — a scoped caller can compute the size of the surface hidden from it

## Summary

Each group dispatcher's `description` in `tools/list` reads:

```
Group dispatcher for N tools across M resources. Use action='help' to discover them.
```

`N`/`M` are computed from the **route registry**. They honour the route's
`deny_list`, and they ignore **both** the route's tier ceiling and the calling
principal's permissions. `action="help"` — which renders the correctly filtered
set — therefore disagrees with the description on every scoped door.

Subtracting one from the othe

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/71) · 2026-08-27 · closed · outside contributor · 1 comment

### [Bug]: Validation errors are unusable by MCP clients — a schema-blind client cannot create a record

A schema-blind MCP client currently has **no legal path to a create**. Three behaviours combine; each is small on its own.

Found during live testing against a deployed host, but every part is general — no host-specific behaviour is involved.

## 1. The corrective detail is written to a field clients discard

`views.py` builds the validation failure as:

```python
_jsonrpc_error(request_id, INVALID_PARAMS, "Invalid arguments", str(exc))
```

`message` is the constant `"Invalid arguments"`. The t

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/65) · 2026-08-23 · closed · outside contributor · 1 comment

### [Feature]: Post-#62 cleanup — write-envelope restoration, true DRF status codes, and a test-infra correction

Small cleanup PR following #62. Deliberately scoped to be a short build, not another long-running effort.

## Scope

Three items. Two are contained code fixes; one is a two-line correction.

**Explicitly out of scope, and moved:**

- **`$defs`/`$ref` schema deduplication** — deferred to the 2.0 line. `$ref` is permitted only from protocol revision 2026-07-28; this server advertises 2025-11-25, so emitting it today would be out of contract on the revision it declares. Adopting 2026-07-28 removes 

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/63) · 2026-08-22 · closed · outside contributor · 3 comments

### [Bug]: OAuth PKCE authorize-path hardening

### Description

With `FRISIAN_MCP_OAUTH_PKCE_AUTO_REGISTER=True`, `_validate_authorize_params` returns valid for any unknown `client_id` as long as `_redirect_uri_is_safe` passes — and that helper only checks the URI scheme (https / loopback / reverse-DNS custom), never the host. An attacker can drive the authorize endpoint with `redirect_uri=https://attacker.example/cb`, receive an authorization code, and (holding their own PKCE verifier) exchange it. PKCE provides no protection because the at

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/30) · 2026-06-28 · closed · outside contributor · 1 comment

### RFC 9728 - OAuth challenge advertises resource_metadata even when PUBLIC_DISCOVERY=False

**Describe the bug**

When `FRISIAN_MCP_OAUTH_PUBLIC_DISCOVERY` is set to `False`, the 401 `WWW-Authenticate` challenge still advertises `resource_metadata="https://<host>/.well-known/oauth-protected-resource"`. The same setting causes the `.well-known/oauth-protected-resource` view to return a JSON 404, so the challenge points at a URL that does not resolve.

This breaks any OAuth client that follows RFC 9728 strictly — it dereferences the `resource_metadata` URL to locate the authorization ser

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/13) · 2026-06-19 · closed · outside contributor · 1 comment

### Update Pipeline

Update pipeline so when PRs are opened the following are ran:
- All tests are ran: uv run pytest tests/ -q
- Ruff lint (style, imports, security): uv run ruff check src/ tests/
- Pylint structural checks: uv run pylint src/frisian_mcp/
- Type checking: uv run mypy src/frisian_mcp/
- Build check (confirm the package builds): uv run python -m build --wheel --no-isolation
- Require CODEOWNER review before merge
- Block merge if any check fails

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/5) · 2026-06-07 · closed · outside contributor · 1 comment

## Most recent

### Add xfail tests characterising version resolution when the synthetic request has no route context

> **Good first issue.** Self-contained, no live host required, no design decisions. It walks you through both halves of how this package talks to a host application, and the deliverable is a small set of tests.

## What this is

#77 describes a limitation that has been **derived from source but never observed**: the synthetic request frisian-mcp builds carries no URL resolver context, so `URLPathVersioning` and `NamespaceVersioning` silently resolve to their `default_version` instead of the vers

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/79) · 2026-08-29 · open · outside contributor · 0 comments

### Version bumps happen in feature PRs, and the rule requiring it contradicts the changelog convention

## Summary

`CONTRIBUTING.md` instructs every contributor to bump the version in the same PR as their change, with a checklist item enforcing it. That rule is self-contradictory, it is the reason the version has drifted, and it puts release numbering in the hands of whoever merges next rather than whoever cuts the release.

## The rule contradicts itself

`CONTRIBUTING.md` currently says:

> Apply the bump that matches the change **in the same PR** — reviewers check for it.

> Any *non-feature* 

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/78) · 2026-08-29 · closed · outside contributor · 0 comments

### FRISIAN_MCP_TRUSTED_PROXY_COUNT is missing from the canonical settings reference

## Summary

`FRISIAN_MCP_TRUSTED_PROXY_COUNT` is **absent from the canonical settings reference** in both documentation versions, while five package modules read it, eight install templates set it, and one of those modules **rejects a bad value at startup**.

An operator reading the reference to find out how to configure proxy trust will not find the setting that does it.

## Measured

```
docs/v1.0/Reference/installation-configuration-reference.md    0 occurrences
docs/v1.1/Reference/installati

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/76) · 2026-08-29 · open · outside contributor · 0 comments

### Synthetic requests discard the caller's origin and the ViewSet's field schema

## Summary

Three defects, in two places, with one root shape: **frisian-mcp builds a stand-in request
and gets it wrong.** In each case the stand-in is hand-assembled from a few attributes
rather than derived from something real, and each one silently degrades output the agent
depends on.

| # | Defect | Where | Status |
|---|---|---|---|
| 1 | `SERVER_NAME` hardcoded to `localhost` | `backends/invocation.py` | ✅ **Fixed** — `9414d13` |
| 2 | Scheme permanently `http` | same lines | ✅ **Fixed**

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/74) · 2026-08-28 · closed · outside contributor · 0 comments

### [Bug]: OAuth tokens are not bound to a route — no RFC 8707 resource indicator or audience validation

## Problem

An OAuth access token is not bound to the route it was issued for, and nothing validates an audience when it is used. A token minted through one route's discovery flow is accepted at every other mounted route, clamped only by tier.

This is measurable today. On a three-route host, a `read_write` principal reaching the admin route's admin-only groups is stopped by the host application's object permissions — never by the gateway. The route boundary is currently enforced by host permiss

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/69) · 2026-08-25 · open · outside contributor · 0 comments

### [Bug]: Redeeming a write continuation token reports total 0 when the created object has a single list-valued field

Redeeming the `continuation_token` from a successful create returns an envelope that says nothing was created.

Observed live:

```json
{"items": [], "page": 1, "page_size": 20, "total": 0, "has_more": false,
 "envelope": { ...the entire created object... },
 "envelope_payload_key": "tags"}
```

The created object is present, under `envelope`. But `items` is empty and `total` is `0`, so **a client reading the payload concludes the create did not happen.** The token redeems correctly; the shape o

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/66) · 2026-08-23 · closed · outside contributor · 0 comments

### [Feature]: Ungrouped auto-discovered writes cannot use the lean envelope — redemption must be decoupled from the write tool's schema

Ungrouped auto-discovered writes lost the lean confirmation envelope in #62, and the obvious fix does not work. This issue records why, so the next attempt does not repeat it.

## The regression

#62 gated the flat write-path mint on `schema_discloses_continuation`, closing a real defect: an auto-discovered write was returning a lean envelope containing a `continuation_token` the published schema did not declare, so a schema-validating client could not legally send it back — and the written obje

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/64) · 2026-08-23 · closed · outside contributor · 0 comments

### Heavy-response hardening: five findings recorded but not fixed in 1.1.0

Follow-up to #56 (heavy-response continuation unredeemable) and #55 (document ingest pipeline).

While fixing #56 we identified five issues that were deliberately **recorded and not fixed**, to keep a release carrying a security fix from widening. Two are already documented in the 1.1.0 changelog under `Known issues`; three have not been surfaced outside the working notes. This issue tracks all five so none of them survives only as a changelog bullet.

**Three of the five need an architecture de

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/61) · 2026-08-08 · closed · outside contributor · 0 comments

### [Bug]: Heavy-response continuation is unredeemable for clients with a non-stable `Mcp-Session-Id`

### Description

The heavy-response negotiation (probe → `continuation_token` → fetch, per ADR-005) binds each continuation to a SEC-3 "owner key" (`_heavy_owner_key`, `views.py`). The owner key is composed of `tool + auth(type:pk) + tier + user + [agent-connection] + [Mcp-Session-Id]` and is compared for **exact equality** when a continuation token is redeemed.

The `Mcp-Session-Id` component is **client-supplied** (the `HTTP_MCP_SESSION_ID` request header). Any MCP client that does not reuse a

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/56) · 2026-07-29 · closed · outside contributor · 0 comments

### [maint] Document Ingestion - general documentation cleanup

# Documentation Ingestion
- Create pipeline that pushes new documents to the server for RAG ingestion
- General cleanup of documentation for consistency

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/53) · 2026-07-25 · closed · outside contributor · 0 comments

### [Feature]:Per-route authentication is not controllable — OAuth walk-up and auth mechanism are global, not per-route

### Problem or motivation

The per-route model (ADR-010) lets each route carry its own **surface**
(`allow_list` / `deny_list`) and its own **tier ceiling** (`highest_tier`). But
**authentication is configured globally**, so you cannot require *different*
authentication on *different* routes.

Two things are global that a per-route deployment often wants to vary per route:

1. **OAuth walk-up eligibility.** `FRISIAN_MCP_OAUTH_PKCE_AUTO_REGISTER` (+ the
   host allowlist) is a single server-wide 

[Read the thread](https://github.com/Frisian-MCP/frisian-mcp/issues/52) · 2026-07-16 · closed · outside contributor · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/Frisian-MCP/frisian-mcp/issues).