Closes#13.
Today GITEA_DEBUG=true only flips the zap level to debug, dumps a
contextless `Text Result:` blob per tool call, and enables the gitea
SDK's own debug stream (which doesn't merge with our log file). That is
not enough to diagnose a misbehaving tool call in production.
This change introduces:
- A `pkg/middleware.ToolLogging` ToolHandlerMiddleware that logs each
tool invocation on entry and exit with structured fields: tool name,
redacted args, request_id, token source, duration_ms, and status. The
request_id is stashed in the context so downstream layers can
correlate.
- A `loggingRoundTripper` in `pkg/gitea` that wraps the shared HTTP
transport and emits one structured line per upstream Gitea API call
(method, token-stripped URL, status, duration_ms, bytes). This
replaces — and is far more useful than — `gitea.SetDebugMode()`.
- An effective-config dump at startup (`logEffectiveConfig`) when
debug+config scope is on, so "did my env var get picked up?" becomes
answerable from the log file.
- Token source tracking. CLI flag / GITEA_ACCESS_TOKEN /
GITEA_ACCESS_TOKEN_FILE / per-request Authorization header are now
distinguished in logs as flag/env/env-file/header.
- A baseline redactor in `pkg/debug` that masks args / query params
whose keys look like secrets (token, password, secret, api_key,
authorization, …). This is the placeholder for issue #5's shared
redactor; once that lands, callers here should defer to it.
- `GITEA_DEBUG_SCOPES` env var to scope debug output to any subset of
`tools,http,config`. Default (unset) is "everything".
Test coverage was added for the redactor, scope flag, request-id
helpers, preview truncation (multibyte-safe), and the middleware's
context wiring + error propagation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
this PR introduces support for per-request authentication tokens in HTTP and SSE modes. The server now inspects incoming requests for an `Authorization: Bearer <token>` header.
Previously, the server operated with a single, globally configured Gitea token. This change allows different clients to use their own tokens when communicating with the MCP server, enhancing security and flexibility.
To support this, the Gitea API client initialization has been refactored:
- The global singleton Gitea client has been removed.
- A new `ClientFromContext` function creates a Gitea client on-demand, using a token from the request context if available, and falling back to the globally configured token otherwise.
- All tool functions now retrieve the client from the context for each call.
The README has also been updated to reflect the new configuration option.
Update: #59
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/gitea-mcp/pulls/89
Reviewed-by: hiifong <i@hiif.ong>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Darren Hoo <darren.hoo@gmail.com>
Co-committed-by: Darren Hoo <darren.hoo@gmail.com>
Klaus
Darren Hoo