{"version":"2.1.318","anchor":"mcp-tool-hooks-can-be-own-tools-and-the-hook-settings-schem","canonical_anchor":"hooks-mcp-tool-hook-type-gets-server-refused-handling-and","heading":"mcp_tool hooks get their own runner, can block actions, and are restricted from project settings","tier":"notice","area":"Hooks","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.318\/e\/mcp-tool-hooks-can-be-own-tools-and-the-hook-settings-schem","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.318","markdown":"### mcp_tool hooks get their own runner, can block actions, and are restricted from project settings\n\nmcp_tool hooks now wait for servers, report clear failures, can block actions, and are handled more strictly when they come from project settings\n\n**What**\n\nA hook is a command you set up to run automatically at certain moments while Claude Code works. An `mcp_tool` hook calls a tool on an MCP server, an outside service that gives Claude tools. Claude Code could already read this hook type when a remote list allowed it. What changed now:\n\n- Own runner: `mcp_tool` hooks now run through their own path instead of the general one. They wait for plugin MCP servers to connect, up to the hook's time limit, and report `timed out` if the servers do not connect. They report `MCP server '...' not connected` if the server is missing, and \"The organization's MCP server lists could not be applied to\" a server when that check fails.\n\n- Blocking: a response that is not empty is now recorded, and a new check can mark the result as blocked, using the response as the output. A blocking failure has the new code `hook_mcp_tool_failed`. Before, these hooks only failed when aborted, on an error, or when the call was not ok, and they never blocked.\n\n- Project settings: hooks from `projectSettings` are skipped when `userSettings` exist and a new check is true. They may also go through a different runner when an input stream is available. The check for restricted hook sources now also matches `mcp_tool` hooks from `projectSettings`. It also matches plugin `agent` and `http` hooks whenever `pluginId` is set; before, `agent` hooks also needed a further check.\n\n- Hook-type check: `mcp_tool` is now included, and the check for `agent` hooks now looks at the right value, fixing an earlier slip.\n\n- New options: hook conditions gain an `if_pattern` option controlled by `tengu_woven_ladder`, which defaults to an empty list. Nothing has been read about that flag. A hook settings schema gains `needsCtrlYFix`, which can only be true.\n\n- Abort check: the hook list is now passed to a new function before the abort check.\n\n**Why**\n\nIf you write `mcp_tool` hooks, they can now stop an action, and their failures say what went wrong. Hooks that come from a project's settings are treated more strictly, so a project cannot always run them the way your own settings can.\n\n- Area: Hooks\n- Names: `mcp_tool`, `needsCtrlYFix`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: yes"}