vector-mcp
vector-mcp
Interfaces MCP y de agente con enrutamiento por acciones para la gestión y recuperación de colecciones vectoriales gobernadas. El valor predeterminado nativo es epistemic-graph. Los proveedores opcionales seguros cubren PostgreSQL/pgvector, Qdrant y MongoDB Atlas.
Versión: 3.1.0
Capacidad gobernada
Herramientas MCP:
vector_collection_managementyvector_searchProveedor de habilidades: el flujo de trabajo consolidado
vector-mcp-operationsProveedor de ontología: la ontología de recuperación vectorial empaquetada
Proveedor de conector de origen: un inventario de colecciones vectoriales de solo lectura preestablecido
Configuración en tiempo de ejecución: AgentConfig, variables de entorno y referencias secretas
Postura de privacidad: sin endpoints, credenciales, identidad personal ni rutas de host verificadas
Related MCP server: production-grade-mcp-agentic-system
Instalación
Use el conjunto adicional más pequeño requerido por el despliegue:
uvx --from 'vector-mcp[mcp]' vector-mcpEl tiempo de ejecución requiere agent-utilities>=2.0.0 y su contrato completo de motor epistemic-graph autocontenido. Un perfil de motor solo numérico o parcial no es un despliegue compatible.
Para un proveedor de almacenamiento seleccionado:
uv add 'vector-mcp[postgres]'
uv add 'vector-mcp[qdrant]'
uv add 'vector-mcp[mongodb]'El extra all habilita todos los proveedores opcionales compatibles, además de los tiempos de ejecución de agente, Langfuse y Logfire. Las imágenes de producción deben instalar solo los proveedores que operan.
Configuración de MCP
El paquete incluye una configuración de lanzamiento de agente neutral que contiene solo el comando, el modo de herramienta condensado y los conmutadores de herramientas. Los valores en tiempo de ejecución se heredan de AgentConfig o los inyecta el operador. Las instrucciones detalladas sobre cómo usar los envoltorios de API subyacentes, los enlaces de esquema extendidos y las referencias del SDK para desarrolladores se mantienen en docs/index.md.
MCP
Este servidor utiliza herramientas dinámicas con enrutamiento por acciones para optimizar la sobrecarga de tokens y maximizar la compatibilidad con IDE.
Herramientas MCP disponibles
Generado automáticamente desde el servidor MCP en vivo: no editar a mano.
Herramientas condensadas con enrutamiento por acciones (MCP_TOOL_MODE=condensed)
Herramienta MCP | Variable de entorno de conmutación | Descripción |
|
| Gestiona las operaciones de gestión de colecciones. |
|
| Gestiona las operaciones de búsqueda. |
2 herramienta(s) con enrutamiento por acciones · 0 herramienta(s) verbosa(s) 1:1. Cada una está habilitada a menos que su conmutador <DOMINIO>TOOL se establezca en falso; MCP_TOOL_MODE selecciona la superficie (**intent predeterminado* — las seis herramientas verbales, conjunto granular cargado bajo demanda · condensed con enrutamiento por acciones · verbose 1:1 · both). Generado automáticamente: no editar.*
Los esquemas detallados de las herramientas, las formas de los parámetros y las restricciones de validación se conservan en la guía de uso.
Selección dinámica de herramientas y visibilidad
Este servidor MCP admite la selección dinámica de conjuntos de herramientas y el filtrado de visibilidad en tiempo de ejecución. Esto le permite restringir el conjunto de herramientas expuestas para evitar saturar la ventana de contexto del LLM.
Puede configurar el filtrado de herramientas a través de múltiples canales de entrada:
Argumentos de CLI: Pase
--toolso--toolsets(o sus contrapartes deshabilitadas--disabled-toolsy--disabled-toolsets) durante el inicio.Variables de entorno: Defina variables de entorno estándar:
MCP_ENABLED_TOOLS/MCP_DISABLED_TOOLSMCP_ENABLED_TAGS/MCP_DISABLED_TAGS
Encabezados de solicitud HTTP SSE: Pase encabezados personalizados durante la inicialización del transporte:
x-mcp-enabled-tools/x-mcp-disabled-toolsx-mcp-enabled-tags/x-mcp-disabled-tags
Parámetros de consulta de solicitud HTTP SSE: Agregue parámetros de consulta directamente a la URL de conexión de su transporte:
?tools=tool1,tool2?tags=tag1
Cuando se proporcionan cadenas de consulta o parámetros, una capa de resolución de Knowledge Graph sin LLM (usando DynamicToolOrchestrator) compara las intenciones de consulta con etiquetas, nombres o descripciones de herramientas conocidas, con un respaldo seguro y un refresco automático de caché en segundo plano cada 24 horas.
Ejemplos de configuración de MCP
Instale el extra
[mcp]centrado en el conector. Los ejemplos usanvector-mcp[mcp]para agregar FastMCP / FastAPI a través deagent-utilities[mcp]; el núcleo requerido de Agent Utilities aún incluyeepistemic-graph[full]. El extra[agent-runtime]además habilita la orquestación de modelos.
Transporte stdio (IDEs locales: Cursor, Claude Desktop, VS Code)
{
"mcpServers": {
"vector-mcp": {
"command": "uvx",
"args": [
"--from",
"vector-mcp[mcp]",
"vector-mcp"
],
"env": {
"MCP_TOOL_MODE": "intent",
"COLLECTION_MANAGEMENTTOOL": "True",
"DATABASE_TYPE": "epistemic_graph",
"LLM_SSL_VERIFY": "False",
"SEARCHTOOL": "True",
"VECTOR_DB_TYPE": "epistemic_graph"
}
}
}
}Las referencias en tiempo de ejecución requieren un lanzador consciente de alias como GraphOS. Otros lanzadores deben omitir esas entradas e inyectar los valores resueltos a través de su propio límite de secretos en tiempo de ejecución.
Transporte Streamable-HTTP (red / producción)
{
"mcpServers": {
"vector-mcp": {
"command": "uvx",
"args": [
"--from",
"vector-mcp[mcp]",
"vector-mcp",
"--transport",
"streamable-http",
"--port",
"8000"
],
"env": {
"TRANSPORT": "streamable-http",
"HOST": "127.0.0.1",
"PORT": "8000",
"MCP_TOOL_MODE": "intent",
"COLLECTION_MANAGEMENTTOOL": "True",
"DATABASE_TYPE": "epistemic_graph",
"LLM_SSL_VERIFY": "False",
"SEARCHTOOL": "True",
"VECTOR_DB_TYPE": "epistemic_graph"
}
}
}
}Alternativamente, conéctese a una instancia Streamable-HTTP preimplementada mediante url:
{
"mcpServers": {
"vector-mcp": {
"url": "http://localhost:8000/vector-mcp/mcp"
}
}
}Ejecute una imagen de contenedor revisada como un hijo stdio de privilegios mínimos (sin listener ni puerto publicado):
docker run -i --rm \
--read-only \
--cap-drop=ALL \
--security-opt=no-new-privileges \
--pids-limit=256 \
--tmpfs /tmp:rw,noexec,nosuid,nodev,size=64m \
-e TRANSPORT=stdio \
-e MCP_TOOL_MODE=intent \
-e COLLECTION_MANAGEMENTTOOL=True \
-e DATABASE_TYPE=epistemic_graph \
-e LLM_SSL_VERIFY=False \
-e SEARCHTOOL=True \
-e VECTOR_DB_TYPE=epistemic_graph \
registry.example.invalid/vector-mcp@sha256:<digest> vector-mcpPara HTTP de red contenerizado, proporcione una entrada TLS autenticada (o
TLS directo del servidor), MCP_ALLOWED_HOSTS exacto y una política CIDR de proxy de confianza exacta
a través del perfil de despliegue propiedad del operador. El generador
no emite un listener no autenticado fuera de loopback.
Generado automáticamente desde la superficie de entorno de lectura de código (MCP_TOOL_MODE + variables del paquete) — no editar.
Opciones de despliegue adicionales
vector-mcp también puede ejecutarse como un contenedor local (Docker / Podman / uv) o consumirse
desde un despliegue remoto. La
guía de despliegue tiene mcp_config.json completo, listo para copiar y pegar,
para los cuatro transportes: stdio, streamable-http,
contenedor local / uv y URL remota:
Contenedor local / uv — inicie el servidor desde
mcp_config.jsonmedianteuvx,docker runopodman run, o apunte a un contenedor streamable-http local medianteurl.URL remota — conéctese a un servidor implementado detrás de Caddy en
https://vector-mcp.example.invalid/mcpusando la clave"url".
Variables de entorno
Variables de entorno del paquete
Variable | Ejemplo | Descripción |
|
| |
|
| |
|
| opciones: stdio, streamable-http, sse |
| — | |
|
| Configura AgentConfig EMBEDDING_MODELS y sus credenciales de runtime referenciadas. |
|
| URL base de la API de embedding/LLM |
| secret-injected | token bearer para el endpoint de embedding/LLM |
| secret-injected | alias aceptado si LLM_TOKEN no está definido |
|
| verificar TLS para el endpoint de embedding/LLM |
| — | Requerido solo para la ingesta de sistema de archivos. Proporcione la raíz propiedad del operador en tiempo de ejecución. |
|
| Backend utilizado cuando db_type no está especificado. El valor predeterminado es el motor nativo epistemic-graph (local, sin infraestructura, duradero). Opciones: epistemic_graph, postgres, mongodb, qdrant. DATABASE_TYPE es la variable canónica; VECTOR_DB_TYPE se acepta como alias para compatibilidad hacia atrás. |
|
| |
| — | host de postgres/qdrant |
| — | nombre de la base de datos postgres/mongodb |
|
| |
|
| |
|
| |
|
| |
|
| |
| — | lista de permitidos SSRF separada por comas para un host Qdrant privado |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
| secret-injected | |
|
|
Variables heredadas de agent-utilities (aplican a cada conector)
Variable | Ejemplo | Descripción |
|
| Superficie de herramienta: |
| — | Lista de permitidos de herramientas separada por comas |
| — | Lista de denegados de herramientas separada por comas |
| — | Lista de permitidos de etiquetas separada por comas |
| — | Lista de denegados de etiquetas separada por comas |
|
| Modo de autorización: |
|
| Archivo de política Eunomia incrustado |
| — | URL del servidor de autorización Eunomia remoto |
| — | Endpoint del recopilador OTLP |
| — | Autenticación MCP hija saliente: |
| — | ID de cliente OIDC (autenticación de cuenta de servicio) |
|
| Referencia de secreto en tiempo de ejecución para la cuenta de servicio OIDC |
| — | Nombre de usuario HTTP Basic ( |
|
| Referencia de secreto en tiempo de ejecución para autenticación HTTP Basic ( |
|
| Registro detallado |
|
| Salida estándar sin búfer (recomendado en contenedores) |
|
| URL del servidor MCP al que se conecta el agente |
|
| Proveedor de LLM para el agente |
|
| ID de modelo para el agente |
|
| Servir la interfaz web AG-UI |
31 paquete + 20 variable(s) heredadas. Generado automáticamente desde .env.example + el conjunto compartido de agent-utilities — no editar.
Cada variable que el servidor lee, agrupada por propósito. Consulte .env.example para la lista canónica de copiar y pegar, incluidos los ajustes de conexión DATABASE_TYPE / GRAPH_SERVICE_SOCKET / GRAPH_SERVICE_AUTH_SECRET para el backend epistémico-graph nativo. Los endpoints de backend, las ubicaciones de bases de datos y las credenciales para proveedores opcionales (Postgres/Qdrant/Mongo/Chroma/Couchbase) nunca son valores literales documentados en el README ni argumentos de herramientas MCP; se resuelven a través de AgentConfig y referencias secret:///env:///vault:// en tiempo de ejecución.
Servidor MCP / transporte
Variable | Descripción | Predeterminado |
|
|
|
| Host de enlace (transportes HTTP) |
|
| Puerto de enlace (transportes HTTP) |
|
| Superficie de herramienta: |
|
| Lista de permitidos/denegados de herramientas separada por comas | — |
| Lista de permitidos/denegados de etiquetas separada por comas | — |
| Salida estándar sin búfer (recomendado en contenedores) |
|
Conmutadores de herramientas
Cada herramienta enrutada por acción se puede deshabilitar individualmente mediante su variable de entorno de conmutación (establecida en false). La lista completa está en la tabla Herramientas MCP disponibles anterior.
Variable | Descripción | Predeterminado |
| Habilitar la herramienta de gestión de colecciones |
|
| Habilitar la herramienta de búsqueda |
|
Telemetría y gobernanza
Variable | Descripción | Predeterminado |
| Habilitar exportación de OpenTelemetry |
|
| Endpoint del recopilador OTLP | — |
| Claves de autenticación OTLP | — |
| Protocolo OTLP (p. ej. | — |
| Modo de autorización: |
|
| Archivo de política incrustado |
|
| URL del servidor Eunomia remoto | — |
CLI del agente (solo tiempo de ejecución [agent] completo)
Variable | Descripción | Predeterminado |
| URL del servidor MCP al que se conecta el agente |
|
| Proveedor de LLM (p. ej. |
|
| ID de modelo (p. ej. |
|
| Servir la interfaz web AG-UI |
|
Consulte .env.example para un punto de partida de copiar y pegar.
Integración de proveedor y ontología
El paquete contribuye con sus habilidades, indicaciones, ontología y conector de origen a través de puntos de entrada de Python. El conector de inventario de colecciones es intencionalmente de solo lectura y registra metadatos de colecciones, no cargas útiles de documentos o incrustaciones.
Las firmas de conector generadas deben recrearse solo después de observar el esquema MCP instalado y de que se proporcione una clave de firma de versión en tiempo de ejecución. Una firma de un esquema de herramienta u ontología anterior nunca debe copiarse hacia adelante.
Comprobaciones de desarrollo
Comprobaciones de bajo costo que no lanzan proveedores:
python scripts/security_sanitizer.py
python scripts/security_contract.py --contract .security/security-contract.json validate
python -m compileall -q vector_mcpLas pruebas de proveedores utilizan límites de SDK simulados y no realizan llamadas de red. La calificación en vivo es una puerta de despliegue separada y debe usar AgentConfig y secretos proporcionados por el operador.
Documentación
El contenedor slim :mcp streamable-http (docker/mcp.compose.yml) publica :8000 con una comprobación /health; consulte Despliegue para la definición completa del servicio compose.
Licencia
Consulte LICENSE.
Desplegar con agent-utilities-deployment
Aprovisione este paquete con el flujo de trabajo consolidado agent-utilities-deployment. Selecciona una ruta de paquete instalado, fuente editable o contenedor inmutable; registra solo referencias de secretos en tiempo de ejecución y de perfil TLS en AgentConfig; y ejecuta compuertas de doctor, registro, política, observabilidad y reversión. Pida a su agente que "despliegue vector-mcp con agent-utilities-deployment".
Modo de instalación | Comando |
Paquete instalado |
|
Fuente editable |
|
Contenedor inmutable | desplegar |
El repositorio no incrusta ningún perfil de despliegue, valor de credencial, ruta de certificado o endpoint específico del entorno. Proporcione esos en tiempo de ejecución a través de AgentConfig y el proveedor de secretos configurado.
Instalación
Elija el extra que coincida con lo que desea ejecutar:
Extra | Instala | Úselo cuando |
| Solo servidor MCP slim ( | Solo ejecuta el servidor MCP (instalación/imagen más pequeña) |
| Tiempo de ejecución completo del agente ( | Ejecuta el agente integrado |
| Todo ( | Desarrollo / ambas superficies |
# MCP server only (recommended for tool hosting — slim deps)
uv pip install "vector-mcp[mcp]"
# Full agent runtime (Pydantic AI + epistemic-graph engine)
uv pip install "vector-mcp[agent]"
# Everything (development)
uv pip install "vector-mcp[all]" # or: python -m pip install "vector-mcp[all]"Imágenes de contenedor (:mcp vs :agent)
Un docker/Dockerfile de múltiples etapas construye dos imágenes de tamaño adecuado, seleccionadas por --target:
Image tag | Build target | Contents | Entrypoint |
|
|
|
|
|
|
|
|
docker build --target mcp -t knucklessg1/vector-mcp:mcp docker/ # slim MCP server
docker build --target agent -t knucklessg1/vector-mcp:latest docker/ # full agentdocker/mcp.compose.yml ejecuta el servidor :mcp ligero; docker/agent.compose.yml ejecuta el agente (:latest) con un sidecar :mcp co-ubicado.
Base de datos de grafo de conocimiento (epistemic-graph)
El agente completo ([agent] / :latest) incorpora el motor epistemic-graph (incluido de forma transitiva a través de agent-utilities[agent]). Para producción — o para compartir un mismo grafo de conocimiento entre múltiples agentes — ejecute epistemic-graph como contenedor de base de datos propio y apunte el agente a él en lugar de incorporarlo. Las recetas de despliegue (nodo único + Raft HA), la configuración de conexión y la arquitectura completa de la base de datos (con diagramas) están documentadas en la guía de despliegue de epistemic-graph. El servidor [mcp] ligero no requiere la base de datos.
Propietarios del repositorio
Contribuir
¡Las contribuciones son bienvenidas! Por favor, asegure la calidad del código ejecutando comprobaciones locales antes de enviar pull requests:
Formatee el código con
ruff format .Ejecute el lint del código con
ruff check .Valide la seguridad de tipos con
mypy .Ejecute las suites de pruebas con
pytest
Despliegue con agent-os-genesis
Este paquete puede ser aprovisionado para usted — guiado por habilidades — por la habilidad universal agent-os-genesis (su modo de despliegue de paquete único): elige su método de instalación, siembra secretos en OpenBao/Vault (o .env), confía en su CA empresarial, registra el servidor MCP y lo verifica — la misma maquinaria que levanta todo el Agent OS, reducida a este paquete. Pida a su agente que "despliegue vector-mcp con agent-os-genesis".
Modo de instalación | Comando |
Bare-metal, producción (PyPI) |
|
Bare-metal, desarrollo (editable) |
|
Contenedor, producción | despliegue |
Contenedor, desarrollo (editable) | despliegue |
Los secretos se leen de los existentes y se siembran mediante vault_sync — solo se le solicita lo que falta.
Available Tools
2 toolsvector_collection_managementC
Manage collection management operations.
Actions:
'create_collection': Creates a new collection or retrieves an existing one in the vector database.
'add_documents': Adds documents to an existing collection in the vector database.
'delete_collection': Deletes a collection from the vector database.
'list_collections': Lists all collections in the vector database.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | host | |
| port | No | port | |
| action | Yes | Action to perform. Must be one of: 'create_collection', 'add_documents', 'delete_collection', 'list_collections' | |
| confirm | No | confirm | |
| db_name | No | db name | |
| db_path | No | db path | |
| db_type | No | db type | |
| password | No | password | |
| username | No | username | |
| overwrite | No | overwrite | |
| document_paths | No | document paths | |
| collection_name | No | collection name | |
| document_contents | No | document contents | |
| document_directory | No | document directory |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'delete_collection' as an action but does not disclose that deletion is destructive or irreversible. It also fails to mention authentication requirements, rate limits, or side effects of adding documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise bullet list of actions, front-loading the main purpose. It uses minimal wording and is easy to scan. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high parameter count (14) and no output schema provided (though context says one exists), the description lacks parameter-to-action mappings, usage examples, and behavioral context. It does not explain which parameters are relevant for each action, leaving the agent to rely solely on schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description lists actions but does not add meaning beyond the schema. Many parameter descriptions (e.g., 'db type', 'host') are vague and not enhanced by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool handles collection management operations and lists four distinct actions with clear names (create_collection, add_documents, delete_collection, list_collections). However, it doesn't explicitly distinguish this tool from its sibling 'vector_search', which may also involve collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like vector_search. The description does not specify prerequisites, contexts, or exclude scenarios, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vector_searchA
Manage search operations.
Actions:
'semantic_search': Retrieves and gathers related knowledge from the vector database instance using the question variable.
'lexical_search': This is a lexical or term based search that retrieves and gathers related knowledge from the database instance using the question variable via BM25.
'search': Performs a hybrid search combining semantic (vector) and lexical (BM25) methods.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | host | |
| port | No | port | |
| rrf_k | No | rrf k | |
| action | Yes | Action to perform. Must be one of: 'semantic_search', 'lexical_search', 'search' | |
| db_name | No | db name | |
| db_path | No | db path | |
| db_type | No | db type | |
| password | No | password | |
| question | No | question | |
| username | No | username | |
| bm25_weight | No | bm25 weight | |
| number_results | No | number results | |
| collection_name | No | collection name | |
| semantic_weight | No | semantic weight |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the three search methods but does not disclose whether the tool modifies data, requires authentication, or has rate limits. The read-only nature of search is implicit but not stated. Behavioral transparency is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a clear bullet-like listing of actions. The first sentence 'Manage search operations.' is somewhat vague but not overly wordy. Each action is described in one sentence. Minor waste could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters and three distinct actions, the description fails to provide guidance on which parameters are needed for each action (e.g., 'question' likely required for all, connection parameters for external DB). No mention of default behaviors for optional parameters like weights or RRF k. The output schema is present, so return values are covered, but parameter usage across actions is underexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but parameter descriptions in the schema are minimal (e.g., 'db type', 'host'). The tool description does not add significant meaning beyond the schema—it mentions 'question' but doesn't explain how to use connection parameters or weights. It barely adds value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages search operations and enumerates three distinct search actions: semantic_search, lexical_search, and search. It differentiates from the sibling tool vector_collection_management by focusing on search rather than collection management. The verb 'manage' is a bit generic, but the actions are specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it lists the three search methods, it offers no guidance on choosing between them or when to avoid this tool. The sibling tool's purpose is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.39.0- First observed
vector_collection_management - First observed
vector_search
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: collection management (CRUD operations on collections) and search (semantic, lexical, hybrid). There is no overlap, making it easy for an agent to select the correct tool.
All tool names follow a consistent 'vector_' prefix pattern with descriptive suffixes ('collection_management', 'search'). Internal action names are uniformly snake_case, maintaining predictability.
With only 2 tools, the server feels somewhat thin for a vector database MCP. While each tool bundles multiple actions, a few more tools (e.g., separate tools for document operations) would improve organization.
The server lacks essential operations such as updating or deleting documents, retrieving collection details, or managing metadata. These gaps would likely cause agent failures in typical workflows.
Maintenance
Related MCP Connectors
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Related MCP Servers
- -licenseNot gradedqualityNot gradedmaintenanceA sophisticated MCP server providing advanced memory capabilities with RAG, hallucination detection, and enterprise-grade AI infrastructure for intelligent agent ecosystems.-
- AlicenseNot gradedqualityDmaintenanceA production-grade MCP server designed for multi-tenant, authenticated, and observable AI agent systems, enabling secure tool execution across heterogeneous data sources.66MIT
- FlicenseNot gradedqualityDmaintenanceAn enterprise-ready MCP server that exposes a RAG tool for retrieving relevant context and metadata from a Qdrant vector database using natural language queries.2-
- AlicenseNot gradedqualityDmaintenanceIntegrates RAG into AI agents via MCP Server, supporting multiple vector database technologies for collection management and search operations.11MIT