MCPizy
BrowseGuidesDocsFor publishersSubmit
Back to Blog
Guide
7 min read
· By Hugo Berton, MCPizy

What Is Pinecone MCP and What Can an Agent Do?

What is Pinecone MCP? A server that lets agents list indexes, then upsert, query and delete vectors in a pinecone vector database.

mcppineconevector-databaseembeddingsclaude-codecursor

Pinecone MCP connects an AI agent to a vector database through five tools. With pinecone connected, an agent can list and create indexes, write vectors, search by similarity and delete by ID. It works in Claude Code, Cursor, Windsurf and VS Code. It handles vectors you already have; it does not turn text into embeddings for you.

What does Pinecone MCP do, in short?

The Pinecone MCP server exposes a vector database to an MCP-compatible agent. Its listing categorises it under Databases and describes it as a vector database for AI embeddings. Instead of writing client code, you ask the agent to create an index, add vectors or find the nearest matches, and the agent calls a tool.

The server publishes five tools: list_indexes, create_index, upsert_vectors, query_vectors and delete_vectors. That covers the basic lifecycle of an index: inspect it, create it, fill it, search it, and remove entries from it.

It is a narrow server by design. It manages indexes and the vectors inside them, which suits retrieval prototypes and agent memory experiments. For the wider picture of how vector servers compare, see Best MCP Servers for Vector Search and RAG in 2026.

What is Pinecone, and why would an agent need it?

Pinecone's official page describes the product as a vector database for AI embeddings. An embedding is a list of numbers that represents the meaning of a piece of text or other data. A vector database stores those lists and returns the ones closest to a query, which is the core operation behind semantic search and retrieval-augmented generation.

The server authenticates with a PINECONE_API_KEY environment variable, which tells you this is an account-based service you connect to, not a file on your laptop. That matters for how you think about data location, access and cost, covered further down.

An agent benefits because retrieval is a repeated chore in agent work. It needs somewhere to put document vectors and a way to pull back the closest ones when a question arrives. Exposing that as tools means the agent can set up and test the store inside the same session where it writes the surrounding code.

What does the Pinecone MCP server let an agent do?

The listing documents five tools, each with a small input shape. Here is what each accepts:

  • list_indexes lists all Pinecone indexes, with no inputs shown.
  • create_index takes a required name and dimension, plus an optional metric.
  • upsert_vectors takes a required index_name and an array of vectors, inserting or updating them.
  • query_vectors takes a required index_name and vector, plus an optional top_k.
  • delete_vectors takes a required index_name and a list of ids.

In practice, a session might start with list_indexes to see what exists, then create_index if nothing fits. The dimension you choose has to match the embeddings you plan to store, so decide your embedding model before asking the agent to create anything.

The query_vectors tool returns the nearest vectors to the vector you supply, and top_k controls how many come back. Because the input is a numeric vector rather than a sentence, the agent or your code must produce the query embedding first.

When does Pinecone fit, and when does a local vector store fit?

Pinecone fits when you want a vector database you reach with an API key, separate from the machine your agent runs on. That makes it a reasonable choice if several tools or teammates need the same index, or if you do not want to run the store yourself. The trade-off is that your vectors live in an account you must manage and secure.

A local store fits when you want everything on your own machine. The Chroma MCP server is the listed alternative: it is described as embeddings, vector search and document storage for RAG applications, and its configuration example uses CHROMA_CLIENT_TYPE set to persistent with a CHROMA_DATA_DIR path for data.

There is also a difference in how you search. Chroma's query_collection takes query_texts, so you pass plain text, while Pinecone's query_vectors takes a vector. If you want the agent to search with sentences and skip an embedding step in your own code, that detail points toward Chroma. If you already generate embeddings elsewhere, Pinecone's shape is no obstacle.

What does Pinecone MCP not do?

The tool list is the boundary. There is no tool that converts text into embeddings, so the server will not read a document and index it on its own. Something else in your workflow has to produce the vectors before upsert_vectors can store them.

The five tools also do not include a way to delete an entire index, change an index's settings or inspect statistics about one. If you need those operations, you would do them outside the MCP server. The delete tool works on vectors by ID, so the agent needs to know the IDs it wants removed.

No CheckMCP audit is published for this server, so there is no independent review to lean on. That does not mean the server is unsafe; it means the checking is yours to do. The guide How to Audit an MCP Server Before Install walks through what to look at.

What setup and permissions should you check?

The install instructions give two routes. The MCPizy CLI route is mcpizy install pinecone, and the direct route is npx -y pinecone-mcp. The configuration example for Claude Code, in ~/.claude.json, runs npx with the arguments -y and @pinecone-database/mcp, and sets PINECONE_API_KEY in env. The same block is shown for Cursor in .cursor/mcp.json and for Windsurf in ~/.codeium/windsurf/mcp_config.json.

Because the package names differ between the two routes, confirm which one your client actually launches before you paste a key into it. As of October 21, 2026, the listing marks the install as verified.

On permissions, start with the key. The server can create indexes, overwrite vectors with upserts and delete by ID, so the key you give it defines the damage a wrong tool call could do. Use a key scoped to a test project first, and keep real data out until you have watched the agent use each tool. MCP Server Permissions and Scopes Explained covers how to think about that.

  1. Install with one of the two commands above.
  2. Add the key through the env block, never in a file you commit.
  3. Ask the agent to run list_indexes as a read-only first call.
  4. Only then let it create or write.

What is the next step after reading about Pinecone?

Open the Pinecone listing to see the tool schemas, the install commands and the client configuration blocks in one place. It is the quickest way to confirm the inputs described above and to copy the config for your editor.

If you are still deciding between a hosted and a local store, read the Chroma listing alongside it. Both expose five tools covering collections or indexes, adding data, searching and deleting, so you can compare them line by line.

The official page does not state a price for Pinecone, so check Pinecone's own pricing before loading a large dataset. A sensible first test is small: create one index, upsert a handful of vectors, run one query and delete what you added. If the results look right, you can scale up with more confidence about what the agent is doing.

Found this useful? Share it.

MCP Servers Mentioned