So you installed a coding agent, and it isn't working as well as you'd like. It hallucinates, keeps building way too many things from scratch, and it tells you you are definitely, surely absolutely right.

How can you make it better? By adding some extensibility!

This article gives you the lay of the land of coding agent IDE extensibility. It covers MCP, CLI, slash commands, hooks, subagents, Agent Skills and finally plugins/extensions. We’ll break down what each thing is useful for, where you can use them, and some good examples too. After this, you'll get a great idea of how to make your coding agent work well.

But first, what are tools?

There’s a lot of terminology in this article, and defining what a tool is will help us learn the rest. For our purposes, tools are bits of code that let a coding agent accomplish a task. For example, you may have a tool that does a web search, and returns results, or a tool that lists your Github issues. But, how do we get agents to load tools consistently?

Model Context Protocol (MCP)

First on this list of tooling is MCP, or Model Context Protocol. This is a standard that defines how tools should be specified for agents to use, such that agents that support this standard can easily install and use tools in a modular fashion.

The best metaphor I've heard about is that of USB-C ports; if you got a device that has ‘em, it can use anything that needs ‘em with some exception!

MCPs are a key development to let LLMs actually do things. For example, a setup for a coding agent could include access to the Linear MCP to manage issues, the Hugging Face MCP to find datasets and the Playwright MCP to iteratively test and navigate web apps. The Pinecone MCP server exists to make accessing and querying indexes through your agent.

Typically, someone would need to write a bunch of code to support their individual agent to use that tool, and then, support deploying that tool where it's running (remotely or locally). That's a lot of work! Now, a maintainer just needs to write the MCP code once for a toolset, and it’s instantly compatible with loads of coding agents. Neat!

The main drawback of MCP is that if you install a server, all of those tools usually remain in context unless your agent harness is doing something unusual to dynamically load them. So it can end up using a lot of tokens if you're not careful or if you install too many of them. The best practice here is to install the ones that you need in each repo.

Command-line interface

Next is the command-line interface, or CLI. CLIs predate agentic harnesses and agentic development. These are tools that you typically install inside your terminal that allow you to manage resources, and they're primarily for developers. They've gained a lot of popularity as accessories for agents as they contain some nice properties that make agents easy to use.

It turns out that a lot of CLIs have the ability to self-document, so you can call help on them and the tool tells you how to use it. Using this type of tool is particularly nice for agents to learn how to use and run commands on. If an agent becomes aware of a tool, it can run a --help command to check what the tool does and why, then proceed.

The benefit of a CLI is you gain access to predictable, reliable local tools that don’t enter context until necessary and are self documenting to boot. CLIs have existed as a concept for a much longer time than MCPs have, so LLMs may have seen a lot of code and documentation on how to use them.

Examples of good CLIs include the Pinecone CLI, the GitHub CLI, and the Hugging Face CLI. These are all interfaces that allow you to do certain operations. Usually, you'd choose a CLI for anything that you want to do locally.

Otherwise, if you want to ship your agent and have it run somewhere else and do things on your behalf, you might want to use an MCP instead. This is because MCPs are easier to manage remotely than CLIs are.

It’s worth checking out if any applications you use have CLIs, as your agents may be able to use them out of the box without much configuration!

Slash Commands

The next topic is slash commands, not to be confused with the aforementioned command line tools! These are the character slash and then some phrases, like /check or /test. They're mostly used as shorthand for specific things you want your agentic IDE to do or for prompts that you've pre-saved. 

For example, maybe you have a neat mini-prompt for having an agent do a thing, like spellchecking. So you might have a slash command that says /spellcheck, which injects a prompt you wrote with your flavor of spell checking and text review.

Not many IDEs support this, and skills have mostly replaced them. So be sure to check what IDE you're working in, whether it uses slash commands or wants you to use skills. The nice thing about slash commands is that they're always user-invocable, so you can pick to use them, whereas skills in some places have different defaults on invoking dependent on the IDE settings.

Hooks

Hooks are a really fun extensibility, but involve more configuration than anything else on this list. Hooks are scripts that lock on and fire when certain events occur from your agent, in order to automatically, and predictably, modify the behavior of your agent. 

