Feature: MCP server exposing REST API with identical authz (incl. MyOpenCRE)

Issue

What is the issue?

Add an MCP (Model Context Protocol) server for OpenCRE that exposes the same capabilities as the existing REST API (/rest/v1/..., documented in docs/api/openapi.yaml), with identical authentication and authorisation requirements.

Agents and IDEs should be able to call OpenCRE through MCP the same way clients call REST today — including authenticated surfaces such as MyOpenCRE (GET/PUT /rest/v1/user/resources), chat completion (POST /rest/v1/completion), and any other @login_required / feature-flagged routes — without a weaker or parallel auth model.

Expected Behaviour

1. Capability parity

   • MCP tools (and resources/prompts where appropriate) map 1:1 (or via a thin, documented mapping) to OpenAPI operations under /rest/v1.
   • Public endpoints remain callable without login (same as REST).
   • Protected endpoints require the same login / feature gates as REST, e.g.:
     • MyOpenCRE: CRE_ENABLE_LOGIN + CRE_ENABLE_MYOPENCRE + authenticated session (login_required) for /rest/v1/user/resources
     • Chat: login_required on /rest/v1/completion
     • Admin import routes: same login_required (and any admin checks) as today
   • Unauthenticated or unauthorized MCP calls fail with the same effective outcomes as REST (401 / feature-disabled defaults), not silent empty success unless REST already does that (see feature_enabled_or_default behaviour on MyOpenCRE).

2. Authn/authz

   • Reuse the existing OAuth/session model (or an explicitly designed, equivalent token flow that maps to the same session/user identity).
   • No separate “MCP bypass” or shared static secret that grants MyOpenCRE / chat / admin powers.
   • Document how a Cursor/Claude/other MCP client obtains and supplies credentials for local and for hosted (opencre.org) use.

3. Delivery

   • Runnable locally and (if in scope) against production/staging OpenCRE.
   • Documented install/config for at least one common MCP client (e.g. Cursor).
   • Tests covering: public tool, auth-required tool denied without credentials, auth-required tool succeeds with credentials, MyOpenCRE feature-flag off behaviour matches REST.

Actual Behaviour

There is no OpenCRE MCP server; agents must invent ad-hoc HTTP calls and cannot reliably share REST authz semantics (especially for MyOpenCRE and other login-gated routes).

Steps to reproduce

N/A (feature request).

---

Success criteria

• MCP server implements tools covering OpenAPI /rest/v1 operations (or an agreed phased subset with a tracked gap list ending in full parity).
• Authn/authz for each tool matches the corresponding REST route (login_required, feature flags, admin rules).
• MyOpenCRE user/resources GET/PUT work over MCP only when REST would allow them.
• Docs: client setup, auth flow, tool ↔ REST mapping table.
• Automated tests for public vs authenticated vs feature-gated paths.
• make lint / make mypy / make test (and any new MCP-specific checks) green.

Context

• REST surface / contract: docs/api/openapi.yaml, application/web/web_main.py
• Auth helpers: login_required, feature_enabled_or_default, is_myopencre_enabled / is_login_enabled
• Related auth cleanup tickets: #963 (OAuth route migration), #966 (auth-wrap CSV import)
• Spec: Model Context Protocol

Design questions (to resolve in planning)

1. Transport: local stdio MCP proxy to REST vs remote HTTP MCP hosted with the app?
2. Auth UX: browser OAuth + cookie/session forwarding vs device-code / PAT / API token bound to the same user record?
3. Phasing: ship public read tools first, then MyOpenCRE + completion, then admin — or full parity in one release?
4. Implementation home: in-repo Python package vs separate npm/Python MCP package that calls REST?

Constraints

• Must not weaken REST security for MCP convenience.
• Prefer reusing OpenAPI as the source of truth for tool schemas rather than hand-maintaining a divergent surface.
• No production DB destructive ops; MCP must not expose privileged internal scripts beyond what REST already exposes.
• Mocks: not for authz tests — exercise real Flask auth gates (or equivalent integration) where practical.

Out of scope (unless explicitly pulled in)

• Changing REST auth model itself (covered by #963 / #966).
• New product APIs that do not exist on REST.
• Replacing the web UI with MCP.