Vector Toolbox MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VTB_READ_ONLY | No | Set to 'true' to disable all write tools and operate in read-only mode. | false |
| VTB_EMBED_MODEL | No | Default embedding model name, used when tools do not specify an embed model. | |
| PINECONE_API_KEY | Yes | Your Pinecone API key, required to connect to Pinecone. | |
| VTB_EMBED_PROVIDER | No | Default embedding provider (e.g., 'pinecone', 'openai', 'cohere', 'huggingface'). Used when tools do not specify an embed provider. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pinecone_create_indexA | Create a Pinecone index by declaring its searchable fields. The schema decides which searches the index can ever answer, and it cannot be changed afterwards - so decide up front:
Recipes matching the five common setups:
Limits enforced before the call is sent: at most one dense_vector
field and at most one sparse_vector field per index, up to 100
full-text string fields. Field names must be unique, at most 64 bytes,
and must not start with Only searchable fields go in the schema. Ordinary metadata is indexed for filtering automatically the first time it appears on a record; declaring it here is rejected by the API. Args:
name: 1-45 chars, lowercase alphanumerics and hyphens.
pod: Pod deployment instead of managed serverless, e.g.
|
| pinecone_create_index_for_modelB | Create an index with a hosted embedding model attached. Pinecone embeds Args:
model: Hosted model, e.g. "llama-text-embed-v2",
"multilingual-e5-large", "pinecone-sparse-english-v0".
text_field: Record field holding the raw text to embed.
filterable_fields: e.g. |
| pinecone_list_indexesB | List every index in the project, with the search modes each supports. |
| pinecone_describe_indexA | Full server-side description of one index: schema, deployment, status, host. |
| pinecone_index_capabilitiesA | Report which searches an index can answer, and with which fields. Call this before searching an index you did not create in this session.
It names the dense / sparse / full-text fields, the dimension each
dense field expects, and the list of valid |
| pinecone_configure_indexA | Change an index's deletion protection, tags or read capacity. The field schema is immutable - a new signal (a sparse field, an FTS field) means creating a new index and reindexing. |
| pinecone_delete_indexA | Delete an index and everything in it. Requires |
| pinecone_list_namespacesB | List the namespaces in an index, with record counts where available. |
| pinecone_describe_namespaceC | Describe one namespace: record count and metadata. |
| pinecone_create_namespaceB | Create an empty namespace. Upserting to a new namespace also creates it. |
| pinecone_delete_namespaceB | Delete a namespace and every record in it. Requires |
| pinecone_sample_metadataA | Sample records from a namespace and describe the metadata shape. Returns each field observed, its types, how many of the sampled records carried it, and up to three example values - enough to write a correct filter without dumping the namespace into the conversation. |
| pinecone_describe_index_statsC | Record counts, dimension and per-namespace breakdown for an index. |
| pinecone_upsert_documentsA | Upsert records, optionally embedding them on the way in. Each document needs a unique Embedding is plug-and-play. Pass Validated before sending, because Pinecone fails an entire upsert if
any one document is invalid: each document needs a unique TTL is implemented by this server, not by Pinecone: Args:
documents: e.g. |
| pinecone_upsert_vectorsA | Upsert through the legacy Vectors API - raw values plus metadata. Use this for single-vector indexes where you want a dense and a sparse
vector on the same record, which is what makes the one-request hybrid
query in Args:
vectors: |
| pinecone_update_documentsB | Partially update documents - by id, or by filter across many at once. Args:
documents: Per-record updates, each with |
| pinecone_update_vectorC | Update one record's vector values or metadata via the Vectors API. |
| pinecone_delete_recordsB | Delete records by id, by metadata filter, or clear a namespace.
|
| pinecone_purge_expiredA | Permanently delete records whose TTL has lapsed. Requires Searches already hide expired records; this is what actually frees the storage. Run it on a schedule if you rely on TTL. |
| pinecone_fetch_recordsB | Fetch records by id or filter, without ranking them.
|
| pinecone_list_record_idsC | List record ids in a namespace, optionally filtered by id prefix. |
| pinecone_searchA | Search an index, validating the request against its schema first. Modes, and what each needs from the schema:
Records whose TTL has lapsed are excluded by default; records written without a TTL are never hidden. |
| pinecone_search_recordsA | Search an integrated-inference index - Pinecone embeds the query. Only for indexes created with
|
| pinecone_query_vectorsA | Vectors API query - the true single-request dense+sparse hybrid. On a single-vector index holding both a dense and a sparse vector per
record, passing both here has Pinecone do the hybrid scoring server
side, rather than the client-side fusion Pass |
| pinecone_rerankA | Rerank a candidate list with a hosted cross-encoder. Use it as a second stage: retrieve widely with Args:
documents: |
| pinecone_embedC | Generate embeddings without storing them - useful for dimension checks. |
| pinecone_list_modelsC | List the hosted embedding and reranking models Pinecone offers. |
| vectortoolbox_statusA | Report configuration: backends, default embedding provider, read-only mode. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 28 tools
Several overlapping clusters exist: pinecone_search, pinecone_search_records, and pinecone_query_vectors all perform retrieval, and pinecone_describe_namespace, pinecone_describe_index_stats, pinecone_describe_index, and pinecone_index_capabilities have partially overlapping reporting purposes. The very detailed descriptions do help an agent choose correctly, but the boundaries between the search tools and the describe tools are not immediately obvious from the names alone.
Nearly all tools follow a consistent pinecone_verb_noun pattern (pinecone_create_index, pinecone_delete_records, pinecone_list_namespaces). The exceptions are pinecone_index_capabilities (noun phrase, no verb) and vectortoolbox_status (different prefix and concatenated without a separating underscore), which are minor deviations rather than a broken convention.
At 28 tools this is heavy for a single MCP server and sits above the comfortable 3-15 range. Most tools do earn their place given the breadth of the vector-DB admin surface (index, namespace, record, search, embedding, rerank), but the count is borderline and a few describe/capabilities tools could plausibly be merged.
Coverage is thorough: index lifecycle (create, create_for_model, list, describe, capabilities, configure, delete), namespace lifecycle, record CRUD (upsert documents/vectors, update, fetch, list ids, delete, purge expired), multiple search modes, embeddings, rerank, model listing, and server status. No obvious gaps for the stated vector-toolbox purpose.