TorchV AIS MCP Server
OfficialClick 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., "@TorchV AIS MCP Serversearch the knowledge base for onboarding documents"
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.
@torchv-team/ais-mcp
π TorchV AIS Knowledge Base MCP Server
A production-ready MCP server that enables read / write / edit / file transfer operations directly on the AIS enterprise knowledge base.
Related MCP server: Engineering Standards MCP Server
β¨ Features
π Unified access to AIS knowledge base
π οΈ Full MCP toolchain (read / write / management)
β‘ One-command startup via
npxπ Supports both STDIO and HTTP (streamable) transports
π Fine-grained permission control (
readonly / write / admin)
π Installation & Run
npx -y @torchv-team/ais-mcpπ Required Configuration
Before starting, set the following environment variables:
export KB_EXECUTE_URL="https://bot.torchv.com"
export KB_TOKEN="your-token"π How to get KB_EXECUTE_URL
π Steps:
Open your AIS instance
Copy the site origin from the browser address bar
π Example:
https://bot.torchv.comπ How to get KB_TOKEN
Recommended:
AIS β Admin Center β API Keys β Create KeyTemporary (not recommended for production):
Browser DevTools β Network β Inspect request β Copy tokenβοΈ Optional Configuration
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"}'π‘οΈ Permission Levels
π’
readonlyβ Read-only accessπ‘
writeβ Allows write / upload / publishπ΄
adminβ Full control (move / delete)
π§© Run Modes
π₯οΈ STDIO Mode (Local MCP Client)
npm run build
node dist/cli.jsor:
npm run dev
npm run startπ Streamable HTTP Mode
npm run build
node dist/cli.js \
--transport streamable-http \
--host 127.0.0.1 \
--port 3000 \
--path /mcpor:
npm run dev:http
npm run start:httpπ Parameters:
--transport streamable-http
--host 127.0.0.1
--port 3000
--path /mcpπ Claude / Codex Configuration
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"
}
}
}
}HTTP Mode
{
"mcpServers": {
"ais-http": {
"type": "streamable-http",
"url": "http://127.0.0.1:3000/mcp"
}
}
}π οΈ Tooling Overview
π Read-only
kb_list_reposkb_list_pathkb_treekb_searchkb_read_documentkb_render_linkkb_download_filekb_get_download_link
βοΈ Write
kb_write_documentkb_patch_documentkb_create_directorykb_copy_documentkb_publish_documentkb_upload_file
π§ Admin
kb_move_documentkb_delete_document
π§ About AIS
AIS is TorchVβs core product β not just a traditional knowledge base, but:
π§ An Enterprise AI Knowledge Engine
Core Capabilities
π Transform scattered data β structured knowledge
π Searchable
π§© Governable
β‘ Composable
π Optimizable
π Try AIS
π² Contact us (CEO WeChat):

Available Tools
8 toolskb_download_fileD
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| localPath | Yes | ||
| extractIs | No | ||
| overwrite | No |
TDQS
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
TDQS
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.
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.
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.
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
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
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
The knowledge base your AI reads and writes, under your rules β over MCP, EU-hosted.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables 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
- FlicenseNot gradedqualityDmaintenanceProvides AI assistants with structured access to an organization's engineering standards, practices, and processes through searchable knowledge base with CRUD operations and multi-dimensional organization.1
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to search, deep-read, and build knowledge bases from Markdown, PDF, DOCX, and PPTX documents via MCP tools for retrieval, document navigation, and ingestion.50627MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to read and write a local-first knowledge base of plain markdown files in git, with governance gates for safe, hash-anchored edits.1Apache 2.0
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/torchv/ais-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
