Vector Toolbox MCP

pinecone_search

Search vector indexes using text, semantic, sparse, or hybrid queries, with schema validation and metadata filters before ranking.

Instructions

Search an index, validating the request against its schema first.

Modes, and what each needs from the schema:

text - BM25. A text clause names exactly one field, so scoring across several fields sends one clause per field in a single request and Pinecone combines them with equal weight (there is no per-clause weight). Pass fields to choose them, or omit it to use every FTS field. field_queries gives each field its own query text, e.g. {"body": "disappointing", "summary": "Disappointing"}.
query_string - Lucene syntax, which targets fields inside the query itself: title:(quantum) OR body:(machine AND learning). Supports AND/OR/NOT, +/-, grouping, phrases "...", phrase slop "..."~2, boosting term^2, phrase prefix "mach lear"* and regex body:/mach.*/. Fuzzy matching (~1 on a single term) is not supported.
dense - semantic search. query is embedded with the configured provider unless you pass vector yourself.
sparse - learned lexical search over a sparse vector field.
hybrid - every signal the index has, run separately and fused client-side. A dense or sparse clause must be the only clause in its request, so this is one request per signal merged with Reciprocal Rank Fusion (fusion="weighted" plus weights={"dense": 2, "text": 1} to bias one signal).
auto - the richest mode the index supports.

filter narrows candidates before ranking and is deterministic, not a scoring signal. Metadata operators: $eq $ne $gt $gte $lt $lte $in $nin $exists $and $or $not. On FTS-enabled string fields you also get $match_phrase, $match_all and $match_any (at most 128 tokens each) - which is how you rank by vector while requiring an exact term.

include_fields defaults to every stored field. Pass a narrower list to keep responses small, or [] for ids and scores only. top_k may be 1-10000.

Records whose TTL has lapsed are excluded by default; records written without a TTL are never hidden.

Input Schema

TableJSON Schema

Name	Required	Default
`mode`	No	auto
`index`	Yes
`query`	No
`top_k`	No
`fields`	No
`filter`	No
`fusion`	No	rrf
`vector`	No
`weights`	No
`namespace`	Yes
`dense_field`	No
`embed_model`	No
`sparse_field`	No
`sparse_model`	No
`field_queries`	No
`sparse_vector`	No
`embed_provider`	No
`include_fields`	No
`embed_dimension`	No
`exclude_expired`	No
`sparse_provider`	No
`candidate_multiplier`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does so well: it states that filter is deterministic pre-ranking rather than a scoring signal, that TTL-expired records are excluded by default while records without TTL are never hidden, the top_k bounds (1-10000), the include_fields default, and that invalid requests are validated against the schema first. It does not cover error behavior or result ordering beyond fusion details, keeping it short of a 5.

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?

Long but front-loaded and tightly organized: purpose first, then a mode-by-mode breakdown, then filtering, then output sizing. Nearly every sentence carries operational detail with little filler, though the density borders on documentation rather than a tool description.

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

Completeness3/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 does address TTL, filtering, sizing, and mode selection. Still, for a 22-parameter tool with zero schema-level documentation, the undocumented embedding and sparse-vector parameters leave real gaps an agent cannot resolve from the definition alone.

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% across 22 parameters, so the description must compensate and only partially does: it explains mode, fields, field_queries, filter operators, include_fields, top_k, fusion, weights, vector, and exclude_expired. Many parameters (index, namespace, dense_field, embed_model/provider/dimension, sparse_field/model/provider, sparse_vector, candidate_multiplier) receive no semantic explanation anywhere.

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 and resource ('Search an index') and then enumerates the search modes it supports, which tells an agent what capability it covers. However, it never distinguishes itself from close siblings such as pinecone_search_records or pinecone_query_vectors, which appear to overlap heavily with the dense/sparse/hybrid modes described here.

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?

The description gives rich *intra-tool* routing guidance (when to choose text vs query_string vs dense vs hybrid, and that 'auto' picks the richest supported mode), which is genuinely useful. But it offers no guidance on when to call this tool at all versus the sibling search/query/rerank/embed tools, so alternative selection is left to inference.

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