From de0f708236c9d26aa49667292e57883ba8096d6c Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Thu, 17 Sep 2026 07:41:25 +0000 Subject: [PATCH] chore: retire the release notice carried by v0.67.0 .github/RELEASE_NOTICE.md is prepended verbatim to the release body and is written for one release. v0.67.0 has shipped, so it is removed here to stop it repeating on the next release. Opened automatically by .github/workflows/retire-release-notice.yml. --- .github/RELEASE_NOTICE.md | 11 ----------- 1 file changed, 11 deletions(-) delete mode 100644 .github/RELEASE_NOTICE.md diff --git a/.github/RELEASE_NOTICE.md b/.github/RELEASE_NOTICE.md deleted file mode 100644 index a2dd2d1e1..000000000 --- a/.github/RELEASE_NOTICE.md +++ /dev/null @@ -1,11 +0,0 @@ -## 🔒 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:erase` under the text after its first colon, so it shared — and silently inherited — the approval of a sibling `erase` on the same server. Every dispatch path (`call_tool_*`, direct-name dispatch on `/mcp/all`, `call_tool()` inside code execution), preflight and `describe_tool` now resolve exactly the `server:tool` pair they dispatch. - -**What changes for you** - -- **On `manual` (default) and `scan` trust, 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 of `retrieve_tools` until you approve them: `mcpproxy upstream inspect ` to review, `mcpproxy upstream approve `, the `quarantine_security` MCP tool, or the Web UI. `trust_mode: auto` servers and installs with `quarantine_enabled: false` auto-approve them; no other tool is affected. -- **Blocks carry over.** A tool you had disabled under the old collapsed name stays disabled under its own name until you enable it there; the log records the carry-over at `WARN` with 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. -- **Unresolved names are refused for everyone.** A call to a tool that a connected server's discovered tool set does not contain is refused before any upstream call, for administrators too — while the server's discovery has not completed, retry shortly; afterwards, refresh with `retrieve_tools` and 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_use` answer, 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](https://docs.mcpproxy.app/features/security-quarantine#namespaced-tool-names) and [Agent Tokens → Target tool tier](https://docs.mcpproxy.app/features/agent-tokens#target-tool-tier).