When you run an agentic IDE or a CLI tool, there are certain events that those tools emit. It could be a user submit prompt event, a file edit event, a tool invocation event, or an MCP tool invocation event. You can attach a script to a hook. A hook watches that event. When it occurs, the hook automatically conducts an action described in natural language or by a script to do a certain thing.

For example, say you're using an MCP and you built it yourself, but there's a certain tool call that's particularly not fun that you want to prevent your agent from calling automatically, like an expensive loading operation or a deletion. Right before it calls that, you could have a hook that interrupts it and does a cost calculation before proceeding.

Or maybe after you finish editing a file, you always want to run an agent that starts a background process to update all of your docs. A hook could watch for file edits to key files and fire once those are updated, or run tests in the background.

In order to make a hook, you usually need to define a config in a file somewhere in your agent, which the specific event the hook fires from, the script it runs when this happens, and what is delivered back to the agent. The Claude Code docs have a fantastic guide on how hooks work, and the concepts carry over to other agentic IDEs too.

Agent Skills

The easiest way to explain Agent Skills is that it's a natural language workflow document. It’s not just a fancy markdown file, as many believe! Skills can come with associated reference documents, and even entire self-contained scripts too. Together, the skill allows for a coding agent to conduct a workflow or process repeatedly, in a reliable fashion, almost like a mini-package.

Why is it reliable? Whenever you ask an agent to complete a task, it can take any number of actions to complete that task. If you're asking an agent to repeatedly do a task, or maybe you figured out a way to use an agent or an agentic IDE that you want other people to be able to replicate, you want to put that information inside of a skill.

A skill allows you to describe the set of actions or workflow you want somebody to be able to complete so that you can save that and have other people use it and so that you can have your agent do that repeatedly.

For example, you could have a skill that runs a bunch of tests in a specific way, like a Playwright skill that runs your integration tests and then checks if your app is working. Or you can have a skill like the Pinecone CLI skill that wraps the command-line tool and teaches an agent how to use it, or a skill like the Pinecone QuickStart, which has a customized walkthrough for people learning to use Pinecone for the first time.

Of all the tooling listed here, skills are the most underrated. Make one every time you have a workflow that you think happens more than once that you want to happen in a specific way. They're super handy and they're the main workhorse of all the agent extensibility processes you can see out there. In fact, most people install skills before they install and configure all this other stuff.

You can install skills from a skills marketplace like skills.sh by doing the following:

npx skills add pinecone-io/skills

Take care when installing skills and always verify their contents before doing so.

Subagents

So, I heard you like agents. What if your agent had an agent? A subagent is simply a scoped copy of an agent process, usually with a custom prompt, their own context window, toolset permissions, and access to other toolings defined above.

Your main agent is the thing that's helping you do whatever you're doing inside your agentic IDE. You can specify them usually with a markdown file, and you can fire them off to happen in the foreground, to run in parallel, or happen in the background. These are great for when you have tasks that are distinct, that don't overlap, or tasks that you want to happen but you don't want to pollute your main context with.

This could be for data generation in parallel. It could be a docs subagent that's an expert at editing docs that you fire off in the background whenever you're working on other things, or an agent that runs tests, or a bunch of agents that complete a bunch of different changes while you're working on some main thread, or you have one agent that spins off a bunch of things, and so on. The best part about this is that you can usually have these agents backgrounded, so they don't block your main supervising agent from doing other things.

The main thing to be careful about: when you run too many subagents, they can eat up your context usage, but they can also cause a bunch of changes that you have to keep track of all at the same time. Usually when people are running subagents, they use another framework or IDE that's specialized in managing these subagents, like Conductor, Sculptor by Imbue, or Cursor.

Plugins and Extensions

Our final concept is that of the plugin or extension. These are supported packages that bundle together all of the things we’ve spoken about so far, in a clean installable way. This lets users add on a whole suite of capabilities at once, without having to configure each one individually. So, if you are interested in sharing your configuration with others, developing a plugin (in Claude Code, Codex, Copilot etc) or extension (in Gemini CLI) is a great way to do so.

An example of this is of course, our wonderful Pinecone plugins and extensions located here.

To easily install our plugins and extensions, or find the best extensibility for you,

take a look at this chart here: