AI 에이전트는 세션 간의 모든 것을 잊어버립니다. Connapse가 이를 해결합니다.
새로운 대화를 시작할 때마다 AI 에이전트는 과거 연구에 대한 기억, 문서에 대한 접근 권한, 축적된 지식 없이 처음부터 다시 시작합니다. Connapse는 에이전트에게 지속적이고 검색 가능한 메모리를 제공하는 오픈 소스 지식 백엔드입니다. 문서를 업로드하거나 기존 Amazon S3 버킷, Azure Blob Storage 컨테이너 또는 로컬 파일 시스템을 연결하세요. 에이전트는 11개의 MCP 도구, REST API 또는 CLI를 통해 연구 자료를 쿼리하고 구축합니다. 컨테이너 격리, 하이브리드 검색(벡터 + 키워드), 자체 호스팅 및 비공개 환경을 지원합니다. Docker를 사용하여 60초 만에 배포하세요. .NET 10 기반으로 구축되었습니다.
AI 에이전트는 MCP 서버를 통해 지식 베이스를 쿼리하고, 문서의 출처 인용이 포함된 구조화된 답변을 받습니다.
임베딩 제공자 전환, 청킹 매개변수 조정, 검색 설정 구성을 재시작 없이 런타임에 수행하세요.
git clone https://github.com/Destrayon/Connapse.git && cd Connapse && docker-compose up -d
# Open http://localhost:5001.NET 10 SDK (개발용)
(선택 사항) 로컬 임베딩을 위한 Ollama
# Clone the repository
git clone https://github.com/Destrayon/Connapse.git
cd Connapse
# Set required auth environment variables (or use a .env file)
export CONNAPSE_ADMIN_EMAIL=admin@example.com
export CONNAPSE_ADMIN_PASSWORD=YourSecurePassword123!
export Identity__Jwt__Secret=$(openssl rand -base64 64)
# Start all services (PostgreSQL, MinIO, Web App)
docker-compose up -d
# Open http://localhost:5001 — log in with the admin credentials above첫 실행 시 다음 작업이 수행됩니다:
Docker 이미지 풀 (~2-5분)
pgvector 확장이 포함된 PostgreSQL 초기화 및 EF Core 마이그레이션 실행
MinIO 버킷 생성
관리자 계정 시드(환경 변수 사용) 및 웹 애플리케이션 시작
# Start infrastructure only (database + object storage)
docker-compose up -d postgres minio
# Run the web app locally
dotnet run --project src/Connapse.Web
# Run all tests
dotnet test
# Run just unit tests
dotnet test --filter "Category=Unit"CLI 설치(옵션 중 선택):
# Option A: .NET Global Tool (requires .NET 10)
dotnet tool install -g Connapse.CLI
# Option B: Download native binary from GitHub Releases (no .NET required)
# https://github.com/Destrayon/Connapse/releases기본 사용법:
# Authenticate first
connapse auth login --url https://localhost:5001
# Create a container (project)
connapse container create my-project --description "My knowledge base"
# Upload files
connapse upload ./documents --container my-project
# Search
connapse search "your query" --container my-project
# Update to latest release (--pre to include alpha/pre-release builds)
connapse update
connapse update --preConnapse는 Claude 및 모든 MCP 클라이언트와 통합하기 위한 모델 컨텍스트 프로토콜(MCP) 서버를 포함합니다.
설정: 웹 UI(설정 → 에이전트 API 키) 또는 CLI(connapse auth agent-key create)를 통해 에이전트 API 키를 생성한 다음, 클라이언트용 구성 스니펫을 추가하세요:
claude mcp add connapse --transport streamable-http http://localhost:5001/mcp --header "X-Agent-Api-Key: YOUR_API_KEY"claude_desktop_config.json에 추가:
{
"mcpServers": {
"connapse": {
"transport": "streamable-http",
"url": "http://localhost:5001/mcp",
"headers": {
"X-Agent-Api-Key": "YOUR_API_KEY"
}
}
}
}.vscode/settings.json(VS Code) 또는 Cursor MCP 구성에 추가:
{
"mcp": {
"servers": {
"connapse": {
"transport": "streamable-http",
"url": "http://localhost:5001/mcp",
"headers": {
"X-Agent-Api-Key": "${input:connapseApiKey}"
}
}
}
}
}VS Code는 처음 사용할 때 API 키를 묻는 메시지를 표시합니다.
MCP 서버는 11개의 도구를 제공합니다:
도구 | 설명 |
| 파일 정리를 위한 새 컨테이너 생성 |
| 문서 개수가 포함된 모든 컨테이너 목록 |
| 컨테이너 삭제 |
| 컨테이너 통계 확인 (문서, 청크, 스토리지, 임베딩) |
| 컨테이너에 단일 파일 업로드 |
| 한 번에 최대 100개의 파일 업로드 |
| 경로의 파일 및 폴더 목록 |
| 문서의 전체 파싱된 텍스트 내용 검색 |
| 컨테이너에서 단일 파일 삭제 |
| 한 번에 최대 100개의 파일 삭제 |
| 컨테이너 내 의미론적, 키워드 또는 하이브리드 검색 |
전체 참조: 매개변수 테이블, 반환 형식, 오류 사례 및 사용 예시는 docs/mcp-tools.md를 참조하세요.
쓰기 보호: Amazon S3 및 Azure Blob Storage 컨테이너는 읽기 전용입니다(소스에서 동기화). 파일 시스템 컨테이너는 컨테이너별 권한 플래그를 따릅니다. 쓰기가 차단된 컨테이너에 대해 업로드 및 삭제 도구를 사용하면 오류가 반환됩니다.
"내 아키텍처 노트를 위해 'project-research'라는 컨테이너를 만들어줘"
"다운로드 폴더의 모든 PDF를 project-research 컨테이너에 업로드해줘"
"project-research 컨테이너에서 속도 제한 전략에 대한 정보를 검색해줘"
"project-research 컨테이너의 /notes/ 폴더에 있는 모든 파일 목록을 보여줘"
"project-research에서 distributed-systems-notes.md의 전체 텍스트를 가져와줘"
"project-research에서 meeting-2026-03-14.md를 삭제하고 이 업데이트된 버전을 업로드해줘"
"project-research의 /drafts/ 폴더에 있는 모든 파일을 삭제해줘"
"project-research 컨테이너에 문서와 청크가 몇 개나 있니?"
localhost:5001 연결 거부 — Docker가 실행 중이지 않거나 포트 충돌입니다. docker compose ps 및 docker compose logs web을 확인하세요.
401 Unauthorized / API 키가 작동하지 않음 — 설정 > 에이전트 API 키에서 키를 확인하세요. 키는 생성 시 한 번만 표시됩니다.
Claude에 도구가 나타나지 않음 — 구성 변경 후 MCP 클라이언트를 다시 시작하세요. curl http://localhost:5001/mcp로 엔드포인트를 확인하세요.
업로드 실패 또는 시간 초과 — 파일 형식이 허용 목록에 있는지 확인하세요. 최대 파일 크기는 서버 구성에 따라 다릅니다.
검색 결과 없음 — 업로드 후 문서가 임베딩될 시간이 필요합니다. 컨테이너 통계에서 임베딩 진행 상황을 확인하세요.
Related MCP server: mnemostack
🗂️ 컨테이너 격리 지식 — 각 프로젝트는 고유한 벡터 인덱스, 스토리지 커넥터 및 검색 구성을 가집니다. 프로젝트, 팀 또는 클라이언트 간의 데이터 혼선이 없습니다.
🔍 하이브리드 검색 — 벡터 유사도 + 키워드 전체 텍스트 검색을 구성 가능한 융합(convex combination, DBSF, AutoCut)으로 제공합니다. 순수 벡터 검색이 놓치는 결과까지 찾아냅니다.
🧠 다중 제공자 AI — 런타임에 컨테이너별로 Ollama, OpenAI, Azure OpenAI, Anthropic 간에 임베딩 및 LLM을 전환할 수 있습니다(재시작 불필요).
🔌 기존 스토리지 인덱싱 — MinIO, 로컬 파일 시스템(실시간 파일 감시), Amazon S3(IAM 인증) 또는 Azure Blob Storage(관리 ID)를 연결하세요. 파일은 원래 위치에 유지됩니다.
🤖 4가지 접근 방식 — 웹 UI, REST API, CLI(네이티브 바이너리), MCP 서버(Claude용 11개 도구). 사람, 스크립트, AI 에이전트 모두를 위해 구축되었습니다.
🔐 엔터프라이즈 인증 — AWS IAM Identity Center 및 Azure AD ID 연결을 포함한 다중 계층 RBAC(쿠키 + OAuth 2.1 + PAT + JWT). 클라우드 권한이 진실의 원천입니다.
🐳 원클릭 배포 — PostgreSQL + pgvector, MinIO 및 선택적 Ollama가 포함된 Docker Compose. 구조화된 감사 로깅 및 속도 제한이 내장되어 있습니다.
📄 다중 형식 수집: PDF, Office 문서, Markdown, 일반 텍스트 — 자동으로 파싱, 청킹 및 임베딩
⚡ 실시간 처리: SignalR을 통한 실시간 진행 상황 업데이트와 함께 백그라운드 수집
🎛️ 런타임 구성: 재시작 없이 컨테이너별로 청킹 전략, 임베딩 모델 및 검색 설정 변경
☁️ 클라우드 ID 연결: AWS IAM Identity Center(기기 인증 흐름) + Azure AD(OAuth2+PKCE) 및 IAM 기반 범위 적용
👥 초대 전용 액세스: 4가지 역할(관리자 / 편집자 / 뷰어 / 에이전트)을 갖춘 관리자 제어 사용자 등록
🤖 에이전트 관리: API 키 수명 주기, 범위 지정 권한 및 감사 추적을 갖춘 전용 에이전트 엔티티
📋 감사 로깅: 업로드, 삭제, 컨테이너 작업 및 인증 이벤트에 대한 구조화된 감사 추적
📦 CLI 배포: 네이티브 독립형 바이너리(Windows/Linux/macOS) 및 NuGet을 통한 .NET 글로벌 도구
🔄 교차 모델 검색: 프로젝트 중간에 임베딩 모델 전환 — 레거시 벡터에 대한 자동 의미론적→하이브리드 폴백
AI 에이전트 개발자: 에이전트가 쿼리하고 구축할 수 있는 지식 백엔드가 필요한 경우 — 연구 업로드, 자료 큐레이션, MCP 또는 REST API를 통한 검색
.NET / Azure 팀: 기존 스택 및 클라우드 ID에 맞는 RAG 플랫폼을 원하는 경우
엔터프라이즈 팀: 적절한 RBAC 및 감사 추적이 포함된 프로젝트 격리 지식 베이스가 필요한 경우
파일 재업로드에 지친 분들: 기존 Amazon S3/Azure Blob Storage/파일 시스템 스토리지에 Connapse를 연결하세요
이 프로젝트는 활발히 개발 중(v0.3.2)이며 프로덕션 준비 단계에 접근하고 있습니다.
v0.3.x는 IAM 기반 액세스 제어, 다중 제공자 임베딩 및 LLM 지원, 클라우드 ID 연결(AWS SSO + Azure AD), 속도 제한을 갖춘 클라우드 커넥터 아키텍처를 추가합니다.
✅ 인증 및 권한 부여 (v0.2.0)
✅ 역할 기반 액세스 제어 (관리자 / 편집자 / 뷰어 / 에이전트)
✅ 감사 로깅
✅ 클라우드 ID 연결 — AWS IAM Identity Center + Azure AD OAuth2+PKCE (v0.3.0)
✅ IAM 기반 범위 적용 — 클라우드 권한이 진실의 원천 (v0.3.0)
✅ 속도 제한 — 사용자별 및 IP별 정책이 포함된 ASP.NET Core 미들웨어 (v0.3.2)
⚠️ 프로덕션 환경에서 강력한 Identity__Jwt__Secret 설정 — 배포 가이드 참조
전체 보안 정책은 SECURITY.md를 참조하세요.
┌──────────────────────────────────────────────────────────────────────┐
│ Access Surfaces │
│ Web UI (Blazor) │ REST API │ CLI │ MCP Server │
└─────────────┬────────────────────────────────────────────────────────┘
│
┌─────────────▼────────────────────────────────────────────────────────┐
│ Core Services Layer │
│ Document Store │ Vector Store │ Search │ Ingestion │
└─────────────┬────────────────────────────────────────────────────────┘
│
┌─────────────▼────────────────────────────────────────────────────────┐
│ Connectors Layer │
│ MinIO │ Filesystem │ Amazon S3 │ Azure Blob Storage │
└─────────────┬────────────────────────────────────────────────────────┘
│
┌─────────────▼────────────────────────────────────────────────────────┐
│ Infrastructure │
│ PostgreSQL+pgvector │ MinIO (S3) │ Ollama (optional) │
└──────────────────────────────────────────────────────────────────────┘[Upload] → [Parse] → [Chunk] → [Embed] → [Store] → [Searchable]
↓
[Metadata]
↓
[Document Store]목표: 업로드부터 검색 가능까지 < 30초.
핵심 기술:
데이터베이스: PostgreSQL 17 + 벡터 임베딩용 pgvector
객체 스토리지: 관리형 스토리지 추상화 — 기본적으로 MinIO(S3 호환), 배포별로 재정의 가능
백엔드: ASP.NET Core 10 Minimal API
**프론트
Delete up to 100 files in one call. Returns per-file success/failure results.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name | |
| fileIds | Yes | JSON array of file (document) IDs to delete, e.g. ["id1","id2"]. Max 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral details beyond the destructiveHint annotation, such as the batch limit and per-file result format.
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?
Two sentences, front-loaded with purpose and limits, no unnecessary words.
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 output schema, description compensates by noting per-file results. Covers key constraints (limit, return format). Could mention error handling for missing files, but sufficient.
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 already describes both parameters fully (100% coverage). The description does not add new semantic value beyond what the schema provides.
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 (delete), resource (files), and limits (up to 100, one call), distinguishing it from single-file deletion and bulk upload.
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?
Implies usage for deleting multiple files up to 100, but lacks explicit when-to-use vs alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload up to 100 files in one call. Each file is parsed, chunked, and embedded. Returns per-file results.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name | |
| files | Yes | JSON array of file objects. Each object: {"filename":"name.txt", "content":"...", "encoding":"text|base64", "folderPath":"/optional/"}. Max 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the processing pipeline (parse, chunk, embed) but lacks details on error handling for partial failures, file size limits, or supported formats. Adequate but not comprehensive.
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?
Two sentences, no filler. Every sentence provides essential information: capacity, processing, and return type.
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?
No output schema exists, so description should clarify return values. 'Returns per-file results' is vague; could specify status, errors, or IDs. Also missing constraints like file size, timeout, or authentication requirements.
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 coverage is 100%, both parameters are documented. The description adds 'Max 100' which reinforces the schema's 'max 100' constraint in files parameter description, but no new meaning beyond 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 uses specific verb 'Upload' with resource 'files', states the limit 'up to 100', and explains the processing pipeline ('parsed, chunked, and embedded'). It clearly distinguishes from sibling 'upload_file' which handles single 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 implies bulk usage via 'up to 100 files' but does not explicitly state when to use this over single upload or alternatives like 'search_knowledge'. No when-not or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new container for organizing documents. Use when setting up a new knowledge domain or project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Container name (lowercase alphanumeric and hyphens, 2-128 chars) | |
| description | No | Optional description for the container |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states creation purpose, lacking details on permissions, side effects, or duplicate handling. Adequate but minimal.
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?
Two clear sentences, front-loaded with action, no unnecessary words.
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?
No output schema, and description does not mention return value (e.g., created container info). Adequate for simple tool but incomplete on expected response.
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 has 100% coverage with descriptions for both parameters. Description repeats the same meaning, adding no extra value. Baseline 3.
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?
Clearly states action (create), resource (container), and purpose (organizing documents). Distinguishes from sibling tools like container_delete or container_list.
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?
Explicitly says 'Use when setting up a new knowledge domain or project', providing clear context. Does not mention exclusions or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a container. MinIO containers must be emptied first. Filesystem/S3/Azure files are not deleted — only the index is removed.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds important behavioral details: files are not deleted, only the index is removed, and MinIO containers must be emptied first.
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?
Two concise sentences, front-loaded with the action and followed by key constraints, with no unnecessary words.
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 simple tool with one parameter and no output schema, the description covers the essential behavior, prerequisites, and what is not deleted, though it could mention irreversibility.
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 coverage is 100%, and the description does not add additional meaning beyond the schema's parameter 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 clearly states the tool deletes a container, and differentiates from sibling tools like delete_file by clarifying that files are not deleted, only the index.
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?
It specifies a prerequisite (MinIO containers must be emptied) and clarifies what is not affected, but does not explicitly compare to alternatives like bulk_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all containers with document counts. Use to discover available knowledge bases before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to repeat these. It adds the return of document counts, but lacks details on pagination or performance. With annotations covering safety, this is adequate.
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 two sentences (12 words) that are front-loaded and contain no fluff. Every word earns its place.
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 parameters and no output schema, the description covers the tool's purpose and usage context well. It mentions 'document counts,' giving insight into return data, but could be slightly more detailed on output format.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, which is appropriate. Baseline 4 for 0 parameters.
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 it lists all containers with document counts and specifies its use for discovering knowledge bases before searching. This differentiates it from sibling tools like container_stats or container_create.
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 explicitly says 'Use to discover available knowledge bases before searching,' providing clear context for when to use it. It lacks explicit exclusion guidance but is sufficient given the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get container statistics: document counts, chunk count, storage size, and embedding model info.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by specifying the exact statistics returned, providing context beyond what annotations offer. No contradictions.
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, front-loaded sentence that efficiently conveys the tool's purpose and output details with no unnecessary words.
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 simple, read-only tool with one parameter and no output schema, the description fully covers what the tool returns and its use case, making it complete.
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 input schema provides full coverage for the single parameter (containerId) with a clear description. The tool description does not add additional semantic meaning for the parameter, so baseline 3 is appropriate.
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 'Get container statistics' and lists specific data (document counts, chunk count, storage size, embedding model info), making it distinct from siblings like container_list which only list container IDs or names.
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 implies the tool is for retrieving statistics of a specific container but does not explicitly state when to use it over alternatives or provide exclusions. No guidance on prerequisites (e.g., container must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file and all its chunks and vectors. To update a file, delete it first then re-upload with upload_file.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name | |
| fileId | Yes | File (document) ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true. The description adds value by specifying that chunks and vectors are also deleted, giving a fuller scope of the operation's effects. It does not contradict annotations.
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?
Two concise sentences: first clearly states the purpose, second provides a practical usage tip. No fluff, front-loaded, every sentence earns its place.
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 simple destructive tool with full schema coverage and an annotation, the description adequately covers the deletion scope and provides an update workflow hint. It could mention irreversibility or permissions, but these are implied by the destructive hint. Overall sufficient.
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 input schema already documents both parameters (containerId and fileId) with descriptions, achieving 100% coverage. The description does not add extra semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.
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 'Delete a file and all its chunks and vectors', which specifies the verb (delete) and resource (file and associated data). It also distinguishes from siblings like bulk_delete by implying single-file deletion via the fileId parameter, and provides additional context about updating.
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 includes explicit guidance for updating: 'To update a file, delete it first then re-upload with upload_file.' However, it does not explicitly warn against using this tool for bulk deletions or when to prefer bulk_delete, though the parameterization hints at single-file usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a document's full text by ID or path. Returns extracted text for binary formats (PDF, DOCX, PPTX).
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name | |
| fileId | Yes | Document ID (UUID) or virtual path (e.g., '/docs/readme.md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds that it returns extracted text for binary formats (PDF, DOCX, PPTX) beyond what annotations convey.
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?
Two front-loaded sentences, no waste, clearly communicate purpose and key behavior.
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 simple retrieval tool with 2 required parameters, description covers purpose, return value (full text, extraction for binaries). Lacks error handling or response format, but sufficient for typical use.
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 coverage is 100% with good descriptions for both parameters. Description restates 'by ID or path' but adds no new semantic detail beyond 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?
Description clearly states verb 'Retrieve' and resource 'document's full text', specifies query by ID or path, and mentions handling of binary formats. Distinguishes from siblings like list_files (metadata) and search_knowledge.
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?
Implied usage context as a read-only retrieval tool, but no explicit when-to-use or alternatives (e.g., 'for metadata use list_files'). Clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and folders at a path within a container. Use to browse container contents before retrieving documents.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name | |
| path | No | Folder path to list (default: root '/') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the browsing context but does not disclose additional behavioral traits such as pagination or error handling, which would provide further transparency.
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 extremely concise with two sentences: one for the core function and one for usage guidance. Every word is necessary and no information is redundant.
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 simple list operation with two parameters and no output schema, the description is fairly complete. It covers what the tool does and when to use it, though it could mention the return structure (e.g., list of file names) to be fully self-contained.
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 the baseline is 3. The description does not add any parameter details beyond what the schema already provides for containerId and path.
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 uses a specific verb 'list' and specifies the resource 'files and folders at a path within a container'. It also provides context by stating its use case 'before retrieving documents', which distinguishes it from siblings like get_document, upload_file, and delete_file.
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 advises using this tool to browse container contents before retrieving documents, giving clear context. However, it does not explicitly exclude other uses or mention alternatives beyond the implied contrast with get_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a container using semantic, keyword, or hybrid mode. Returns ranked document chunks with scores. Use when answering questions from stored knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query text | |
| containerId | Yes | Container ID or name to search within | |
| mode | No | Search mode: Semantic (vector), Keyword (full-text), or Hybrid (both). Default: Hybrid | |
| topK | No | Number of results to return. Default: 10 | |
| path | No | Optional: Filter results to a folder subtree (e.g., '/docs/') | |
| minScore | No | Minimum similarity score floor (0.0-1.0). Defaults to 0.05. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the main behavioral traits are covered. The description adds 'Returns ranked document chunks with scores,' which gives some extra context but is not critical. No destructive behavior or auth needs are mentioned, but annotations suffice.
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 two sentences long, with the first sentence covering purpose and behavior, and the second giving usage guidance. Every sentence adds value, and there is no unnecessary text.
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 the 100% schema coverage, the presence of annotations, and no output schema, the description is fairly complete. It covers purpose, usage, and return type. However, it could briefly mention that results are from the specified container, but that is implicit in the first sentence.
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 coverage is 100%, with each parameter having a description in the input schema. The tool description does not add any additional information about the parameters beyond what the schema already provides, so baseline 3 is appropriate.
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 ('Search a container') and specifies the modes (semantic, keyword, hybrid). It also mentions the return type ('ranked document chunks with scores'), making the tool's purpose distinct from siblings like container_list or get_document.
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 explicitly suggests using the tool 'when answering questions from stored knowledge,' providing a clear use case. However, it does not mention when not to use it or compare to alternatives, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to be parsed, chunked, embedded, and made searchable. Provide either 'content' (base64) or 'textContent' (raw text), not both.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID or name | |
| content | No | Base64-encoded file content. For binary files (PDF, DOCX, images). Mutually exclusive with textContent. | |
| textContent | No | Raw text content for text-based files (Markdown, TXT, CSV, JSON, etc.). Mutually exclusive with content. | |
| fileName | No | Original file name with extension | |
| path | No | Destination folder path (e.g., '/docs/2026/') | |
| strategy | No | Chunking strategy: Semantic, FixedSize, or Recursive. Default: Semantic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions the processing pipeline (parse, chunk, embed) and mutual exclusivity of content types, but does not disclose failure modes, idempotency, permissions, or response format. This is adequate but not rich.
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?
Two sentences with no waste. The purpose is front-loaded, and essential usage hint is included. Every sentence adds value.
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 6 parameters (1 required), schema covers all, and no output schema, the description is fairly complete. It explains the overall goal and key constraint. However, it omits details on return value or confirmation. Still, it is adequate for an agent to understand and use the tool.
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 coverage is 100%, so baseline is 3. The description reiterates the mutual exclusivity of content and textContent already in schema descriptions, adding minimal extra meaning. No new parameter semantics beyond 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 action ('Upload a file') and the resource, and describes the processing pipeline ('parsed, chunked, embedded, and made searchable'). This distinguishes it from sibling tools like bulk_upload (multiple files) and delete_file (deletion).
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 gives a parameter usage guideline ('Provide either content or textContent, not both') but lacks explicit guidance on when to use this tool over siblings like bulk_upload or search_knowledge. No when-not-to-use or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.2bulk_deletebulk_uploadcontainer_createcontainer_deletecontainer_listcontainer_statsdelete_fileget_documentlist_filessearch_knowledgeupload_fileScored across 11 tools
Each tool targets a distinct operation: container management, file operations, bulk actions, and search. No two tools have overlapping purposes; even delete_file and bulk_delete are clearly scoped by single vs batch.
All tools follow a consistent verb_noun snake_case pattern (e.g., container_create, upload_file, search_knowledge). No mixed conventions or vague verbs.
11 tools is well-scoped for a knowledge management server, covering container CRUD, file operations, bulk operations, and search. No redundancy or missing essential operations.
Covers most lifecycle operations: container create/list/delete, file upload/get/list/delete, bulk upload/delete, and search. Missing container update and folder creation, but these are minor gaps that agents can work around.
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.
