Skip to main content
Glama
deenesjakoruzh
torchv

TorchV AIS MCP Server

Official
by torchv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

@torchv-team/ais-mcp

English | 中文

License MCP

🚀 TorchV AIS 지식 베이스 MCP 서버

AIS 엔터프라이즈 지식 베이스에서 직접 읽기 / 쓰기 / 편집 / 파일 전송 작업을 수행할 수 있는 프로덕션 준비 완료 MCP 서버입니다.

img.png

Related MCP server: Engineering Standards MCP Server

✨ 기능

  • 📚 AIS 지식 베이스에 대한 통합 액세스

  • 🛠️ 전체 MCP 툴체인 (읽기 / 쓰기 / 관리)

  • ⚡ npx를 통한 원명령어 시작

  • 🔌 STDIO 및 HTTP (스트리밍 가능) 전송 방식 모두 지원

  • 🔐 세밀한 권한 제어 (readonly / write / admin)

🚀 설치 및 실행

npx -y @torchv-team/ais-mcp

🔑 필수 구성

시작하기 전에 다음 환경 변수를 설정하십시오:

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

🌐 KB_EXECUTE_URL을 얻는 방법

📌 단계:

  1. AIS 인스턴스를 엽니다.

  2. 브라우저 주소 표시줄에서 사이트 오리진(origin)을 복사합니다.

👉 예시:

https://bot.torchv.com

🔐 KB_TOKEN을 얻는 방법

권장:

AIS → Admin Center → API Keys → Create Key

임시 (프로덕션 환경에는 권장하지 않음):

Browser DevTools → Network → Inspect request → Copy token

⚙️ 선택적 구성

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

🛡️ 권한 수준

  • 🟢 readonly → 읽기 전용 액세스

  • 🟡 write → 쓰기 / 업로드 / 게시 허용

  • 🔴 admin → 전체 제어 (이동 / 삭제)

🧩 실행 모드

🖥️ STDIO 모드 (로컬 MCP 클라이언트)

npm run build
node dist/cli.js

또는:

npm run dev
npm run start

🌍 스트리밍 가능한 HTTP 모드

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

또는:

npm run dev:http
npm run start:http

📌 매개변수:

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

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

HTTP 모드

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

🛠️ 도구 개요

📖 읽기 전용

  • kb_list_repos

  • kb_list_path

  • kb_tree

  • kb_search

  • kb_read_document

  • kb_render_link

  • kb_download_file

  • kb_get_download_link

✏️ 쓰기

  • kb_write_document

  • kb_patch_document

  • kb_create_directory

  • kb_copy_document

  • kb_publish_document

  • kb_upload_file

🔧 관리자

  • kb_move_document

  • kb_delete_document

🧠 AIS 소개

AIS는 TorchV의 핵심 제품입니다. 단순한 전통적 지식 베이스가 아닌 다음을 제공합니다:

🧠 엔터프라이즈 AI 지식 엔진

핵심 기능

  • 🔄 분산된 데이터를 구조화된 지식으로 변환

  • 🔍 검색 가능

  • 🧩 관리 가능

  • ⚡ 구성 가능

  • 📈 최적화 가능

🎁 AIS 체험하기

📲 문의 (CEO 위챗):

img.png

Available Tools

8 tools
kb_download_fileD
ParametersJSON Schema
NameRequiredDescriptionDefault
codeYes
localPathYes
extractIsNo
overwriteNo

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
NameRequiredDescriptionDefault
pathYes
sortNo
limitNo

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
NameRequiredDescriptionDefault
sortNo
limitNo

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
NameRequiredDescriptionDefault
codeNo
nameNo
rangeNo
headNo
tailNo
lineNumbersNo

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
NameRequiredDescriptionDefault
pathYes
depthNo
limitNo

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.

  1. 8 tool updatesv0.1.4
    • 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 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

Related MCP Connectors

Related MCP Servers