OpenSearch Vector MCP. Run k-NN searches directly from your chat client.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
Just plug in your AI agents and start using Vinkius.
OpenSearch Vector runs k-NN vector searches directly on your OpenSearch cluster. It lets you create dedicated vector indexes, upsert embeddings with metadata, and query for conceptually similar documents using any AI agent.
What your AI agents can do
Create index
Builds a new native OpenSearch KNN index optimized for storing vector embeddings using cosine similarity.
Delete document
Removes an explicit vector document from the specified OpenSearch index.
Get index
Retrieves all mapping and settings for a specific OpenSearch index.
The agent runs k-NN queries against your indexes using a provided vector to find conceptually related documents.
You provision new native OpenSearch KNN indices, setting the required dimensions and similarity metrics for embeddings.
The agent inserts or updates a single vector document, ensuring its embedding is stored alongside its metadata.
You get a full overview of the cluster's indexes, including health status, document counts, and detailed configurations.
The agent deletes documents from an index by providing its unique ID.
Ask AI about this MCP
Supported MCP Clients
Gemini Waiting for input…
OpenSearch Vector: 6 Tools for Vector Database Management
Manage the full lifecycle of your embeddings using these tools: create, list, search, upsert, and delete documents.
019d75e9create index
Builds a new native OpenSearch KNN index optimized for storing vector embeddings using cosine similarity.
019d75e9delete document
Removes an explicit vector document from the specified OpenSearch index.
019d75e9get index
Retrieves all mapping and settings for a specific OpenSearch index.
019d75e9index document
Inserts or updates a single vector document directly into an existing KNN index in OpenSearch.
019d75e9list indexes
Lists all indexes currently residing on the entire OpenSearch cluster.
019d75e9search
Executes a k-Nearest Neighbors (k-NN) search, finding conceptually similar embeddings within an index using a dense float vector array.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with OpenSearch Vector, then connect any of our 4,700+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 4,700+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
What you can do with this MCP connector
Look, your OpenSearch cluster needs to act like a vector database if you wanna run AI stuff against it. This server handles that whole gig. It exposes tools so your agent can manage the entire lifecycle—from building out new indexes to running complex similarity searches using vectors.
When you're ready to find documents conceptually related to something, you use the search tool. You pass in a dense float vector array, and the agent executes a k-Nearest Neighbors (k-NN) query right against your index. It gives you back the top results it finds based on how similar they are to that input vector.
If you need to manage what's already built, you start with listing everything out using list_indexes. This shows every single index currently sitting on the cluster. If you want deep details on one specific index—like checking its full mapping, settings, or verifying things like its vector dimension and distance metric—you use get_index.
If an index doesn't exist yet, you gotta build it first. The create_index tool handles that; it builds a brand new native OpenSearch KNN index. You specify the required dimensions for your vectors and tell it to optimize for cosine similarity. This sets up the whole structure so embeddings can actually live there.
Once the index is built, you need data in it. If you're dealing with individual documents, you use index_document. This handles both inserting a brand new vector document and updating an existing one. You pass in the embedding and all the necessary metadata, keeping everything linked together inside the KNN index.
Cleaning up is just as important. When you need to delete a specific record from an index, you use delete_document. All it needs is the unique ID of the document to remove it cleanly from that particular vector index.
The whole process flows like this: You list all indexes with list_indexes; if one's missing or outdated, you build it using create_index; then you feed it data via index_document or update records using delete_document. Finally, when your AI client needs an answer, it runs the search query against the index to pull out those highly similar documents.
You never have to touch the underlying cluster settings yourself; the agent handles all that heavy lifting for you.
How OpenSearch Vector MCP Works
- 1 First, you subscribe to the OpenSearch Vector server and provide your cluster credentials (Host, Username, Password).
- 2 Next, you tell your AI agent what you need—for example, 'Find the top 5 documents related to X.'
- 3 The agent runs the necessary sequence of tools (
search,list_indexes, etc.) against OpenSearch and returns the structured results in plain text.
The bottom line is: you manage your entire vector store using natural language prompts, never touching cURL or a dashboard.
Who Is OpenSearch Vector MCP For?
ML engineers who hate writing API boilerplate. RAG developers building context pipelines. Data teams needing an audit trail for index health checks. If you spend time on command lines managing search indices, this is for you.
Uses create_index and index_document to build the context knowledge base that feeds your agent's answers.
Runs targeted similarity queries via search to test embedding quality against production data without writing complex API calls.
Uses list_indexes and get_index to verify index configurations, document counts, and overall cluster health status quickly.
What Changes When You Connect
- Stop writing cURL: Instead of composing complex
curlcommands to test embeddings, just ask the agent. It handles thesearchtool calls for you. - Full lifecycle control: Manage everything—creation (
create_index), updating (index_document), and deleting (delete_document)—without switching between a dashboard and a terminal. - Visibility on demand: Need to know if your index is healthy? Run
list_indexesorget_index. You get the status and dimensions instantly, right in your chat window. - Contextual retrieval for RAG: Indexing documents with
index_documentmakes them immediately available for high-accuracy retrieval via thesearchtool. - Zero setup friction: The agent manages which vector dimension (384, 768, etc.) is needed when you call
create_index, so you don't have to memorize config values.
Real-World Use Cases
ML Engineer testing embeddings
An ML engineer needs to check if a new set of 768-dimension product embeddings are correctly stored. Instead of writing a multi-step API script, they ask the agent to run list_indexes first, then use get_index on the target index name before running a sample search query.
RAG Developer building context
A developer has 10 new support articles. They need to ensure these are searchable. They ask the agent to create an index using create_index, then run index_document repeatedly for all ten documents, getting confirmation that each upsert worked.
Data Analyst checking cluster health
The data team needs a quick report on all active knowledge bases. They simply ask the agent to 'list all indexes.' The system uses list_indexes and reports back status, document count, and dimensions instantly.
Finding similar content
A user inputs a vector derived from a customer query. The agent runs the search tool against the 'knowledge-base' index, returning the top 5 most relevant documents and their similarity scores immediately.
The Tradeoffs
Running search before checking indexes
A developer assumes an index exists and runs search without knowing the exact name or if it's configured correctly. This fails because OpenSearch needs a specific index name.
→
Always run list_indexes first to confirm your target index name. Then, use get_index on that confirmed name before running any complex search query with search.
Using `search` without a vector
Trying to find related items but forgetting the required dense float vector input array for the query. The system rejects it because the core mechanism requires vector math.
→
Make sure your prompt provides the full, JSON-stringified dense float vector array as the search input when calling search.
Updating data manually
Manually calculating and inserting embeddings into a document via an unsupported method. This skips transactional integrity checks.
→
Always use index_document. It handles the upsert logic, ensuring that if you update the embedding or metadata, it happens atomically.
When It Fits, When It Doesn't
Use this server if your core problem is semantic search: finding information based on meaning (the vector) rather than just keywords. You need a dedicated vector database layer for Retrieval-Augmented Generation (RAG).
Don't use this if you only need simple key-value lookups or pure filtering (e.g., 'find all users with status=active'). For that, a standard relational or document store is faster and simpler.
Use list_indexes to map your current setup, then decide if you need to build (create_index) or just read/write data (search/index_document).
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by OpenSearch. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This server provides 6 capabilities that interface natively with Claude, ChatGPT, Cursor, and any MCP client. No middleware. No custom integration required.
Available Capabilities
Reading vector indices used to require three different dashboards.
Today, managing your search context is a headache. You have to jump between the Index Management UI to check dimensions, then run complex cURL commands in the terminal to write data, and finally go into the Search tab just to test one query. It's slow, brittle, and requires you to be an expert in OpenSearch APIs.
With the OpenSearch Vector MCP Server, all of that vanishes. You simply tell your agent: 'List my indexes.' The response comes back immediately, showing health status and dimensions. You get a single source of truth for your data context.
OpenSearch Vector MCP Server lets you run k-NN searches directly from chat.
Before this tool, running a similarity search meant manually retrieving an index name, formatting the query payload into JSON, and executing a specialized API call. A single mistake in the vector array format killed the entire request.
Now, you just talk to your agent. You ask it: 'What are the top 5 documents related to this text?' The agent runs `search` using all the right parameters automatically. It's fast, and it works.
Common Questions About OpenSearch Vector MCP
How do I list all vector indexes in my cluster using `list_indexes`? +
Run list_indexes. This tool queries the OpenSearch cluster and returns a list of every index name, along with basic metadata like document count and health status.
Can I update existing documents? What should I use instead of manual updates? +
Yes. You don't manually update them; you use index_document. This tool executes an atomic upsert, which means it writes the new vector data and replaces the old version for that specific document ID.
What is cosine similarity used for? +
Cosine similarity measures the angle between two vectors. When you use create_index with this setting, OpenSearch optimizes the index specifically to find documents whose meanings are closest together in the vector space.
How do I test a search query? Do I need to write cURL for `search`? +
No. You never need to write cURL. Just provide your dense float vector array and ask the agent to run search, specifying the target index name.
How do I properly provision a new vector index using `create_index`? +
You must specify the correct vector dimension when creating the index. This dimension (e.g., 384, 768, or 1536) needs to match the output size of your embedding model for proper functioning and optimal search performance.
What kind of metadata can I inspect on an index using `get_index`? +
The tool retrieves the full OpenSearch mapping and settings. You'll find critical details like the configured vector dimension, the distance metric used (e.g., cosine), and overall engine parameters.
How do I remove specific records from the embedding space using `delete_document`? +
You supply a unique document ID to the tool. It executes an explicit deletion of that vector record, which is necessary for data governance or removing outdated context documents.
Is my data update guaranteed when I use `index_document`? +
Yes. This tool performs a fast transactional atomic insertion into the embedding space. It guarantees that your vector document upserts directly and completely, avoiding partial writes or corruption.
What vector dimensions does it support? +
Any dimension supported by OpenSearch k-NN. Common values: 384 (MiniLM), 768 (BERT/all-mpnet), 1536 (OpenAI text-embedding-ada-002), 3072 (text-embedding-3-large). When creating an index, specify the exact dimension and the agent provisions the mapping automatically.
Can I delete an entire index or just individual documents? +
Currently, the agent supports deleting individual documents by ID from an index. Full index deletion is not exposed through this integration to prevent accidental data loss. If you need to drop an index, use the OpenSearch Dashboards or direct API calls.
Does this work with Amazon OpenSearch Service (managed)? +
Yes. Provide the Amazon OpenSearch Service endpoint as the host (e.g., https://search-xxx.us-east-1.es.amazonaws.com) along with the master username and password. The integration uses standard REST APIs that work identically on managed and self-hosted clusters.
Use it with your favorite AI tools
Connect this server to Cursor, Claude, VS Code, and more.
More in this category
Password Strength Scorer
Evaluate any password using the Dropbox zxcvbn engine — the same algorithm protecting 700M+ users. Returns a 0-4 score, real crack time estimates, and actionable improvement suggestions. No AI can do this.
Postman
Bring your Postman API lifecycle to your AI — orchestrate collections, environments, API mocks, and check workspace health seamlessly.
Hugging Face
Explore AI models, datasets and Spaces via Hugging Face — search models, inspect files, review discussions and track collections from any AI agent.
You might also like
Albacross
B2B intent and reveal intelligence — identify anonymous website visitors and manage leads via AI.
Ebby
Equip your AI agent to manage audio transcriptions, track processing status, and retrieve text via the Ebby API.
Google Play Developer
Manage your Android apps - respond to reviews and check subscriptions via AI.