A
licenseNot graded
qualityD
maintenanceEnables accessing and managing personal/team internal knowledge repository with tools for semantic search, smart search, document listing, and saving information for future recall.
Apache 2.0
TorchV AIS MCP Server
Officialby torchv
@torchv-team/ais-mcp
🚀 Servidor MCP de la Base de Conocimiento TorchV AIS
Un servidor MCP listo para producción que permite operaciones de lectura / escritura / edición / transferencia de archivos directamente en la base de conocimiento empresarial de AIS.
Related MCP server: SAG MCP Server
✨ Características
📚 Acceso unificado a la base de conocimiento AIS
🛠️ Cadena de herramientas MCP completa (lectura / escritura / gestión)
⚡ Inicio con un solo comando mediante
npx🔌 Admite transportes STDIO y HTTP (transmisible)
🔐 Control de permisos detallado (
readonly / write / admin)
🚀 Instalación y ejecución
npx -y @torchv-team/ais-mcp🔑 Configuración requerida
Antes de comenzar, establezca las siguientes variables de entorno:
export KB_EXECUTE_URL="https://bot.torchv.com"
export KB_TOKEN="your-token"🌐 Cómo obtener KB_EXECUTE_URL
📌 Pasos:
Abra su instancia de AIS
Copie el origen del sitio desde la barra de direcciones del navegador
👉 Ejemplo:
https://bot.torchv.com🔐 Cómo obtener KB_TOKEN
Recomendado:
AIS → Admin Center → API Keys → Create KeyTemporal (no recomendado para producción):
Browser DevTools → Network → Inspect request → Copy token⚙️ Configuración opcional
export KB_MODE="readonly" # readonly | write | admin
export KB_TIMEOUT_SECONDS="30"
export KB_DEFAULT_REPO_CODE="TEAM_DOCS"
export KB_EXTRA_HEADERS_JSON='{"x-foo":"bar"}'🛡️ Niveles de permisos
🟢
readonly→ Acceso de solo lectura🟡
write→ Permite escritura / carga / publicación🔴
admin→ Control total (mover / eliminar)
🧩 Modos de ejecución
🖥️ Modo STDIO (Cliente MCP local)
npm run build
node dist/cli.jso:
npm run dev
npm run start🌍 Modo HTTP transmisible
npm run build
node dist/cli.js \
--transport streamable-http \
--host 127.0.0.1 \
--port 3000 \
--path /mcpo:
npm run dev:http
npm run start:http📌 Parámetros:
--transport streamable-http
--host 127.0.0.1
--port 3000
--path /mcp🔌 Configuración de Claude / Codex
STDIO
{
"mcpServers": {
"ais": {
"command": "npx",
"args": ["-y", "@torchv-team/ais-mcp"],
"env": {
"KB_EXECUTE_URL": "https://your-ais-domain",
"KB_TOKEN": "your-token",
"KB_MODE": "readonly"
}
}
}
}Modo HTTP
{
"mcpServers": {
"ais-http": {
"type": "streamable-http",
"url": "http://127.0.0.1:3000/mcp"
}
}
}🛠️ Resumen de herramientas
📖 Solo lectura
kb_list_reposkb_list_pathkb_treekb_searchkb_read_documentkb_render_linkkb_download_filekb_get_download_link
✏️ Escritura
kb_write_documentkb_patch_documentkb_create_directorykb_copy_documentkb_publish_documentkb_upload_file
🔧 Administrador
kb_move_documentkb_delete_document
🧠 Acerca de AIS
AIS es el producto principal de TorchV; no es solo una base de conocimiento tradicional, sino:
🧠 Un motor de conocimiento de IA empresarial
Capacidades principales
🔄 Transformar datos dispersos → conocimiento estructurado
🔍 Buscable
🧩 Gobernable
⚡ Componible
📈 Optimizable
🎁 Pruebe AIS
📲 Contáctenos (WeChat del CEO):
Available Tools
8 toolskb_download_fileD
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| localPath | Yes | ||
| extractIs | No | ||
| overwrite | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_get_download_linkD
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| extractIs | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_list_pathD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| sort | No | ||
| limit | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_list_reposD
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_read_documentD
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| name | No | ||
| range | No | ||
| head | No | ||
| tail | No | ||
| lineNumbers | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_render_linkD
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| repoCode | No | ||
| path | No | ||
| file | No | ||
| docCode | No | ||
| codes | No | ||
| mode | No | ||
| topk | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_treeD
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| depth | No | ||
| limit | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
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.
8 tool updates
v0.1.4- First observed
kb_download_file - First observed
kb_get_download_link - First observed
kb_list_path - First observed
kb_list_repos - First observed
kb_read_document - First observed
kb_render_link - First observed
kb_search - First observed
kb_tree
TDQS
D1.8/5.0
Scored across 8 tools
Disambiguation2/5
The tools have overlapping purposes that could cause confusion, particularly around file/document operations. For example, kb_download_file, kb_get_download_link, and kb_render_link all seem related to accessing files, but their specific distinctions are unclear without descriptions. Similarly, kb_list_path and kb_tree both appear to involve directory/file listing, creating ambiguity in tool selection.
Naming Consistency5/5
All tool names follow a perfectly consistent pattern: they all start with 'kb_' prefix and use snake_case throughout. This uniformity makes the tool set predictable and easy to parse, with no deviations in naming conventions across the eight tools.
Tool Count4/5
With 8 tools, the count is reasonable for a knowledge base or document management server. It's slightly on the higher side but still well-scoped, suggesting a focused domain without being overly sparse or bloated. The number aligns well with typical MCP server tool counts.
Completeness3/5
Inferring from tool names, the server seems designed for knowledge base operations (e.g., listing, reading, searching, downloading). However, there are notable gaps: there are no clear tools for creating, updating, or deleting content, which limits full CRUD coverage. The surface covers retrieval and listing well but misses modification capabilities, potentially causing agent workarounds.
Maintenance
ActivityInactive
ResponsivenessOutdated data
Related MCP Connectors
Read, edit and improve shared documents and knowledge with people and agents.
Software for your AI: company files, spreadsheets and rules, with per-person access and history.
Shared business knowledge, tools and skills for AI agents, with citations and approval controls.
Read and draft requirements, controlled documents and trace links in Traceable Docs.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables full read/write management of SAG knowledge bases, including source and document CRUD, semantic search, knowledge graph queries, and model configuration through 18 MCP tools.2MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI agents and users to search a unified organizational knowledge warehouse, create and iterate on documents, manage folders and reviews, and curate shareable knowledge packs through any compatible MCP client.-
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to search, read, update, and batch-manage persistent documents and workspace knowledge through MCP tools, prompts, and resources.-