Add authenticated-user identity lookup to Gitea MCP #9

New Issue

2026-07-01T10:46:04-05:00

jcwalker3 commented

2026-07-01 10:46:04 -05:00

Context

While using the existing Gitea MCP tool to review/merge PR #8 for issue #52, the LLM could inspect repository/PR state but could not verify the authenticated Gitea account through the MCP tool. This blocked safe approve/merge behavior because Gitea rejects self-review/self-merge when the authenticated user is also the PR author.

Problem

Review and merge workflows require the MCP server to expose the authenticated Gitea identity so the caller can verify reviewer eligibility before approving or merging a PR.

Required capability

Add a read-only Gitea MCP tool such as:

getAuthenticatedUser
whoami
getCurrentUser

The tool should return safe identity metadata only, such as:

username/login
display name, if available
user id, if available
email only if already exposed by Gitea API and safe under current config
server URL/base URL
token scope summary if safely available, otherwise omit

Acceptance criteria

Gitea MCP exposes a read-only authenticated-user lookup.
The tool does not mutate anything.
The tool does not expose the token or secrets.
Output redacts any sensitive values.
Review/merge workflows can compare authenticated username against PR author username.
If identity cannot be determined, approve/merge workflows must fail closed.
Existing Gitea MCP behavior is not broken.
No Jenkins, Ops, Release, deploy, rollback, or production behavior is added.

Security requirements

Never print the token.
Never print authorization headers.
Redact secrets from logs and tool output.
Identity lookup must be safe to call before mutating actions.
Merge/approve tools should require caller-side or server-side eligibility checks before mutation.

Suggested labels

mcp
gitea
security
dogfooding
read-only

Do not implement this unless explicitly approved after the issue is created.

## Context While using the existing Gitea MCP tool to review/merge PR #8 for issue #52, the LLM could inspect repository/PR state but could not verify the authenticated Gitea account through the MCP tool. This blocked safe approve/merge behavior because Gitea rejects self-review/self-merge when the authenticated user is also the PR author. ## Problem Review and merge workflows require the MCP server to expose the authenticated Gitea identity so the caller can verify reviewer eligibility before approving or merging a PR. ## Required capability Add a read-only Gitea MCP tool such as: - `getAuthenticatedUser` - `whoami` - `getCurrentUser` The tool should return safe identity metadata only, such as: - username/login - display name, if available - user id, if available - email only if already exposed by Gitea API and safe under current config - server URL/base URL - token scope summary if safely available, otherwise omit ## Acceptance criteria - Gitea MCP exposes a read-only authenticated-user lookup. - The tool does not mutate anything. - The tool does not expose the token or secrets. - Output redacts any sensitive values. - Review/merge workflows can compare authenticated username against PR author username. - If identity cannot be determined, approve/merge workflows must fail closed. - Existing Gitea MCP behavior is not broken. - No Jenkins, Ops, Release, deploy, rollback, or production behavior is added. ## Security requirements - Never print the token. - Never print authorization headers. - Redact secrets from logs and tool output. - Identity lookup must be safe to call before mutating actions. - Merge/approve tools should require caller-side or server-side eligibility checks before mutation. ## Suggested labels - `mcp` - `gitea` - `security` - `dogfooding` - `read-only` Do not implement this unless explicitly approved after the issue is created.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#9