vector-mcp
This server provides an MCP interface for managing and searching vector databases, enabling Retrieval-Augmented Generation (RAG) in AI agents.
Collection Management
Create, list, and delete collections
Add documents via file paths, directories, or raw content
Search
Semantic search — vector/embedding-based similarity search
Lexical search — term-based BM25 search
Hybrid search — combines both with configurable weights (RRF ranking)
Supported Backends: Couchbase, MongoDB, PostgreSQL, Qdrant
Advanced Features
Enterprise security: Eunomia policies, OIDC token delegation, Tool Guard, Prompt Injection Defense, and Context Safety Guard
Telemetry: OpenTelemetry and Langfuse exports
Integrated Pydantic AI agent with Agent Control Protocol (ACP) and AG-UI web interface support
Dynamic/consolidated Action-Routed MCP tools to minimize token overhead and maximize IDE compatibility
Allows interacting with Couchbase as a vector database, enabling collection management (create, delete, list) and document operations (add, search via semantic, lexical, or hybrid methods).
Allows interacting with MongoDB as a vector database, enabling collection management (create, delete, list) and document operations (add, search via semantic, lexical, or hybrid methods).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@vector-mcpsearch for 'climate change' in my vector database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
vector-mcp
Action-routed MCP and agent interfaces for governed vector collection management and retrieval. The native default is epistemic-graph. Secure opt-in providers cover PostgreSQL/pgvector, Qdrant, and MongoDB Atlas.
Version: 3.1.0
Governed capability
MCP tools:
vector_collection_managementandvector_searchSkill provider: the consolidated
vector-mcp-operationsworkflowOntology provider: the packaged vector retrieval ontology
Source connector provider: a read-only vector collection inventory preset
Runtime configuration: AgentConfig, environment variables, and secret references
Privacy posture: no checked-in endpoints, credentials, personal identity, or host paths
Related MCP server: production-grade-mcp-agentic-system
Install
Use the smallest extra set required by the deployment:
uvx --from 'vector-mcp[mcp]' vector-mcpThe runtime requires agent-utilities>=2.0.0 and its self-contained full
epistemic-graph engine contract. A bare numeric-only or partial engine profile is not a
supported deployment.
For a selected storage provider:
uv add 'vector-mcp[postgres]'
uv add 'vector-mcp[qdrant]'
uv add 'vector-mcp[mongodb]'The all extra enables every supported optional provider plus the agent, Langfuse, and
Logfire runtimes. Production images should install only the providers they operate.
MCP configuration
The package includes a neutral agent-launch configuration containing only the command, condensed tool mode, and tool toggles. Runtime values are inherited from AgentConfig or injected by the operator. Detailed instructions on how to use the underlying API wrappers, extended schema bindings, and developer SDK references are maintained in docs/index.md.
MCP
This server utilizes dynamic Action-Routed tools to optimize token overhead and maximize IDE compatibility.
Available MCP Tools
Auto-generated from the live MCP server — do not edit by hand.
Condensed action-routed tools (MCP_TOOL_MODE=condensed)
MCP Tool | Toggle Env Var | Description |
|
| Manage collection management operations. |
|
| Manage search operations. |
2 action-routed tool(s) · 0 verbose 1:1 tool(s). Each is enabled unless its <DOMAIN>TOOL toggle is set false; MCP_TOOL_MODE selects the surface (intent default — the six verb-tools, granular set loaded on demand · condensed action-routed · verbose 1:1 · both). Auto-generated — do not edit.
Detailed tool schemas, parameter shapes, and validation constraints are preserved in the usage guide.
Dynamic Tool Selection & Visibility
This MCP server supports dynamic toolset selection and visibility filtering at runtime. This allows you to restrict the set of exposed tools in order to prevent blowing up the LLM's context window.
You can configure tool filtering via multiple input channels:
CLI Arguments: Pass
--toolsor--toolsets(or their disabled counterparts--disabled-toolsand--disabled-toolsets) during startup.Environment Variables: Define standard environment variables:
MCP_ENABLED_TOOLS/MCP_DISABLED_TOOLSMCP_ENABLED_TAGS/MCP_DISABLED_TAGS
HTTP SSE Request Headers: Pass custom headers during transport initialization:
x-mcp-enabled-tools/x-mcp-disabled-toolsx-mcp-enabled-tags/x-mcp-disabled-tags
HTTP SSE Request Query Parameters: Append query parameters directly to your transport connection URL:
?tools=tool1,tool2?tags=tag1
When query strings or parameters are supplied, an LLM-free Knowledge Graph resolution layer (using DynamicToolOrchestrator) matches query intents against known tool tags, names, or descriptions, with safe fallback and automated 24-hour background cache refreshing.
MCP Configuration Examples
Install the connector-focused
[mcp]extra. Examples usevector-mcp[mcp]to add FastMCP / FastAPI throughagent-utilities[mcp]; the required Agent Utilities core still carriesepistemic-graph[full]. The[agent-runtime]extra additionally enables model orchestration.
stdio Transport (local IDEs — 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"
}
}
}
}Runtime references require an alias-aware launcher such as GraphOS. Other launchers must omit those entries and inject the resolved values through their own runtime secret boundary.
Streamable-HTTP Transport (networked / production)
{
"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"
}
}
}
}Alternatively, connect to a pre-deployed Streamable-HTTP instance by url:
{
"mcpServers": {
"vector-mcp": {
"url": "http://localhost:8000/vector-mcp/mcp"
}
}
}Run a reviewed container image as a least-privilege stdio child (no listener or published port):
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-mcpFor containerized network HTTP, supply an authenticated TLS ingress (or
direct server TLS), exact MCP_ALLOWED_HOSTS, and an exact trusted-proxy
CIDR policy through the operator-owned deployment profile. The generator
does not emit an unauthenticated non-loopback listener.
Auto-generated from the code-read env surface (MCP_TOOL_MODE + package vars) — do not edit.
Additional Deployment Options
vector-mcp can also run as a local container (Docker / Podman / uv) or be
consumed from a remote deployment. The
Deployment guide has full, copy-paste
mcp_config.json for all four transports — stdio, streamable-http,
local container / uv, and remote URL:
Local container / uv — launch the server from
mcp_config.jsonviauvx,docker run, orpodman run, or point at a local streamable-http container byurl.Remote URL — connect to a server deployed behind Caddy at
https://vector-mcp.example.invalid/mcpusing the"url"key.
Environment Variables
Package environment variables
Variable | Example | Description |
|
| |
|
| |
|
| options: stdio, streamable-http, sse |
| — | |
|
| Configure AgentConfig EMBEDDING_MODELS and its referenced runtime credentials. |
|
| embedding/LLM API base url |
| secret-injected | bearer token for the embedding/LLM endpoint |
| secret-injected | alias accepted if LLM_TOKEN is unset |
|
| verify TLS for the embedding/LLM endpoint |
| — | Required only for filesystem ingestion. Supply the operator-owned root at runtime. |
|
| Backend used when db_type is unspecified. Default is the native epistemic-graph engine (local, zero-infra, durable). Options: epistemic_graph, postgres, mongodb, qdrant. DATABASE_TYPE is the canonical variable; VECTOR_DB_TYPE is accepted as an alias for backward compatibility. |
|
| |
| — | postgres/qdrant host |
| — | postgres/mongodb database name |
|
| |
|
| |
|
| |
|
| |
|
| |
| — | comma-separated SSRF allowlist for a private Qdrant host |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
| secret-injected | |
|
|
Inherited agent-utilities variables (apply to every connector)
Variable | Example | Description |
|
| Tool surface: |
| — | Comma-separated tool allow-list |
| — | Comma-separated tool deny-list |
| — | Comma-separated tag allow-list |
| — | Comma-separated tag deny-list |
|
| Authorization mode: |
|
| Embedded Eunomia policy file |
| — | Remote Eunomia authorization server URL |
| — | OTLP collector endpoint |
| — | Outbound MCP child auth: |
| — | OIDC client id (service-account auth) |
|
| Runtime secret reference for the OIDC service account |
| — | HTTP Basic username ( |
|
| Runtime secret reference for HTTP Basic auth ( |
|
| Verbose logging |
|
| Unbuffered stdout (recommended in containers) |
|
| URL of the MCP server the agent connects to |
|
| LLM provider for the agent |
|
| Model id for the agent |
|
| Serve the AG-UI web interface |
31 package + 20 inherited variable(s). Auto-generated from .env.example + the shared agent-utilities set — do not edit.
Every variable the server reads, grouped by purpose. See .env.example for the
canonical, copy-paste list — including the DATABASE_TYPE / GRAPH_SERVICE_SOCKET /
GRAPH_SERVICE_AUTH_SECRET connection settings for the native epistemic-graph backend. Backend
endpoints, database locations, and credentials for opt-in providers (Postgres/Qdrant/Mongo/
Chroma/Couchbase) are never README-documented literal values or MCP tool arguments — they resolve
through AgentConfig and secret:///env:///vault:// references at runtime.
MCP server / transport
Variable | Description | Default |
|
|
|
| Bind host (HTTP transports) |
|
| Bind port (HTTP transports) |
|
| Tool surface: |
|
| Comma-separated tool allow/deny list | — |
| Comma-separated tag allow/deny list | — |
| Unbuffered stdout (recommended in containers) |
|
Tool toggles
Each action-routed tool can be disabled individually via its toggle env var (set to false).
The full list is in the Available MCP Tools table above.
Variable | Description | Default |
| Enable the collection-management tool |
|
| Enable the search tool |
|
Telemetry & governance
Variable | Description | Default |
| Enable OpenTelemetry export |
|
| OTLP collector endpoint | — |
| OTLP auth keys | — |
| OTLP protocol (e.g. | — |
| Authorization mode: |
|
| Embedded policy file |
|
| Remote Eunomia server URL | — |
Agent CLI (full [agent] runtime only)
Variable | Description | Default |
| URL of the MCP server the agent connects to |
|
| LLM provider (e.g. |
|
| Model id (e.g. |
|
| Serve the AG-UI web interface |
|
See .env.example for a copy-paste starting point.
Provider and ontology integration
The package contributes its skills, prompts, ontology, and source connector through Python entry points. The collection-inventory connector is intentionally read-only and registers collection metadata, not document or embedding payloads.
Generated connector signatures must be recreated only after the installed MCP schema is observed and a release signing key is provided at runtime. A signature from an older tool schema or ontology must never be copied forward.
Development checks
Low-cost checks that do not launch providers:
python scripts/security_sanitizer.py
python scripts/security_contract.py --contract .security/security-contract.json validate
python -m compileall -q vector_mcpProvider tests use mocked SDK boundaries and make no network calls. Live qualification is a separate deployment gate and must use operator-supplied AgentConfig and secrets.
Documentation
The slim :mcp streamable-http container (docker/mcp.compose.yml) publishes :8000 with a
/health check; see Deployment for the full compose service definition.
License
See LICENSE.
Deploy with agent-utilities-deployment
Provision this package with the consolidated agent-utilities-deployment
workflow. It selects an installed-package, editable-source, or immutable-container
path; records only runtime secret and TLS-profile references in AgentConfig; and
runs doctor, registration, policy, observability, and rollback gates. Ask your agent
to "deploy vector-mcp with agent-utilities-deployment".
Install mode | Command |
Installed package |
|
Editable source |
|
Immutable container | deploy |
The repository embeds no deployment profile, credential value, certificate path, or
environment-specific endpoint. Supply those at runtime through AgentConfig and the
configured secret provider.
Installation
Pick the extra that matches what you want to run:
Extra | Installs | Use when |
| Slim MCP server only ( | You only run the MCP server (smallest install / image) |
| Full agent runtime ( | You run the integrated agent |
| Everything ( | Development / both surfaces |
# 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]"Container images (:mcp vs :agent)
One multi-stage docker/Dockerfile builds two right-sized images, selected by --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 runs the slim :mcp server; docker/agent.compose.yml runs the
agent (:latest) with a co-located :mcp sidecar.
Knowledge-graph database (epistemic-graph)
The full agent ([agent] / :latest) embeds the epistemic-graph engine (pulled in
transitively via agent-utilities[agent]). For production — or to share one knowledge graph
across multiple agents — run epistemic-graph as its own database container and point the
agent at it instead of embedding it. Deployment recipes (single-node + Raft HA), connection
config, and the full database architecture (with diagrams) are documented in the
epistemic-graph deployment guide.
The slim [mcp] server does not require the database.
Repository Owners
Contribute
Contributions are welcome! Please ensure code quality by executing local checks before submitting pull requests:
Format code using
ruff format .Lint code using
ruff check .Validate type-safety with
mypy .Execute test suites using
pytest
Deploy with agent-os-genesis
This package can be provisioned for you — skill-guided — by the agent-os-genesis
universal skill (its single-package deploy mode): it picks your install method, seeds
secrets to OpenBao/Vault (or .env), trusts your enterprise CA, registers the MCP
server, and verifies it — the same machinery that stands up the whole Agent OS, narrowed
to just this package. Ask your agent to "deploy vector-mcp with agent-os-genesis".
Install mode | Command |
Bare-metal, prod (PyPI) |
|
Bare-metal, dev (editable) |
|
Container, prod | deploy |
Container, dev (editable) | deploy |
Secrets are read-existing + seeded via vault_sync — you are only prompted for what's missing.
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.
TDQS
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
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
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 AI agents to plan, verify, and deploy Cloudflare-native apps.
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.62MIT
- 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 gradedqualityBmaintenanceIntegrates RAG into AI agents via MCP Server, supporting multiple vector database technologies for collection management and search operations.11MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Knuckles-Team/vector-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server