Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/frisian-mcp-django/issues.md or /mcp/frisian-mcp-django/issues.json, or Pod over MCP.

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).

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 · 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

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 · 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:

Read the thread · 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 · 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 · 2026-06-19 · closed · outside contributor · 1 comment

Update Pipeline

Update pipeline so when PRs are opened the following are ran:

Read the thread · 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 · 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 · 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 · 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 · 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 · 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 · 2026-07-29 · closed · outside contributor · 0 comments

[maint] Document Ingestion - general documentation cleanup

Documentation Ingestion

Read the thread · 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 · 2026-07-16 · closed · outside contributor · 0 comments

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