Field note 04

Tool Search and the New Codex Plugin Layer

Skills, MCP servers, apps, and plugins solve different problems. The July Codex updates make the boundaries between them easier to use.

By Codex Rules EditorialJuly 8, 20267 minute read

The extension vocabulary around coding agents has become crowded. A skill sounds like a plugin. A plugin can contain an app. An app may be backed by MCP. MCP tools can be found through tool search.

The words matter because they describe different kinds of trust and maintenance.

What changed on July 8

Codex CLI 0.143 enabled remote plugins by default. The release also made plugin catalog rows more informative, added npm marketplace sources, showed remote and local versions, and improved management commands. In the same release, MCP tools began using tool search by default where supported, and hosted MCP gained session authentication support.

Tool search addresses a scaling problem. Passing the full schema for every available tool into every model turn becomes slow and expensive as a tool catalog grows. The model can instead discover the relevant tool when the task needs it. The official MCP client guidance calls this progressive tool discovery.

This does not remove the need for good names and descriptions. Search can only find what a catalog explains clearly.

The four layers

Skill

A skill is a reusable workflow. It packages instructions in a SKILL.md file and may include references, assets, or scripts. Use one when the core value is knowing how to perform a task consistently.

Examples include a release checklist, a code review method, a test matrix, or a process for preparing 3D assets.

MCP server

An MCP server exposes live tools and context. Use one when the agent needs to read or act on an external system. Codex supports local standard-input servers and remote HTTP servers, including authentication.

Examples include querying an issue tracker, controlling a browser, reading an asset database, or running a domain-specific build tool.

App

An app is an integration people can connect and authorize. It carries the practical questions of identity, permissions, read and write access, and approvals.

Plugin

A plugin is the distribution package. It can bundle skills, MCP-backed capabilities, and related metadata into one installable unit. The official build guide uses a .codex-plugin/plugin.json manifest and supports marketplace distribution, including npm sources.

The short version is simple: skills teach, MCP connects, apps authorize, and plugins distribute.

A concrete example

Microsoft's Playwright MCP server gives an agent structured browser tools. That is the connection layer. A testing skill can tell the agent which viewports to inspect, which flows matter, how to capture evidence, and when a console error should fail the task. A plugin could distribute both pieces together.

The Playwright MCP project also offers a useful naming lesson. A release renamed browser_run_code to browser_run_code_unsafe. Dangerous capability should be visible at the moment of use, not hidden in setup documentation.

My take

The cleanest extension begins with the smallest layer that solves the problem. If instructions are enough, write a skill. If live access is required, add MCP. If other people need a stable installation and permission experience, package it as a plugin.

Starting with a plugin because it sounds complete can produce unnecessary authentication, maintenance, and security work. Starting with a giant MCP server can produce a catalog of ambiguous tools. The layer should follow the need.

This also helps filters on a resource site. Do not put every extension under one “tools” tag. Let people filter separately by workflow knowledge, live connectivity, authorization model, distribution format, read or write access, and approval requirements.

A rule worth copying

Use a skill for repeatable knowledge, MCP for live capability, an app for user authorization, and a plugin for distribution.