Read and write a Pinecone vector index — upsert records, run semantic and text search, manage indexes and namespaces, and use Pinecone's hosted embedding and reranking models.
Pinecone ships in the w6w first-party pack. It declares 24 actions, 3 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.pineconePinecone is a managed vector database, and this app reads and writes an index from a workflow: upserting records, searching by vector or by text, and managing the indexes and namespaces records live in. It supports both ways of building an index — bringing your own vectors, or letting Pinecone embed and rerank text for you — and exposes Pinecone’s hosted embedding and reranking models directly, which removes the most common source of vector-search bugs: querying with a different embedding model than the one used to write the documents.
Index lifecycle is covered end to end: creating and configuring an index, listing and deleting namespaces, and creating a point-in-time backup or restoring one into a new index for recovery. Every action that cannot say in advance how much data it will remove — deleting by filter, emptying a namespace, deleting an index — requires an explicit confirmation, and index and namespace deletion cannot be undone once run.
Three routes to the same 24 actions. The Workflow tab is generated from Pinecone's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
backup-create Take a point-in-time backup of a serverless index. Asynchronous — the response comes back before the copy is Ready. Restoring makes a NEW index, never an overwrite.
backup-list Every backup in the project, with the id a restore needs and the record count that says which one to pick. Only a Ready backup can be restored.
embed Embed text with one of Pinecone's hosted models — the same models that back integrated-embedding indexes. Say whether the text is a passage or a query; it matters.
index-configure Change what an index allows after creation — deletion protection, tags, and an integrated index's read/write parameters. Dimension, metric and model are permanent.
index-create Create a serverless index. Dimension and metric are permanent — changing either means deleting the index and re-embedding everything in it.
index-create-for-model Create an index with integrated embedding — text in, text out, no vectors. The model is permanent, and the field map names which field of your records gets embedded.
index-delete Permanently delete an index and every record in it. Refused by Pinecone while deletion protection is on, and refused here without an explicit confirmation.
index-get One index in full — its data-plane host, dimension, metric, readiness and, for an integrated-embedding index, the field map that says which field gets embedded.
index-list Every index in this API key's project, with the data-plane host, dimension, metric and readiness of each.
index-restore Create a NEW index from a backup — never an overwrite, so recovery is additive. Asynchronous: the index arrives Initializing.
index-stats Record counts per namespace, and the index's dimension. The call that answers 'did the ingest actually land'.
model-get One model's details — dimension, supported parameters, batch and sequence limits. The authoritative source for the dimension an index needs.
model-list The embedding and reranking models available to this project, with the dimension each produces — the number an index has to be created with.
namespace-delete Delete a namespace and everything in it — in a namespace-per-tenant design, that is one customer's entire data. No undo.
namespace-list The namespaces in an index — Pinecone's isolation boundary, one per tenant in most designs. The empty-string namespace is the default one.
record-delete Delete by id, by metadata filter, or empty a whole namespace. The last two need an explicit confirmation — neither can say in advance how much it will remove.
record-fetch Read records by id, with their values and metadata. Ids that do not exist are missing from the response rather than an error.
record-list Enumerate record ids in a namespace, optionally by prefix — the reason to prefix ids by their parent document. Returns ids only, not values or metadata.
record-query Similarity search from a query vector — or from the id of a record already in the index, which is how 'more like this' works. Embed the query with the SAME model as the records.
record-search Semantic search from a text query on an integrated-embedding index — no embedding call, and an optional reranker that reads query and candidate together.
record-update Change one record's values or metadata without replacing it. Metadata merges — named keys are set, unnamed keys survive — but a key cannot be removed this way.
record-upsert Write or replace records by id. A record that exists is overwritten whole — metadata included — so this is replace, not merge. Up to 1000 vectors or 2 MB per call.
record-upsert-text Write records as text into an integrated-embedding index — Pinecone embeds them. Ids are `_id`, the text field is whatever the index's field map names, and the batch limit is 96.
rerank Reorder candidate documents against a query with a cross-encoder. Works on any documents, not just Pinecone's — reranking a database or web result set is a fine use of it.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Pinecone's real ids.
{
"manifestVersion": "2",
"name": "pinecone-example",
"steps": [
{
"id": "backup-create",
"uses": {
"app": "io.w6w.pinecone",
"action": "backup-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"indexName": "<indexName>"
}
}
]
}backup-create backup-list embed index-configure index-create +19 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Pinecone, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Pinecone. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "backup-create",
payload: {
indexName: "<value>",
// name: "<value>",
// description: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action backup-create --payload '{"indexName":"<value>"}' Give an AI agent Pinecone — without giving it Pinecone's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.pinecone#backup-create",
"input": {
"indexName": "<indexName>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Pinecone connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Pinecone's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Pinecone itself is MIT, and the runtime that executes it is source-available (FSL).
Pinecone declares its own checks, so its health is a property of the app rather than something the host guesses at.
Pinecone's Statuspage. The global components (index management, inference) decide the verdict; the per-region components are reported but capped at degraded, since this check cannot know which region your index is in.
Every index this API key can see, with its state and region. Catches the gap between 'Pinecone is up' and 'your index will answer a query' — initializing, failed, terminating.