Supavec MCP Server
Supavec MCP サーバー
Supavec から関連コンテンツを取得します。
Supavec用のMCP (モデルコンテキストプロトコル)サーバーの公式実装。
ツール
fetch-embeddings: Supavec から関連する埋め込みとコンテンツを取得します
Related MCP server: SourceSync.ai MCP Server
使用法
構築する
常に依存関係をインストールして最初にビルドします。
npm run install && npm run buildSupavec APIキーを取得する
Supavecにサインアップして API キーを取得します。
デスクトップ版Claude
~/Library/Application\ Support/Claude/claude_desktop_config.jsonに以下を追加します。
{
"mcpServers": {
"supavec": {
"command": "node",
"args": ["path/to/supavec/mcp/build/index.js"],
"env": {
"SUPAVEC_API_KEY": "<your api key>"
}
}
}
}スタンドアロンまたは他のプロジェクト用
SUPAVEC_API_KEY=your_api_key && node build/index.jsライセンス
Supavec MCP Server MIT ライセンスに基づいてライセンスされます。
Available Tools
2 toolsfetch-embeddingsC
Fetch embeddings for a file by ID and query
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ID of the file to get embeddings for | |
| query | Yes | Query to search for in the file |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool fetches embeddings but doesn't describe what 'embeddings' are in this context, how they are returned, any rate limits, authentication needs, or potential side effects. This leaves significant gaps for an AI agent to understand the tool's behavior.
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 single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for the tool's complexity.
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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'embeddings' are, how they are structured, or what the return values look like, which is crucial for a tool with undefined outputs and behavioral traits. The description should provide more context to compensate for the lack of structured data.
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?
The schema description coverage is 100%, with clear descriptions for both parameters ('file_id' and 'query'), so the schema does the heavy lifting. The description adds no additional meaning beyond what the schema provides, such as format details or usage examples, but this is acceptable given the high schema coverage.
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 action ('fetch embeddings') and the target resource ('for a file by ID and query'), which is specific and unambiguous. However, it doesn't explicitly differentiate from the sibling tool 'list-user-files', which appears to list files rather than fetch embeddings, so it misses full sibling distinction.
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 provides no guidance on when to use this tool versus alternatives, such as the sibling 'list-user-files', or any context about prerequisites, scenarios, or exclusions. It merely restates the basic functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-user-filesB
List all files uploaded to Supavec for the current user
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of files to fetch (default: 10) | |
| offset | No | Offset for pagination (default: 0) | |
| order_dir | No | Order direction for results | desc |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation but doesn't mention whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. The description is minimal and lacks important behavioral context for a tool that presumably accesses user data.
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 single, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a simple list operation and gets straight to the point.
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?
For a list operation with 3 well-documented parameters and no output schema, the description provides the basic purpose but lacks important context. Without annotations, it should ideally mention authentication requirements, return format, or pagination behavior. The description is adequate but has clear gaps given the tool's data access nature.
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?
The schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description doesn't add any parameter information beyond what's already in the schema, so it meets the baseline for high schema coverage without adding extra value.
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 action ('List all files') and resource ('uploaded to Supavec for the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'fetch-embeddings', which appears to be a different operation rather than a direct alternative for listing files.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'fetch-embeddings' or any other context for selection. The only implied usage is for listing user files, but there's no explicit when/when-not guidance.
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.0.0- First observed
fetch-embeddings - First observed
list-user-files
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one fetches embeddings for a specific file, while the other lists all user files. There is no overlap or ambiguity between these operations, making it clear when to use each tool.
Both tools use a verb_noun pattern (fetch-embeddings, list-user-files), which is consistent and readable. The minor deviation is the use of hyphens instead of underscores, but this is a consistent stylistic choice across both tools.
With only 2 tools, the server feels thin for a Supavec MCP Server, which likely involves file and embedding management. Key operations like uploading files, deleting files, or managing embeddings beyond fetching are missing, making the scope incomplete.
The toolset is severely incomplete for file and embedding management. There are no tools for uploading files, deleting files, updating embeddings, or other CRUD operations, leaving significant gaps that will hinder agent workflows in this domain.
Maintenance
Related MCP Connectors
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables efficient vector database operations for embedding storage and similarity search through a Model Context Protocol interface.7-
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables AI models to interact with SourceSync.ai's knowledge management platform for managing documents, ingesting content from various sources, and performing semantic searches.2530 npm1ISC
- FlicenseBqualityDmaintenanceA Model Context Protocol server that enables LLMs to fetch and process web content in multiple formats (HTML, JSON, Markdown, text) with automatic format detection.56-
- FlicenseNot gradedqualityDmaintenanceA simple Model Context Protocol server that enables searching and retrieving relevant documentation snippets from Langchain, Llama Index, and OpenAI official documentation.-