# I installed a plugin. What did I actually install? Author: Rajat Published: 2026-09-23 Canonical URL: https://www.thebuildercourse.com/blog/what-is-an-agent-plugin Publisher: The Builder Course Unpack instructions and connections, then compare plugins in Codex, Claude Code, and DeepSeek Harness. Understand installation, account access, and action approval. When I install a plugin, I want to know what it adds to the application. Does it give me a saved procedure, connect to another service, or add something else? Browser extensions and editor plugins work this way too: the application decides what an extension can add. The packages below show what that means for agent applications. I compare Codex, Claude Code, and DeepSeek Harness because the same word covers different capabilities in each. [The shopping example](https://www.thebuildercourse.com/blog/mcp-skills-plugins) shows how a plugin can contain a skill and an MCP connection. ## What files are inside a plugin? When I open a plugin on my computer, I see a folder with files inside. Here are three fictional packages using a supported Codex folder layout. Open a file to see what it contains. You do not need to understand every line; look for the package details, the instructions, and the connection settings. An interactive illustration with sample data and written responses. No account is connected and no AI model is running. ### Reply-writing helper Fictional example using the supported Codex compatibility layout. Files beginning with a dot may be hidden in your file browser. ```text reply-writing-helper/ ├── .codex-plugin/ │ └── plugin.json └── skills/ └── write-reply/ ├── SKILL.md └── reply-template.md ``` .codex-plugin/plugin.json: This file names the plugin and points to the parts it includes. The paths below start from the plugin’s top-level folder. ```text { "name": "reply-writing-helper", "version": "1.0.0", "description": "Draft a reply from pasted text.", "skills": "./skills/" } ``` skills/write-reply/SKILL.md: The skill describes when to use it and how to write the reply. Its template sits in the same folder, so the instructions can refer to it by name. ```text --- name: write-reply description: Draft a reply when I paste an email. --- Read the email I provide. Ask me for any missing facts. Write a short, friendly reply using reply-template.md. Show me the draft. Do not send it. ``` skills/write-reply/reply-template.md: An ordinary text file the skill can reuse. A skill folder can include supporting files alongside SKILL.md. ```text Hi [name], [Answer their question using the facts provided.] [Next step, if needed.] Thanks, [My name] ``` The instructions and template travel together. This plugin works on pasted text; there is no Gmail connection in this folder. ### Calendar connection Fictional example using the supported Codex compatibility layout. Files beginning with a dot may be hidden in your file browser. ```text calendar-connection/ ├── .codex-plugin/ │ └── plugin.json └── .mcp.json ``` .codex-plugin/plugin.json: This file names the plugin and points to the parts it includes. The paths below start from the plugin’s top-level folder. ```text { "name": "calendar-connection", "version": "1.0.0", "description": "Connect to calendar tools.", "mcpServers": "./.mcp.json" } ``` .mcp.json: This tells the app where to reach a calendar MCP server. The server runs elsewhere; its code and your calendar events are not in this file. The address here is fictional. ```text { "mcpServers": { "calendar": { "type": "http", "url": "https://calendar.example.invalid/mcp" } } } ``` This package supplies connection settings, with no skills folder. The server must be running and account access must be authorised before its tools can work. ### Calendar assistant Fictional example using the supported Codex compatibility layout. Files beginning with a dot may be hidden in your file browser. ```text calendar-assistant/ ├── .codex-plugin/ │ └── plugin.json ├── skills/ │ └── find-time/ │ └── SKILL.md └── .mcp.json ``` .codex-plugin/plugin.json: This file names the plugin and points to the parts it includes. The paths below start from the plugin’s top-level folder. ```text { "name": "calendar-assistant", "version": "1.0.0", "description": "Find a suitable time to meet.", "skills": "./skills/", "mcpServers": "./.mcp.json" } ``` skills/find-time/SKILL.md: This is where the scheduling preferences live. The skill tells the agent how to use the calendar tools; it does not create a calendar connection by itself. ```text --- name: find-time description: Help me find a time for a meeting. --- Use the calendar tools to check availability. Suggest times between 09:00 and 17:00. Keep 12:00–13:00 free for lunch. Leave 15 minutes after existing meetings. Show me a suggested time. Ask for confirmation before creating an event. ``` .mcp.json: This tells the app where to reach a calendar MCP server. The server runs elsewhere; its code and your calendar events are not in this file. The address here is fictional. ```text { "mcpServers": { "calendar": { "type": "http", "url": "https://calendar.example.invalid/mcp" } } } ``` One folder, two different jobs: SKILL.md explains how to schedule; .mcp.json tells the app where to connect. The manifest packages them together. This example uses the Codex compatibility layout. Newer portable packages can put `plugin.json` and `mcp.json` directly in the top-level folder. If the names differ from what you see on your computer, check the format your app uses. [Codex plugin folder layouts](https://developers.openai.com/plugins/build/plugins) The writing helper needs no mailbox connection to work on text I paste. The calendar connection supplies access to tools once it is configured and authorised. The combined package includes a procedure for using those tools. Each can be a useful plugin. [OpenAI plugin architecture](https://developers.openai.com/plugins/concepts/plugins) A plugin can have a visual interface, but that is not a requirement. ‘Mini app’ can be a helpful first impression of some plugins; opening the contents gives us a more precise answer. ## Plugin for which application? The application determines what a plugin can add. Select one below to compare its supported capabilities; DeepSeek Harness uses plugins for parts of its runtime too. An interactive illustration with sample data and written responses. No account is connected and no AI model is running. ### Codex An installable package Skills and supporting files MCP connections Optional lifecycle hooks A plugin can group reusable workflows and connections. The exact supported components and setup depend on the Codex surface. Source: https://developers.openai.com/plugins/concepts/plugins ### Claude Code A package of extensions Skills and agent definitions MCP connections Hooks and other supported extensions The broad packaging idea is similar, but Claude Code has its own conventions. Check dependencies and configuration before moving a package between apps. Source: https://code.claude.com/docs/en/plugins ### DeepSeek Harness A module in the running system Tools and capability services Model adapter Agent loop and other runtime parts Its plugin architecture reaches inside the running agent system. A plugin can register or replace capabilities; the term covers more than a bundle of task instructions. Source: https://deepseek-harness.github.io/deepseek-harness/en/reference/ Codex can package skills and MCP connections, with other supported capabilities such as hooks. Claude Code also distributes extensions through plugins, including skills, agent definitions, hooks, and MCP servers. Similar ingredients do not make every package interchangeable. [Codex plugin architecture](https://developers.openai.com/plugins/concepts/plugins), [Claude Code plugins](https://code.claude.com/docs/en/plugins) DeepSeek Harness uses plugins throughout its own runtime: modules can contribute capabilities such as the tool registry, model adapter, or agent loop. That is a broader job than a task procedure bundled with a connection. Its current developer-preview documentation describes plugins that register capabilities through the running system. [Harness plugin tutorial](https://deepseek-harness.github.io/deepseek-harness/en/develop/basic/) The **DeepSeek model** and **DeepSeek Harness** are different parts. A DeepSeek model running in another application follows that application’s extension system. Choosing a model does not by itself choose a plugin format. DeepSeek’s docs cover its own Harness as well as integrations with other applications. [DeepSeek agent integrations](https://api-docs.deepseek.com/) ## Packaging does not change the parts’ jobs. If I connect an MCP server directly, I have an MCP connection. If I distribute the configuration for that connection inside a plugin, I also have an installable package for a particular app. The server still exposes its capabilities through MCP. Likewise, putting a skill inside a plugin does not turn its instructions into an account connection. DeepSeek Harness also has documented skill support and an MCP client alongside its plugin architecture. These ideas can coexist. [Harness skills](https://deepseek-harness.github.io/deepseek-harness/en/reference/subsystems/skills), [Harness MCP integration](https://deepseek-harness.github.io/deepseek-harness/en/guide/mcp-memory) When moving a setup to another app, I would inspect the instructions, the server connection, and the app-specific configuration separately. A shared skill format or MCP support can help parts travel. Scripts, tools, authentication, and other dependencies still need checking. ## Which approval are we talking about? | Decision | What it concerns | | --- | --- | | Directory review | Whether a publisher’s package can appear in a curated catalogue. | | Account authorisation | Whether the integration can access your account, and with what scope. | | Action approval | Whether this particular action may run under the app’s policy. | A plugin can be developed locally or shared privately without first appearing in a public directory. A directory accepting a plugin does not sign in to my calendar for me. Signing in does not tell me that every action will ask for confirmation either. Those are separate decisions. [OpenAI packaging and distribution](https://developers.openai.com/plugins/build/plugins), [Claude Code local development](https://code.claude.com/docs/en/plugins) For our calendar example, I would check what the package contains, who runs the connected server, whether it can only read events or also change them, and what confirmation the app requires. That tells me far more than the word ‘plugin’ on its own. ## Start with the job you want done. If I want to reuse a writing procedure on pasted text, a skill may be enough. If I need current calendar data, I need a suitable connection. If I want teammates to install the procedure and connection together, a plugin may be a convenient way to distribute them. The package should make those pieces easy to inspect. The [connection diagram](https://www.thebuildercourse.com/blog/how-mcp-works) follows an MCP request, and the [skill examples](https://www.thebuildercourse.com/blog/what-is-an-agent-skill) show what the saved procedures contain. Tool details checked against linked documentation on 23 September 2026. Product conventions can change; check the source for your application. ## Read next - [What is MCP? A shared protocol for connecting AI agents to apps](https://www.thebuildercourse.com/blog/how-mcp-works): Follow the connection that a plugin can configure. - [Your repo is your AI’s memory. Give it a decent one.](https://www.thebuildercourse.com/blog/repo-readiness): Give an agent the project context it needs alongside its extensions.