de en es ja ko ru zh

TorchV AIS MCP Server

Name: TorchV AIS MCP Server
Author: torchv

Official

by torchv

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

`@torchv-team/ais-mcp`

Englisch | Chinesisch

Lizenz MCP

🚀 TorchV AIS Wissensdatenbank MCP-Server

Ein produktionsbereiter MCP-Server, der Lese- / Schreib- / Bearbeitungs- / Dateiübertragungs- Vorgänge direkt in der AIS Enterprise-Wissensdatenbank ermöglicht.

Related MCP server: Engineering Standards MCP Server

✨ Funktionen

📚 Einheitlicher Zugriff auf die AIS-Wissensdatenbank
🛠️ Vollständige MCP-Toolchain (Lesen / Schreiben / Verwaltung)
⚡ Start mit einem Befehl über npx
🔌 Unterstützt sowohl STDIO- als auch HTTP (streamable)-Transporte
🔐 Fein abgestufte Berechtigungskontrolle (readonly / write / admin)

🚀 Installation & Ausführung

npx -y @torchv-team/ais-mcp

🔑 Erforderliche Konfiguration

Legen Sie vor dem Start die folgenden Umgebungsvariablen fest:

export KB_EXECUTE_URL="https://bot.torchv.com"
export KB_TOKEN="your-token"

🌐 So erhalten Sie `KB_EXECUTE_URL`

📌 Schritte:

Öffnen Sie Ihre AIS-Instanz
Kopieren Sie den Site-Origin aus der Adressleiste des Browsers

👉 Beispiel:

https://bot.torchv.com

🔐 So erhalten Sie `KB_TOKEN`

Empfohlen:

AIS → Admin Center → API Keys → Create Key

Temporär (nicht für die Produktion empfohlen):

Browser DevTools → Network → Inspect request → Copy token

⚙️ Optionale Konfiguration

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"}'

🛡️ Berechtigungsstufen

🟢 readonly → Schreibgeschützter Zugriff
🟡 write → Erlaubt Schreiben / Hochladen / Veröffentlichen
🔴 admin → Volle Kontrolle (Verschieben / Löschen)

🧩 Ausführungsmodi

🖥️ STDIO-Modus (Lokaler MCP-Client)

npm run build
node dist/cli.js

oder:

npm run dev
npm run start

🌍 Streambarer HTTP-Modus

npm run build
node dist/cli.js \
  --transport streamable-http \
  --host 127.0.0.1 \
  --port 3000 \
  --path /mcp

oder:

npm run dev:http
npm run start:http

📌 Parameter:

--transport streamable-http
--host 127.0.0.1
--port 3000
--path /mcp

🔌 Claude / Codex-Konfiguration

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-Modus

{
  "mcpServers": {
    "ais-http": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:3000/mcp"
    }
  }
}

🛠️ Tool-Übersicht

📖 Schreibgeschützt

kb_list_repos
kb_list_path
kb_tree
kb_search
kb_read_document
kb_render_link
kb_download_file
kb_get_download_link

✏️ Schreiben

kb_write_document
kb_patch_document
kb_create_directory
kb_copy_document
kb_publish_document
kb_upload_file

🔧 Administrator

kb_move_document
kb_delete_document

🧠 Über AIS

AIS ist das Kernprodukt von TorchV – nicht nur eine herkömmliche Wissensdatenbank, sondern:

🧠 Eine Enterprise-KI-Wissensmaschine

Kernfähigkeiten

🔄 Verwandelt verstreute Daten → strukturiertes Wissen
🔍 Durchsuchbar
🧩 Steuerbar
⚡ Kombinierbar
📈 Optimierbar

🎁 AIS ausprobieren

📲 Kontaktieren Sie uns (CEO WeChat):

Available Tools

8 tools

kb_download_fileD

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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 updatesv0.1.4Apr 23, 2026
- First observedkb_download_file
- First observedkb_get_download_link
- First observedkb_list_path
- First observedkb_list_repos
- First observedkb_read_document
- First observedkb_render_link
- First observedkb_search
- First observedkb_tree

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.8/5.0

Scored 2026-04-23 03:00 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

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

KumbukaOAuth
ai.kumbuka
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Knowledge & Memory RAG Systems
21
brainatticOAuth
ai.brainattic
The knowledge base your AI reads and writes, under your rules — over MCP, EU-hosted.
Knowledge & Memory Search
2
iknowOAuth
dev.iknow
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Knowledge & Memory Search Documentation Access
1
mkdshare.DEV A
io.github.PhilipAnd
Publish and share access-controlled Markdown documents from any MCP-enabled AI tool.
Content Management Systems Documentation Access Developer Tools
112

Related MCP Servers

Rememberizer MCP Server for
Knowledge & Memory Search RAG Systems
skydeckai
A
license
Not graded
quality
D
maintenance
Enables accessing and managing personal/team internal knowledge repository with tools for semantic search, smart search, document listing, and saving information for future recall.
Updated 5 months ago (2026-04-20 07:17 UTC)
Apache 2.0
Engineering Standards MCP
Developer Tools Documentation Access Knowledge & Memory
ifoundry
F
license
Not graded
quality
D
maintenance
Provides 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.
Updated 9 months ago (2025-12-11 12:42 UTC)
1
-
autotuesday-kb-mcp
Knowledge & Memory Cloud Platforms
autotuesday
F
license
Not graded
quality
D
maintenance
Enables secure access to an organizational knowledge base via Supabase (RLS), providing tools for search, retrieval, writing, version history, and change tracking.
Updated 3 months ago (2026-07-02 14:24 UTC)
-
SAG MCP Server
Knowledge & Memory AI & Machine Learning
guazixiong
A
license
Not graded
quality
C
maintenance
Enables 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.
Updated a month ago (2026-08-21 08:19 UTC)
MIT

@torchv-team/ais-mcp

✨ Funktionen

🚀 Installation & Ausführung

🔑 Erforderliche Konfiguration

🌐 So erhalten Sie KB_EXECUTE_URL

🔐 So erhalten Sie KB_TOKEN

⚙️ Optionale Konfiguration

🛡️ Berechtigungsstufen

🧩 Ausführungsmodi

🖥️ STDIO-Modus (Lokaler MCP-Client)

🌍 Streambarer HTTP-Modus

🔌 Claude / Codex-Konfiguration

STDIO

HTTP-Modus

🛠️ Tool-Übersicht

📖 Schreibgeschützt

✏️ Schreiben

🔧 Administrator

🧠 Über AIS

Kernfähigkeiten

🎁 AIS ausprobieren

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`@torchv-team/ais-mcp`

🌐 So erhalten Sie `KB_EXECUTE_URL`

🔐 So erhalten Sie `KB_TOKEN`