Redact PR web-link URL fields from gitea_list_prs / gitea_view_pr MCP output #125

New Issue

2026-07-03T17:43:37-05:00

jcwalker3 commented

2026-07-03 17:43:37 -05:00

Problem

The #120 redaction work (merged in PR #121) hides service endpoint URLs, Keychain IDs, and token values from normal LLM-facing MCP output (gitea_whoami, gitea_get_profile, gitea_audit_config). However, an MCP-only connectivity proof on 2026-07-03 confirmed that the raw payloads returned by gitea_list_prs and gitea_view_pr still expose PR web-link url fields (and possibly related html_url-style link fields) pointing at the Gitea host.

This is inconsistent with the rules in the live config:

hide_service_urls_from_llm: true
mcp_resolves_endpoints: true

LLM sessions should identify PRs by number/branch/head SHA, not by URL. The MCP layer resolves endpoints; URLs in tool output are unnecessary and leak the service host.

Scope

Apply the same redaction pattern used in #120 to gitea_list_prs and gitea_view_pr output: strip or omit url / web-link fields from normal LLM-facing responses.
Audit other read tools (gitea_view_issue, gitea_list_issues, gitea_create_issue, gitea_create_pr responses, etc.) for the same leak and cover them in the same pass.
Preserve the existing admin/debug opt-in (GITEA_MCP_REVEAL_ENDPOINTS=1) to include the link fields when explicitly requested.
No behavior change to the underlying API calls; output shaping only.

Acceptance criteria

Normal output of gitea_list_prs / gitea_view_pr (and any other tools found in the audit) contains no URLs pointing at configured Gitea hosts.
With the reveal opt-in set, link fields are present as before.
Tests cover both the redacted default and the reveal opt-in for each affected tool.
Existing v1/v2 config behavior unchanged.

References

Follows the redaction pattern from #120 / PR #121.
Related design discussion: #100 (LLM-safe output principles).

## Problem The #120 redaction work (merged in PR #121) hides service endpoint URLs, Keychain IDs, and token values from normal LLM-facing MCP output (`gitea_whoami`, `gitea_get_profile`, `gitea_audit_config`). However, an MCP-only connectivity proof on 2026-07-03 confirmed that the raw payloads returned by `gitea_list_prs` and `gitea_view_pr` still expose PR web-link `url` fields (and possibly related `html_url`-style link fields) pointing at the Gitea host. This is inconsistent with the rules in the live config: - `hide_service_urls_from_llm: true` - `mcp_resolves_endpoints: true` LLM sessions should identify PRs by number/branch/head SHA, not by URL. The MCP layer resolves endpoints; URLs in tool output are unnecessary and leak the service host. ## Scope - Apply the same redaction pattern used in #120 to `gitea_list_prs` and `gitea_view_pr` output: strip or omit `url` / web-link fields from normal LLM-facing responses. - Audit other read tools (`gitea_view_issue`, `gitea_list_issues`, `gitea_create_issue`, `gitea_create_pr` responses, etc.) for the same leak and cover them in the same pass. - Preserve the existing admin/debug opt-in (`GITEA_MCP_REVEAL_ENDPOINTS=1`) to include the link fields when explicitly requested. - No behavior change to the underlying API calls; output shaping only. ## Acceptance criteria - Normal output of `gitea_list_prs` / `gitea_view_pr` (and any other tools found in the audit) contains no URLs pointing at configured Gitea hosts. - With the reveal opt-in set, link fields are present as before. - Tests cover both the redacted default and the reveal opt-in for each affected tool. - Existing v1/v2 config behavior unchanged. ## References - Follows the redaction pattern from #120 / PR #121. - Related design discussion: #100 (LLM-safe output principles).

jcwalker3 referenced this issue

2026-07-03 18:08:10 -05:00

feat: add Gitea issue comment list/create MCP tools (#126) #127

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#125