{"version":"2.1.304","anchor":"artifact-mcp-tools-may-replace-the-built-in-artifact-tool","canonical_anchor":"artifact-mcp-tools-may-replace-the-built-in-artifact-tool","heading":"Artifact tools from an MCP server can stand in for the built-in ones","tier":"internal","area":"Artifacts","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.304\/e\/artifact-mcp-tools-may-replace-the-built-in-artifact-tool","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.304","markdown":"### Artifact tools from an MCP server can stand in for the built-in ones\n\nWhen an MCP server supplies artifact tools, Claude Code can hide its built-in artifact tools and apply your permission rules to the MCP ones instead\n\n**Unclear.** It is not clear what decides whether the MCP tools replace the built-in artifact tool, or whether that is on by default.\n\n**What**\n\nArtifact access in Claude Code can now come from tools supplied by an MCP server, which is an outside program that adds tools to Claude Code, instead of from the built-in artifact tool.\n\n- When an MCP server supplies `read_artifact`, `get_artifact` or `read_file`, the built-in artifact tools can be hidden.\n\n- When the MCP tools take over, the permission check asks nothing more if your permission rules already cover those tools, and otherwise works as it did for the built-in tool.\n\n- WebFetch's note about artifact links now names whichever read tool is in use, rather than always the built-in one.\n\n- Automatic reactions to artifacts are switched off while the built-in artifact tools are hidden this way, as well as when you have turned them off yourself.\n\n**Why**\n\nThis prepares artifact access to move to tools served over MCP. If you write permission rules for artifacts, those rules may need to cover the MCP tool names as well as the built-in one.\n\n- Area: Artifacts\n- Tier: Under the hood\n- Useful: 4\/5\n- Signal: 4\/5\n- Scope: individual\n- Heads-up: no"}