Make Gitea MCP profile activation and runtime identity state explicit #131

New Issue

2026-07-04T00:04:12-05:00

jcwalker3 commented

2026-07-04 00:04:12 -05:00

Problem

Different LLM hosts are behaving differently when asked to use Gitea MCP author/reviewer profiles. Some sessions have separate author/reviewer MCP namespaces, while others expose only one connected MCP server launched as prgs-author. Prompts currently say "switch to prgs-reviewer," but the tool does not clearly tell the LLM whether profile switching is supported in the active runtime, whether the current profile is fixed at server launch, or whether a separate reviewer namespace is required.

This causes repeated failed attempts and confusion (observed most recently in the PR #130 review flow, where reviewer actions had to fall back to a CLI path because the connected server was launched as prgs-author). The tool should make runtime identity/profile state explicit and provide deterministic next steps.

Requirements

1. Read-only runtime context tool

Proposed name: gitea_get_runtime_context

It must return:

active profile name
authenticated username, if resolved
remote
config model/version (v1 / v2-environments / v2-contexts)
profile source (env var, config file profile, default)
allowed operations
forbidden operations
whether runtime profile switching is supported
whether the active server is static-profile or dynamic-profile
whether review/merge is currently allowed
exact reasons review/merge is not allowed
safe next action when identity/profile is wrong

2. Safe profile listing tool

Proposed name: gitea_list_profiles

It must return redacted profile metadata:

profile names
role kind (author / reviewer / operator / limited)
allowed operation families
forbidden operation families
identity status if safely resolvable
enabled/disabled state where the config model has it
no tokens
no keychain IDs
no raw service URLs unless the reveal opt-in (GITEA_MCP_REVEAL_ENDPOINTS=1) is enabled

It must clearly distinguish "profile exists in config" from "profile is active in this connected MCP server."

3. Decide and document the official profile activation model

Preferred safe model — dual MCP namespaces for high-risk actions:

gitea-author
gitea-reviewer
review/merge uses the reviewer namespace/session only.

Optional dynamic model:

add gitea_activate_profile only if runtime switching is explicitly enabled in config
it must be audited
it must return before/after identity proof
it must require fresh whoami / profile verification after switching
it must not weaken self-review or self-merge gates

4. Improve review/merge failure messages

When review or merge eligibility fails, return:

active identity
active profile
required identity/profile, if known
missing permission
self-author status
PR state
whether the failure can be fixed by switching profile
whether the failure requires a different MCP namespace/session
exact safe next step

5. Update docs and operator guide

Document:

static-profile mode
dynamic-profile mode, if supported
dual namespace recommendation
why editing local environment variables does not necessarily change an already-connected MCP server
required verification before review/merge
hard stop behavior

Update the #128 operator guide (mcp_get_control_plane_guide) and skill registry (profile-switching skill) to reflect the decided model.

6. Tests

author profile runtime context
reviewer profile runtime context
unresolved identity runtime context
static profile mode
dynamic profile mode, if implemented
redacted profile listing
merge failure explanation from author profile
self-author block explanation
no secrets, tokens, keychain IDs, or raw service URLs in output

Acceptance criteria

A new LLM can call one runtime context tool and immediately understand whether it can review/merge in the current session.
The tool clearly distinguishes "profile exists in config" from "profile is active in this connected MCP server."
The tool clearly distinguishes "switch profile in this runtime" from "use a separate reviewer namespace/session."
Review/merge gates remain fail-closed.
No author/reviewer separation is weakened.
No secrets are exposed.
No tags or production behavior are involved.

Non-goals / hard stops

Do not implement GT #107.
Do not bypass profile gates.
Do not expose secrets, tokens, keychain IDs, or raw service URLs.
Do not create tags.
Do not touch production.

## Problem Different LLM hosts are behaving differently when asked to use Gitea MCP author/reviewer profiles. Some sessions have separate author/reviewer MCP namespaces, while others expose only one connected MCP server launched as `prgs-author`. Prompts currently say "switch to prgs-reviewer," but the tool does not clearly tell the LLM whether profile switching is supported in the active runtime, whether the current profile is fixed at server launch, or whether a separate reviewer namespace is required. This causes repeated failed attempts and confusion (observed most recently in the PR #130 review flow, where reviewer actions had to fall back to a CLI path because the connected server was launched as `prgs-author`). The tool should make runtime identity/profile state explicit and provide deterministic next steps. ## Requirements ### 1. Read-only runtime context tool Proposed name: `gitea_get_runtime_context` It must return: - active profile name - authenticated username, if resolved - remote - config model/version (v1 / v2-environments / v2-contexts) - profile source (env var, config file profile, default) - allowed operations - forbidden operations - whether runtime profile switching is supported - whether the active server is static-profile or dynamic-profile - whether review/merge is currently allowed - exact reasons review/merge is not allowed - safe next action when identity/profile is wrong ### 2. Safe profile listing tool Proposed name: `gitea_list_profiles` It must return redacted profile metadata: - profile names - role kind (author / reviewer / operator / limited) - allowed operation families - forbidden operation families - identity status if safely resolvable - enabled/disabled state where the config model has it - no tokens - no keychain IDs - no raw service URLs unless the reveal opt-in (`GITEA_MCP_REVEAL_ENDPOINTS=1`) is enabled It must clearly distinguish "profile exists in config" from "profile is active in this connected MCP server." ### 3. Decide and document the official profile activation model Preferred safe model — dual MCP namespaces for high-risk actions: - `gitea-author` - `gitea-reviewer` - review/merge uses the reviewer namespace/session only. Optional dynamic model: - add `gitea_activate_profile` only if runtime switching is explicitly enabled in config - it must be audited - it must return before/after identity proof - it must require fresh `whoami` / profile verification after switching - it must not weaken self-review or self-merge gates ### 4. Improve review/merge failure messages When review or merge eligibility fails, return: - active identity - active profile - required identity/profile, if known - missing permission - self-author status - PR state - whether the failure can be fixed by switching profile - whether the failure requires a different MCP namespace/session - exact safe next step ### 5. Update docs and operator guide Document: - static-profile mode - dynamic-profile mode, if supported - dual namespace recommendation - why editing local environment variables does not necessarily change an already-connected MCP server - required verification before review/merge - hard stop behavior Update the #128 operator guide (`mcp_get_control_plane_guide`) and skill registry (`profile-switching` skill) to reflect the decided model. ### 6. Tests - author profile runtime context - reviewer profile runtime context - unresolved identity runtime context - static profile mode - dynamic profile mode, if implemented - redacted profile listing - merge failure explanation from author profile - self-author block explanation - no secrets, tokens, keychain IDs, or raw service URLs in output ## Acceptance criteria - A new LLM can call one runtime context tool and immediately understand whether it can review/merge in the current session. - The tool clearly distinguishes "profile exists in config" from "profile is active in this connected MCP server." - The tool clearly distinguishes "switch profile in this runtime" from "use a separate reviewer namespace/session." - Review/merge gates remain fail-closed. - No author/reviewer separation is weakened. - No secrets are exposed. - No tags or production behavior are involved. ## Non-goals / hard stops - Do not implement GT #107. - Do not bypass profile gates. - Do not expose secrets, tokens, keychain IDs, or raw service URLs. - Do not create tags. - Do not touch production. ## Related - #100 (profiles v2 discussion, closed), #120/#121 (contexts v2 + redaction), #128/PR #130 (operator guide/skills tools), #125 (PR-payload URL redaction).

jcwalker3 added the status:in-progress label 2026-07-04 00:56:37 -05:00

jcwalker3 referenced this issue

2026-07-04 01:04:11 -05:00

feat: make Gitea MCP profile activation and runtime identity state explicit (#131) #132

jcwalker3 referenced this issue from a commit

2026-07-04 01:04:12 -05:00

feat: implement profile activation and runtime identity clarity (#131)

Sign in to join this conversation.