Three.js Agent Skills vs Three.js MCP tools

Short answer

Use Agent Skills to give an agent reusable architecture, implementation, and validation instructions. Use MCP tools to expose callable capabilities such as inspecting a live scene, reading runtime state, or applying an allowed action. These mechanisms are complements, not interchangeable products.

A strong combined workflow uses a skill to decide what should happen, an MCP tool to observe or act when live access is necessary, and an independent validation path to establish what happened. Treat a repository evidence artifact as current only when its status is valid and its source hash matches checked-in source.

The protocol-level difference

The MCP specification explicitly treats tools as model-controlled and recommends a human in the loop who can deny invocations. A skill does not remove that permission boundary. Instructions that say to call a mutating tool are not authorization to do so.

Choose Agent Skills when

• The agent must select a rendering architecture before acting.
• The task should use a repeatable procedure across repositories or sessions.
• Mechanism, units, coordinate spaces, lifecycle, resource costs, and failure conditions must be explained.
• The workflow can operate from source, local references, scripts, and checked-in examples.
• The team wants the instructions, their revision, and their evidence contract reviewable in Git.

For example, the image-pipeline skill can define one owner for tone mapping, require only consumed MRT signals, and state when a graph change needs invalidation. Those are design contracts, not live scene commands.

Choose MCP tools when

• The question depends on the scene that is running now rather than source alone.
• The agent needs a structured scene tree, material state, performance reading, or another capability exposed by the selected server.
• A reversible, user-authorized runtime action is faster and clearer than inferring state from code.
• The client should discover a bounded function with declared inputs rather than improvise an integration.

The pinned threejs-devtools-mcp README is one concrete example. At the reviewed commit it documents 59 tools, a browser bridge, an open-tab requirement, and real-time inspection and modification. Those are facts about that server, not promises made by every Three.js MCP implementation.

Use both with explicit ownership

One safe pattern is:

1. The skill reads the task and selects the mechanism and diagnostics.
2. The agent inspects source and establishes what may be changed.
3. A read-only MCP tool gathers live state when source cannot answer the question.
4. The user or host permission model approves any mutating invocation.
5. Source changes remain ordinary reviewed repository changes.
6. The validation workflow checks final output, diagnostics, backend identity, and negative controls independently of the tool's success response.

The MCP result can be an input to evidence, but it is not automatically the whole evidence package. A tool saying that an object was modified does not prove that the final image, lifecycle, or frame cost is correct.

Security and operational boundaries

Inspect the exact server, tool schema, transport, and side effects before enabling it. A local browser bridge, remote HTTP service, and source-editing tool have different trust surfaces. Use least privilege, prefer read-only inspection when it answers the question, and keep a human able to deny calls.

An Agent Skill is also part of the instruction supply chain. Review its source before installation. Portability does not imply trust, and a Markdown procedure can still direct an agent toward unsafe actions if its provenance is poor.

Migration and adoption

Do not migrate from skills to MCP merely because live tools exist. Add an MCP server when a named runtime capability closes a real gap. Do not replace a useful MCP inspection path with static guidance when the decision requires current scene state.

Document the boundary in routing and minimal context: which skill owns reasoning, which tools are allowed, which calls may mutate state, and which independent checks close the task. The existing-project guide covers adding the workflow without rebuilding the application.

Limitations

Skills cannot magically inspect a live process without host capabilities. MCP tools do not inherently carry expert graphics architecture, version policy, or a falsifiable visual contract. Server quality and coverage vary, and this page does not use one representative server to rank the category.

No universal cost or performance conclusion follows from either format. Context use, latency, setup work, and correctness depend on the client, server, model, repository, and task.