Skip to main content
Glama
pinecone-io

Pinecone Developer MCP

Official
by pinecone-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search Document Index

search-document-index
Read-only

Search a Pinecone document index by semantic meaning, sparse embeddings, keyword relevance, or Lucene-style queries to retrieve ranked matching documents and selected fields.

Instructions

Search a Pinecone document index (one created with create-document-index). Call describe-index first to see which fields declare "embed", "sparseEmbed", or "fullTextSearch". Rank with one or more "scoreBy" clauses:

  • "embed": search by meaning on a field with "embed". Pass the query as plain text; Pinecone embeds it with the field's model.

  • "sparse_embed": search a field with "sparseEmbed" the same way.

  • "text": keyword (BM25) search on one or more full-text fields. Good for exact terms like IDs, error codes, and names.

  • "query_string": Lucene-style query syntax. Don't pass "fields" (the API rejects it); target fields with qualifiers inside the query, for example 'chunk_text:"exact phrase"', or omit qualifiers to search every full-text field. An "embed" or "sparse_embed" clause must be the only clause; "text" and "query_string" clauses can be combined. To rank by meaning and by exact terms, run two separate searches: their scores are on different scales, so don't compare them across searches. Returns matches with "_id", "_score", and the fields named in "includeFields". Newly upserted records can take a few seconds to be indexed and become visible to search results and index stats; if recent data is missing, wait briefly and retry.

Input Schema

NameRequiredDescriptionDefault
nameYesThe index to search.
topKNoThe number of matches to return. Defaults to 10.
filterNoAn optional filter, such as {"category": {"$eq": "policy"}}. On a full-text field, "$match_phrase", "$match_all", and "$match_any" require terms, for example {"chunk_text": {"$match_all": "refund"}}.
scoreByYesThe clauses that rank the documents.
llm_modelNoOptional. If you are an AI model, use this field to specify your name (e.g., "gpt-4o", "Composer", "Claude Sonnet 4", "Claude Opus", "Gemini 2.5", "Cascade", "Grok 4.1", "Copilot", "Devin", and many others). The exact formatting of the name doesn't matter - approximate values are fine if you know roughly what you are. Include the version number in your model name only if you know it, but it is okay to leave it out if unsure. If you don't know your model name, omit this field entirely. **Do not prompt the user for this.** This value is used to track usage analytics.
namespaceNoThe namespace to search. Defaults to "__default__".__default__
llm_providerNoOptional. If you are an AI model, use this field to indicate the name of the company that trained you (e.g., "Anthropic", "OpenAI", "Google", "Cursor", "xAI", "GitHub", "Windsurf", "Cognitioni AI", and many others). The exact formatting doesn't matter - approximate values are fine. If you don't know your provider, avoid guessing and omit this field. **Do not prompt the user for this.** This value is used to track usage analytics.
includeFieldsNoThe fields to return with each match. Defaults to ["*"] (all stored fields).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses non-obvious behavior: embed/sparse_embed clauses must be the only clause, query_string rejects 'fields', scores from different clauses are on incomparable scales, and newly upserted records are delayed in indexing. It also states the return shape (_id, _score, includeFields).

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 the core action, then organized as a bulleted breakdown of clause types followed by a constraints/returns note. Every sentence carries information, though the bullet list makes it longer than strictly necessary and the clause-validity rules appear after the type definitions rather than before.

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?

For an 8-parameter tool with nested scoreBy objects and no output schema, the description covers the hard parts: clause composition rules, query_string field handling, and return fields. It does not mention the analytics-only llm_model/llm_provider parameters, though the schema documents them adequately.

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

Parameters5/5

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

Even with 100% schema coverage, the description adds real semantic meaning: it explains what each scoreBy type actually does (Pinecone embeds plain text via the field's model, BM25 keyword scoring, Lucene-style syntax with inline field qualifiers). It also ties includeFields to the returned match objects rather than just restating the schema.

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

Purpose5/5

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

States a specific verb and resource ('Search a Pinecone document index') and immediately scopes it to indexes created with create-document-index, which separates it from sibling tools like search-records and search-docs. The prerequisite pointer to describe-index further pins down the exact object being operated on.

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

Usage Guidelines4/5

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

Gives clear conditional guidance: call describe-index first, use 'text' for exact terms like IDs and error codes, use two separate searches when combining semantic and keyword ranking, and wait/retry for recently upserted data. It never explicitly contrasts itself with siblings such as cascading-search or rerank-documents, so the when-not guidance is incomplete.

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

Deploy Server

Other Tools