chore(deps): update dependency smart-mcp-proxy/mcpproxy-go to v0.69.0 - #161
Merged
Merged
Conversation
renovate
Bot
force-pushed
the
renovate/smart-mcp-proxy-mcpproxy-go-0.x
branch
from
October 2, 2026 14:12
9a604e2 to
963c1af
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.64.0→v0.69.0Release Notes
smart-mcp-proxy/mcpproxy-go (smart-mcp-proxy/mcpproxy-go)
v0.69.0Compare Source
🔒 Rotate your API key if anyone else can read your mcpproxy logs
Earlier releases wrote the admin API key to the log files in plain text. It appeared in the access log whenever the key arrived as
?apikey=, which is how the Web UI and the tray open the/eventsstream and the/ui/page, and inmain.logwhen the key was auto-generated. This release redacts it on the access, authentication and startup log lines that carried it (SEC-01).What to do: if your logs have been shared, collected by a log shipper, attached to an issue, or can be read by other users, treat the key as exposed.
api_keyin~/.mcpproxy/mcp_config.json, or remove the field and one will be generated.~/Library/Logs/mcpproxy/on macOS,~/.local/state/mcpproxy/logs/on Linux (or$XDG_STATE_HOME/mcpproxy/logs/, and/var/log/mcpproxy/when run as root),%LOCALAPPDATA%\mcpproxy\logs\on Windows.The Web UI also stopped printing the key to the browser console.
/metricsnow requires the API keyIf you enabled the Prometheus exporter (
observability.metrics.enabled, off by default),/metricsnow returns401without credentials. Agent tokens get403, because the endpoint exposes fleet-wide data. Send the admin key asAuthorization: Bearer <key>(Prometheusauthorization.credentials) or asX-API-Key. The health probes (/healthz,/livez,/health,/readyz,/ready) stay unauthenticated. See Observability.The REST API no longer allows any origin (CORS)
/api/v1/*and/eventsused to sendAccess-Control-Allow-Origin: *. They now allow loopback origins and the hosts listed intrusted_hostsonly. The bundled Web UI and non-browser clients are unaffected. If a separate web app calls the REST API from another domain, add that domain totrusted_hosts.MCPPROXY_TRUSTED_HOSTSreplaces the list rather than adding to it, and the same list also governs Host validation on the MCP endpoint.Tray self-update on Windows and on macOS tarball installs
The tray's built-in updater now checks every download against the release's
checksums.txtand refuses to install on any mismatch. It also installs the tray binary. Earlier versions put the core binary in its place, so after a "successful" update the tray app turned into a headless core. If your tray stopped showing its menu after an earlier self-update, reinstall it from this release. DMG app bundles (Sparkle) and Homebrew installs were never affected.Also in this release
config.db, which holds OAuth tokens, is now created owner-only (0600). Existing databases are tightened automatically on startup.This release focuses on critical security hardening and bug fixes across authentication, data protection, and system stability.
Security Fixes
/metricsnow requires admin authentication (previously unauthenticated)Access-Control-Allow-Origin: *headers from REST API and/eventsendpointsconfig.dbis now created with owner-only permissions and database backups are properly securedBug Fixes
New Features
Download Installers
sudo apt install ./mcpproxy_*.debsudo dnf install ./mcpproxy-*.rpmHomebrew (macOS/Linux):
v0.68.0Compare Source
🔒 Colon-named tools are approved by their exact name — one-time review after upgrade
A tool's approval record, search-index entry and callability are now keyed by the exact name its server reports, colons included. Earlier releases filed a namespaced tool such as
ns:eraseunder the text after its first colon, so it shared — and silently inherited — the approval of a siblingeraseon the same server. Every dispatch path (call_tool_*, direct-name dispatch on/mcp/all,call_tool()inside code execution), preflight anddescribe_toolnow resolve exactly theserver:toolpair they dispatch.What changes for you
manual(default) andscantrust, colon-named tools on a server that already has an approved baseline become pending once, under their own names, on the first discovery after upgrade. They stay uncallable and out ofretrieve_toolsuntil you approve them:mcpproxy upstream inspect <server>to review,mcpproxy upstream approve <server> <tool>, thequarantine_securityMCP tool, or the Web UI.trust_mode: autoservers and installs withquarantine_enabled: falseauto-approve them; no other tool is affected.WARNwith both names. A tool that was locked pending review is pending under its own name and is unlocked by approving it by that name — nothing else is needed, and nothing is deleted. A namespaced tool you had toggled in the UI keeps its old review lock (with the before/after evidence) under its own name until you approve it; if its old record approved a different definition than the server reports now, it is held as changed for review, and if it had no old record it is pending under an active gate — a toggle never approves a definition nobody reviewed.retrieve_toolsand retry with a listed name. Quarantined, disabled and disconnected servers keep their existing answers: a call to a disconnected server still gets the not-connected /reconnect_on_useanswer, and once the server reconnects and completes discovery, a name that result does not list is refused as unresolved — it is never dispatched.Details: Security Quarantine → Namespaced tool names and Agent Tokens → Target tool tier.
Server edition: configuration keys and modes that never did anything are gone
This release removes the server-edition knobs and
auth_brokermodes that were accepted by the validator but had no reader in production. An oldmcp_config.jsonstill loads; what changes is how the removed keys are treated. Personal-edition users are not affected unless the file carries aserver_editionorauth_brokerblock.Removed keys and modes (spec 107, FR-032):
server_edition.max_user_serversandserver_edition.workspace_idle_timeout— never enforced.auth_broker.headerandauth_broker.header_format— no request was ever rewritten with them.auth_broker.mode: token_exchangeandauth_broker.mode: entra_obo— never implemented.oauth_connectis now the only accepted mode.What the server edition (
mcpproxy-server) does with an old fileserver_edition.max_user_servers is no longer supported and was ignored,auth_broker.header is no longer supported and was ignored, and so on. A server whoseauth_broker.modeistoken_exchangeorentra_oboloses its wholeauth_brokerblock:auth_broker.mode "token_exchange" was never implemented; the auth_broker block for server "<name>" was ignored. The next write-back of the file omits the dropped keys.PATCH /api/v1/configand/api/v1/config/applyreject a document that carries any removed key or mode with the same message, so a script that still sendsmax_user_serversnow gets a validation error instead of a silent accept.token_exchange/entra_oboserver tooauth_connectif you want its connect flow to keep working — otherwise itsauth_brokerblock is dropped on the next load.What the personal edition (
mcpproxy) does with the same fileserver_editionblock and every server'sauth_brokerblock now pass through the personal binary as opaque JSON — every key and value preserved, removed keys included, no warning and no validation. Earlier releases wrote both blocks back as{}, so an API-key bootstrap or aPATCH /api/v1/configfrom the personal binary could erase a team's SSO or broker configuration; that is fixed here (FR-040).store_idp_tokensis now a no-opserver_edition.store_idp_tokensno longer stores anything. The identity-provider access and refresh tokens it used to persist at login existed only to feed the never-implementedtoken_exchange/entra_obomodes, which left a long-lived IdP refresh token at rest with nothing reading it. The writer, the reader and the offline-access scope and authorization parameters that asked the IdP for a refresh token (offline_access,access_type=offline) are removed (FR-033), so a fresh login no longer requests a refresh token from the IdP."store_idp_tokens": truelogs one warning at boot —server_edition.store_idp_tokens is deprecated and no longer stores IdP tokens; remove it— and does nothing else.mcpproxy-serverwithserver_edition.enabled: trueafter upgrading deletes them fromconfig.db(the rows are removed by key before anything else in the server-edition setup runs, so this happens whetherMCPPROXY_CRED_KEYis still set, unset or even invalid; the log linepurged legacy IdP subject-token rowsreports the count). Credentials connected through theoauth_connectflow are not touched.Auth broker: a stored credential is stored, not injected
The
oauth_connectconnect flow, its REST routes, themcpproxy credentialcommands, the encrypted credential store andMCPPROXY_CRED_KEY/credential_encryption_keyall stay. What changes is the promise attached to them: a credential a user connects through the broker is kept for a future broker and is not injected into upstream tool calls. It never was — the injection, resolution and per-user connection-keying code paths that the documentation described had no production caller and are deleted in this release (FR-031, FR-034).mcpproxy credential listandmcpproxy credential statusnow open with the lineStored credentials are kept for a future broker and are NOT injected into upstream calls in this release.credential_brokeractivity rows remain readable and labelled.Agent tokens: a per-user quota inside the deployment cap
The server edition now enforces a 25-token quota per signed-in user on top of the existing 100-record deployment cap (#1177). Revoked tokens keep their slot until they are permanently deleted.
409 ConflictfromPOST /user/tokensthat names their quota — permanently deleting one of their unused tokens frees a slot — so one user can no longer take the whole pool. The 100-record deployment cap remains and every stored token still counts toward it, so a deployment whose stored records add up to 100 refuses the next token for everyone until an administrator frees records; a caller who is still under their own quota then gets the409that says the limit is shared and points at an administrator (the quota is checked first, so a user already at 25 sees their own-quota message instead). A user who already holds more than 25 tokens keeps them; they cannot create another until they are back under the quota.Server edition:
/mcpalways requires a credentialWhen
server_edition.enabledis true,/mcpnow behaves as ifrequire_mcp_authweretruewhatever the file says (spec 107, FR-029). Before this release a server-edition deployment withrequire_mcp_authoff (the default) handed every unauthenticated/mcpcaller an anonymous administrator context.401. A session cookie or a user JWT on/mcp→401(they were never valid there; they are no longer silently promoted). Agent tokens (mcp_agt_…), the global API key and the Unix socket work exactly as before."require_mcp_auth": falseis not a validation error, so no deployment fails to boot on upgrade. It logs one notice —require_mcp_auth: false is overridden to true because server_edition.enabled is true— andmcpproxy doctorreports the same line. Remove the key, or set it totrue, to silence both.require_mcp_authkeeps its configured value./mcpon a server-edition deployment without any credential, it now needs an agent token: each user mints one from the Web UI orPOST /api/v1/user/tokensand sends it asAuthorization: Bearer mcp_agt_….trusted_proxiesnow gates every forwarded header — behind an ingress, set it orpublic_urlX-Forwarded-For,X-Real-IP,X-Forwarded-ProtoandX-Forwarded-Hostused to be believed from any peer: a direct client could choose its own session IP, force the OAuth callback tohttps, or move it to another host. They are now honoured only when the request'sRemoteAddris inside the new top-leveltrusted_proxieslist (CIDRs or addresses; envMCPPROXY_TRUSTED_PROXIES, comma-separated; hot-reloadable; both editions), taking the right-most hop that is not itself a trusted proxy as the client IP. The default is empty — trust nobody (FR-027).What changes behind a reverse proxy or ingress if you do nothing
redirect_urisent to your IdP is built from the listener's own scheme andHost— typicallyhttp://…— instead of the ingress'sX-Forwarded-Proto: https. Your IdP's exact-match registration then refuses the callback and every SSO login fails.client.ip, the connect-flow base URL and the swagger server URL all show the ingress's address, not the user's.Fix (either one)
server_edition.public_urlto the origin users reach (https://mcp.example.com; envMCPPROXY_PUBLIC_URL). It becomes the sole source of the callback URL (<public_url>/api/v1/auth/callback), the connect-flow base URL and the cookieSecuredecision;HostandX-Forwarded-*are ignored for those (FR-025). When it is unset and the listener is not loopback — the published image listens on0.0.0.0:8080— boot logs a warning andmcpproxy doctorreports it; it is not a validation error.trusted_proxies(["10.0.0.0/8"],["fd00::/8"], a single address). Do both if you also want the real client IP in sessions and audit lines.trusted_proxies[0] "…" is not a valid CIDR or IP address) is a validation error at load and onPATCH /api/v1/config. No forwarded header ever feeds the local/remote or administrator classification. Details: reverse proxy, config file, environment variables.Session cookie —
server_edition.session_cookie_secureis new:auto(default) setsSecurewhen the effective scheme is https (public_url, in-process TLS, orX-Forwarded-Proto: httpsfrom a trusted proxy),trueforces it,falsedisables it. Earlier releases never setSecure. Validation refusesfalsetogether with anhttps://public_urlor in-process TLS; an explicitfalseelsewhere is honoured with one boot warning and amcpproxy doctorfinding.HttpOnlyandSameSite=Laxare unchanged (FR-026).Post-login redirect —
redirect_urionGET /api/v1/auth/loginis accepted only as a same-origin path (a single leading/, no scheme, host,//,/\, backslash or control character); anything else lands on/ui/and the login'sauth_eventline carriesredirect_rejected. The Web UI is unaffected (FR-028).Server edition: generic
oidcidentity providerserver_edition.oauth.provideracceptsoidcnext togoogle,githubandmicrosoft, so Okta, Entra ID, Keycloak, Authentik, Auth0 and any other OpenID Connect provider work without provider-specific code (FR-020). The three existing providers behave exactly as before.issuer_url(required;https, orhttponly for a loopback host andallow_insecure_issuer: true),scopes(default["openid","profile","email"];openidis added if missing),groups_claim(default"groups"),email_verified_policy(defaultrefuse_false),display_name(login-button label; falls back to the provider name).client_id/client_secretstay${env:}-referenced; there is no environment variable for nested keys.authorization_endpoint,token_endpoint,jwks_urianduserinfo_endpointcome from<issuer_url>/.well-known/openid-configuration, fetched lazily on the first login and cached, so boot and readiness never wait on the IdP.none, never HS*), exactiss,aud/azp,exp/nbf/iatwith 60 s skew, and a per-loginnonce. Discovered endpoints must be absolutehttps(same loopback exception), and the back-channel client never follows a redirect: the client secret and code are still sent to your configured token endpoint (and a bearer token to your configured userinfo endpoint) as normal, but a 3xx answer from any of the token, JWKS or userinfo endpoints refuses the login instead of being followed — so a compromised or misconfigured endpoint cannot redirect that credential to another host (FR-021).email_verified_policy—refuse_false(default) refuses a login whose ID token saysemail_verified: falseand admits one where the claim is absent;require_truealso refuses an absent claim;ignoreadmits both. Pickrequire_truewhen your IdP always sets the claim;refuse_falseexists so providers that omit it still work out of the box.emailitself is required (email_missingotherwise).oidclogin the user record stores the groups claim from the verified ID token (or fromuserinfowhen the token lacks it — accepted only when the userinfosubequals the token'ssub), replacing the previous list wholesale with agroups_updated_attimestamp; a missing or malformed claim stores[]and logsgroups_claim_missing.google/github/microsoftlogins store[].GET /api/v1/auth/mereturns your groups;GET /api/v1/admin/usersshows every user's groups andgroups_updated_at. Storing groups has no authorisation effect on its own; they are the input to the server-editionaccessgrant (FR-008).(provider, provider_subject_id)and refreshes both on every login. Same provider, same email, different subject is refused (subject_mismatch), so an IdP email collision cannot take over an existing account; an administrator re-arms the binding for a genuinely re-created IdP account by disabling and re-enabling the user — the next successful login rebinds (FR-023).403page ("Sign-in was not permitted") with a reference id; the reason (email_unverified,subject_mismatch,state_invalid, …) reaches only the server log and theauth_eventline under that id. IdP-side failures (discovery_failed,provider_error) and proxy-side failures after verification (internal_error) render a503"Sign-in is temporarily unavailable" instead, so an outage is never shown as "not permitted" (FR-024).GET /api/v1/auth/providerreturns only{"display_name": "…"}— never the issuer, client id, tenant, scopes or domains — so the Web UI labels the sign-in button and detects the edition before login; the personal build answers404(FR-030).Server edition: group-based server access, and credential minting is now session-cookie-only
A tenant — anyone who signs in through the team's IdP rather than through the API key or the local socket — now sees, uses, mints tokens for, connects to and diagnoses exactly the servers their IdP group grants (spec 107, FR-004/FR-009), on the REST API, the Web UI and every agent token they own. Administrators (API key, socket, and any
admin_emailuser) are unaffected.server_edition.access.group_serversmaps an IdP group name to a list of shared server names (or["*"]for every shared server);access.default_serverscovers a user whose groups match no key. A user's grant is the union of their groups' entries; a server must be both shared and granted to appear for them — sharing alone is not enough once the map is active. Theaccessblock itself must be present to change anything: an absent block keeps today'sShared-only behaviour (every shared server visible to every tenant, unchanged); a present block — even{}, with nogroup_servers/default_serversentries — is deny-all for every tenant that matches none of it. Add the block to narrow access; there is no config that widens it beyondShared./api/v1/*,/events), the Web UI and agent tokens a tenant owns.accessmap on every authentication (oneGetUserper call) — so enabling, editing or removing anaccessentry takes effect on the token's very next call, without rotating or re-minting it. The same is true for a tenant's session on core REST and its SSE stream (the per-frame refresher re-resolves the principal, so un-sharing narrows the next frame). Widening a user's access (the IdP adds them to a group, or the map is edited to include them) only takes effect once they sign in again — groups themselves refresh only at login.POST /api/v1/auth/token(JWT renewal),POST /api/v1/user/tokensandPOST /api/v1/user/tokens/{name}/regeneratenow accept only the browser session cookie — a bearer JWT or an agent token gets401. A derived credential can no longer mint another credential, closing the chain where a JWT could renew itself indefinitely and then mint a 30-day agent token in its last second.POST /api/v1/user/tokensalso now capsexpires_inat 365 days (previously unbounded), matching core/api/v1/tokens. The practical freshness bound is now session TTL + the longer of JWT TTL and the longest-lived owned agent token (≤ 365 days); an administratordisablestill takes effect immediately.subject_mismatch) rather than silently taking over the existing record. An administrator re-arms the binding by disabling the user and then re-enabling them — this arms a single-use, persisted rebind window — and the user's next successful login accepts the new subject and rebinds automatically. No other action is needed and no record is deleted.?apikey=, no calls to administrator-only or global-state endpoints (/info,/routing,/docker/status,/connect,/stats/tokens,/security/overview,/onboarding/state, core/activity*, core/config); those cards, chips and pages are hidden rather than issued-and-403'd — Settings stays an administrator-only page (its own personal-server and token management live under/my/servers,/my/tokens). Diagnostics and history use the tenant-scoped/user/diagnosticsand/user/activityendpoints. Theaccessmap is edited by an administrator through Settings' Raw JSON tab and shown read-only as group chips on the admin server page and onAdminUsers.server_edition.accessat all: every tenant keeps seeing everySharedserver exactly as before this release, on group grants alone. To start restricting tenants by IdP group, add theaccessblock — from that point on, only a matching group entry (ordefault_servers) grants a shared server; a present-but-empty block denies every tenant until you populate it. Administrators are unaffected either way.Server edition: every authorization decision and tool call now writes an audit line
A new
audit_logwrites one JSON line per pre-dispatch authorization decision and one per completed tool call (authz/tool_callevents, spec 107 FR-012..FR-019), plus one per login/logout attempt (auth_event, already covered above). Arguments are never logged in the clear: each line carriesargs_sha256, a SHA-256 over the RFC 8785 (JCS) canonical form of the call's arguments, andargs_bytes, never the arguments themselves. A quarantined or otherwise hidden server name is written for the operator's own record but is never echoed back to the caller — the audit line and the caller-facing refusal stay separately governed. Nestedcode_executionsub-calls get their ownauthz/tool_callpair carryingparent_id, so a script that fans out into several upstream tools is fully attributable, not collapsed into one line.audit_log.enabled: false); nothing changes unless you turn it on. Server edition default: on, writing to stdout, with one line logged at startup announcing the sink. Setaudit_log.pathto a file instead (rotated:max_size_mb/max_backups/max_age_days/compress, defaults 50 MB / 10 / 90 days / compressed) if you want the audit stream off your process's own stdout.audit_logabsent, the server edition silently falls back to{enabled:false}and logs oneWARN(audit_log.stdout is ignored under the stdio transport; set audit_log.path) instead of writing audit JSON into the protocol stream. If you explicitly setaudit_log.enabled: true, stdout: truewith nopathunder stdio, that is refused, not silently downgraded: startup fails with exit code 4,audit_log.stdout cannot be used under the stdio transport (stdout carries JSON-RPC); set audit_log.path.audit_log.pathcannot be opened for append (missing parent directory, permissions),mcpproxy-serverexits with code 4 and logsaudit_log.path %q cannot be opened for append: %v. Point the path at a writable location before starting, or use the stdout sink where the transport allows it.plan.mdComplexity Tracking) — a write failure after startup increments an always-on counter (visible inmcpproxy doctor) rather than blocking or dropping the request; audit lines are best-effort after boot, guaranteed-writable at boot.audit_logis bound at sink construction, so every key under it (enabled,path,stdout,max_size_mb,max_backups,max_age_days,compress) requires a restart to take effect; a hotPATCH/applyis accepted but only applies on the next start.This release focuses on enterprise security and multi-tenancy capabilities for Teams edition, with major improvements to scope-based authorization and audit logging.
New Features
Teams Edition:
Bug Fixes
Teams Edition:
Both Editions:
call_tool_writeargumentsImprovements
Teams Edition:
redirect_uriDownload Installers
sudo apt install ./mcpproxy_*.debsudo dnf install ./mcpproxy-*.rpmHomebrew (macOS/Linux):
Other download options (auto-update URLs, archives)
Auto-update URLs (always points to latest):
Binary archives (this version):
Installation Instructions
Windows
mcpproxy-setup-*.exemacOS
Linux / Manual Installation
tar -xzf mcpproxy-*.tar.gzchmod +x mcpproxy./mcpproxy servePlatform Support & Usage
Platform Support
Usage
GUI (Recommended):
CLI:
v0.67.0Compare Source
🔒 Colon-named tools are approved by their exact name — one-time review after upgrade
A tool's approval record, search-index entry and callability are now keyed by the exact name its server reports, colons included. Earlier releases filed a namespaced tool such as
ns:eraseunder the text after its first colon, so it shared — and silently inherited — the approval of a siblingeraseon the same server. Every dispatch path (call_tool_*, direct-name dispatch on/mcp/all,call_tool()inside code execution), preflight anddescribe_toolnow resolve exactly theserver:toolpair they dispatch.What changes for you
manual(default) andscantrust, colon-named tools on a server that already has an approved baseline become pending once, under their own names, on the first discovery after upgrade. They stay uncallable and out ofretrieve_toolsuntil you approve them:mcpproxy upstream inspect <server>to review,mcpproxy upstream approve <server> <tool>, thequarantine_securityMCP tool, or the Web UI.trust_mode: autoservers and installs withquarantine_enabled: falseauto-approve them; no other tool is affected.WARNwith both names. A tool that was locked pending review is pending under its own name and is unlocked by approving it by that name — nothing else is needed, and nothing is deleted. A namespaced tool you had toggled in the UI keeps its old review lock (with the before/after evidence) under its own name until you approve it; if its old record approved a different definition than the server reports now, it is held as changed for review, and if it had no old record it is pending under an active gate — a toggle never approves a definition nobody reviewed.retrieve_toolsand retry with a listed name. Quarantined, disabled and disconnected servers keep their existing answers: a call to a disconnected server still gets the not-connected /reconnect_on_useanswer, and once the server reconnects and completes discovery, a name that result does not list is refused as unresolved — it is never dispatched.Details: Security Quarantine → Namespaced tool names and Agent Tokens → Target tool tier.
This release focuses on bug fixes and improved tool identity enforcement, enhancing reliability and security across both editions.
New Features
Bug Fixes
Improved search matching - Fixed search functionality to correctly match non-contiguous underscore segments in tool names, making it easier to find tools with complex naming patterns. (Both editions)
Token quota enforcement - Fixed per-owner agent token quotas to properly enforce limits, preventing agents from exceeding their allocated token budgets. (Teams edition)
Windows stability - Resolved a critical heap crash issue on Windows caused by recovered panics, and fixed a race condition in Pass-2 temporary directory handling that could cause build instability. (Both editions)
Download Installers
sudo apt install ./mcpproxy_*.debsudo dnf install ./mcpproxy-*.rpmHomebrew (macOS/Linux):
Other download options (auto-update URLs, archives)
Auto-update URLs (always points to latest):
Binary archives (this version):
Installation Instructions
Windows
mcpproxy-setup-*.exemacOS
Linux / Manual Installation
tar -xzf mcpproxy-*.tar.gzchmod +x mcpproxy./mcpproxy servePlatform Support & Usage
Platform Support
Usage
GUI (Recommended):
CLI:
v0.66.1Compare Source
This release focuses on important security and stability fixes, along with OAuth authorization improvements.
Bug Fixes
Improvements
Download Installers
sudo apt install ./mcpproxy_*.debsudo dnf install ./mcpproxy-*.rpmHomebrew (macOS/Linux):
Other download options (auto-update URLs, archives)
Auto-update URLs (always points to latest):
Binary archives (this version):
Installation Instructions
Configuration
📅 Schedule: (in timezone Europe/London)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.