Skip to main content
Glama

pinecone_upsert_documents

Insert or update documents in a Pinecone index, embedding text on the way in and validating each record so your upsert never fails as a whole.

Instructions

Upsert records, optionally embedding them on the way in.

Each document needs a unique _id. Fields declared in the index schema are searched; every other field is stored and indexed for filtering automatically.

Embedding is plug-and-play. Pass embed_source_field naming the text field to embed and the toolbox fills every dense and sparse field the schema declares, using embed_provider/embed_model (defaults come from VTB_EMBED_PROVIDER / VTB_EMBED_MODEL). A document that already carries a vector for a field is left alone, so you can mix pre-computed and generated vectors in one call. The vector width is checked against the schema before anything is sent.

Validated before sending, because Pinecone fails an entire upsert if any one document is invalid: each document needs a unique _id and at least one schema field (a metadata-only document is rejected), and no field name may start with _ or $. Requests are split at 1000 documents.

TTL is implemented by this server, not by Pinecone: ttl_seconds stamps a vtb_expires_at epoch on each record, searches exclude lapsed records by default, and pinecone_purge_expired reclaims the storage. Records written without a TTL carry no extra field and are never hidden by that filter.

Args: documents: e.g. [{"_id": "d1", "body": "...", "category": "tech", "year": 2026}]. embed_source_field: Field whose text becomes the vector(s). dense_field / sparse_field: Target schema fields when the index declares more than one. ttl_seconds: Lifetime in seconds. Omit for no expiry. batch_size: Documents per request when batching.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYes
documentsYes
namespaceYes
batch_sizeNo
dense_fieldNo
embed_modelNo
ttl_secondsNo
sparse_fieldNo
sparse_modelNo
embed_providerNo
embed_dimensionNo
sparse_providerNo
embed_source_fieldNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden and does so richly: server-side TTL semantics with the vtb_expires_at stamp, automatic embedding fill with provider/model env defaults, per-document validation before sending, the 1000-document split, and vector-width pre-checks. This is exactly the beyond-schema behavior an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and mechanics, then structured Args. It is dense but mostly earns its length; the 'unique _id' requirement is stated twice (prose and Args), a minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the description covers validation, embedding, TTL, and batching well. It falls short only on index/namespace requirements for a mutation tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 13 params, so the description must compensate. It documents documents, embed_source_field, dense_field/sparse_field, ttl_seconds, batch_size, and touches embed_provider/embed_model defaults, but leaves index, namespace, embed_dimension, sparse_model, and sparse_provider unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (upsert) and resource (documents/records) and clarifies the embedding option in the opening line. It implicitly distinguishes itself from pinecone_upsert_vectors by operating on documents, but never explicitly names a sibling to route between them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through detailed mechanics (when a vector is present, when TTL is set) rather than explicit when-to-use/when-not guidance. An agent must infer that this is for full records rather than raw vectors, and no alternative tool is named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.