What can you do with this server?

This server is an MCP bridge that lets AI agents discover and call JAICP/Tovie Platform OpenAPI operations through three read-only or mutating tools. * jaicp_specs — returns the bundled official JAICP/Tovie OpenAPI specs without any network access. * jaicp_operations — lists OpenAPI operations for one spec (bot-channel, project, reporter, async, text-campaign, caila, calls) and optionally searches by operationId, path, or summary. * jaicp_call — executes an operation by spec id + operationId, with support for path/query/headers/body parameters, exact path disambiguation for duplicate operationIds, and confirm: true required for mutations unless JAICP_READ_ONLY is set. * Supports JSON, form-urlencoded, multipart (base64), and binary responses; enforces timeouts, max response size, blocks redirects, and rejects unsafe path parameters. * Can target either JAICP or Tovie Platform depending on configured host/tokens; read-only mode is available globally via JAICP_READ_ONLY=true.

How do I use jaicp-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jaicp-mcp Show me my project's analytics for last week" 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.

jaicp-mcp

by CryLeech

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

jaicp-mcp

MCP-сервер для работы AI-агентов с JAICP и Tovie Platform

Release Node.js MCP License: MIT

Русский · English

jaicp-mcp подключает MCP-клиенты — Cursor, Claude Code, Codex CLI и другие — к HTTP API JAICP и Tovie Platform.

Сервер строит запросы по официальным OpenAPI, проверяет параметры до обращения к сети и защищает mutating-операции. Один и тот же контракт содержит 160 операций для обоих облаков.

IMPORTANT

Это неофициальный проект. Он не является продуктом Just AI или Tovie AI.

Возможности

семь API: проекты, каналы, аналитика, асинхронные отчёты, текстовые рассылки, CAILA и Dialer;
автоматическая подстановка required/default-параметров из OpenAPI;
JSON, form-urlencoded, multipart-файлы из base64 и бинарные ответы;
защита мутаций через confirm и глобальный режим JAICP_READ_ONLY;
таймауты, запрет redirect, лимит ответа и редакция типичных секретов;
одинаковый контракт для JAICP и Tovie Platform — меняются только хост и токены;
полностью автономные тесты без запросов к реальным API.

Related MCP server: Open API MCP Server

Быстрый старт

1. Установите сервер

Требуются Git и Node.js 20 или новее.

git clone https://github.com/CryLeech/jaicp-mcp.git
cd jaicp-mcp
npm ci
cp .env.example .env

В PowerShell последняя команда выглядит так:

Copy-Item .env.example .env

2. Добавьте токен

Откройте .env и укажите как минимум unified-токен из раздела JAICP/Tovie «Доступ к API»:

JAICP_HOST=https://app.jaicp.com
JAICP_UNIFIED_TOKEN=your-unified-token
JAICP_PROJECT_SHORT_NAME=your-project-short-name

Для Tovie Platform используйте JAICP_HOST=https://platform.tovie.ai и токен, выпущенный этим облаком.

CAUTION

Не добавляйте.env в Git и не помещайте токены в конфигурацию MCP-клиента.

3. Подключите MCP-клиент

Добавьте сервер в ~/.cursor/mcp.json или .cursor/mcp.json, заменив путь на абсолютный:

{
  "mcpServers": {
    "jaicp": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/jaicp-mcp/src/server.mjs"]
    }
  }
}

После перезапуска Cursor сервер предоставит три инструмента: jaicp_specs, jaicp_operations и jaicp_call.

claude mcp add --transport stdio jaicp -- node /absolute/path/to/jaicp-mcp/src/server.mjs

Подробнее: Claude Code MCP.

[mcp_servers.jaicp]
command = "node"
args = ["/absolute/path/to/jaicp-mcp/src/server.mjs"]
cwd = "/absolute/path/to/jaicp-mcp"

Подробнее: Codex MCP.

Примеры запросов

После подключения можно обращаться к API обычным языком:

«Покажи список проектов JAICP».
«Найди операции для получения статистики сессий».
«Покажи текстовые рассылки проекта my-project».
«Экспортируй интенты CAILA».

Перед вызовом сервер найдёт точную OpenAPI-операцию, проверит обязательные параметры и определит, изменяет ли она данные.

Инструменты

`jaicp_specs`

Показывает подключённые API, хост, версию сервера и наличие нужных токенов. Значения токенов не возвращаются.

`jaicp_operations`

Ищет операции одной спеки по operationId, пути, тегу или описанию. Возвращает required/default-параметры, форматы тела и ответа, а также признак мутации.

`jaicp_call`

Выполняет операцию по spec + operationId. При совпадающих operationId принимает точный OpenAPI path для дизамбигуации.

{
  "spec": "project",
  "operationId": "getByProjectShortName",
  "pathParams": {
    "projectShortName": "my-project"
  }
}

Поддерживаемые API

bot-channel — JAICP · Tovie
project — JAICP · Tovie
reporter — JAICP · Tovie
async — JAICP · Tovie
text-campaign — JAICP · Tovie
caila — JAICP · Tovie
calls — JAICP · Tovie

Vendored-копии YAML находятся в vendor/specs/. npm run check-specs сравнивает их с файлами обоих облаков.

Конфигурация

Переменная	Назначение	По умолчанию
`JAICP_HOST`	Хост JAICP или Tovie Platform	`https://app.jaicp.com`
`JAICP_UNIFIED_TOKEN`	Проекты, каналы, reporter и рассылки	—
`JAICP_PROJECT_SHORT_NAME`	Проект для path/query, если он не указан в вызове	—
`JAICP_NLP_TOKEN`	CAILA / NLP Direct	—
`JAICP_CALLS_TOKEN`	Dialer	—
`JAICP_READ_ONLY`	Запретить любые мутации	`false`
`JAICP_FETCH_TIMEOUT_MS`	Таймаут HTTP-запроса	`120000`
`JAICP_MAX_RESPONSE_BYTES`	Максимальный размер ответа	`2000000`
`JAICP_ENV`	Путь к другому env-файлу	—

Сервер ищет конфигурацию в ~/.cursor/secrets/jaicp.env, затем в .env проекта. Явные переменные окружения имеют приоритет.

JAICP_PROJECT_SHORT_NAME подставляется и в query, и в {projectShortName} path.

Безопасность

WARNING

confirm: true защищает только от случайного вызова: этот флаг передаёт та же AI-модель. Для гарантированного запрета изменений используйте JAICP_READ_ONLY=true.

мутации определяются по HTTP-методу и x-security-authority;
Dialer addPhone* считается мутацией даже при использовании GET;
path-параметры с /, \, dot-segments и управляющими символами отклоняются;
автоматические HTTP-redirect запрещены;
multipart принимает base64, но не читает произвольные локальные пути;
сервер редактирует типичные токены, но не обещает удалять персональные данные;
reporter-выгрузки могут содержать персональные данные.

HTTP без TLS разрешён только для localhost. Для явного dev-исключения существует JAICP_ALLOW_INSECURE_HOST=1.

Форматы данных

JSON используется по умолчанию;
application/x-www-form-urlencoded поддерживается для Dialer;
multipart/form-data принимает { filename, mediaType, data }, где data — base64;
JSON и text-ответы возвращаются как текст MCP;
application/octet-stream возвращается как MCP embedded resource.

Разработка

npm test
npm run check
npm run check-specs
openspec validate --all --strict --no-interactive

Изменения проектируются через OpenSpec. Активные изменения находятся в openspec/changes/.

Лицензия

Исходный код распространяется по MIT. JAICP и связанные знаки принадлежат Just AI; Tovie AI Platform и связанные знаки — Tovie AI. Подробнее: NOTICE.md.

Available Tools

3 tools

jaicp_callB

Call a JAICP/Tovie OpenAPI operation by spec id + operationId. Writes need confirm=true unless JAICP_READ_ONLY.

ParametersJSON Schema

Name	Required	Description
`body`	No
`path`	No	Exact OpenAPI path when operationId is duplicated
`spec`	Yes
`query`	No
`confirm`	No	Required true for mutating calls. Ignored when JAICP_READ_ONLY=true
`headers`	No
`pathParams`	No
`operationId`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It discloses a key behavior: writes require confirm=true unless JAICP_READ_ONLY. However, it does not address error handling, authentication, rate limits, or return format, which are important for a complex tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the primary purpose and adds a critical usage constraint. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 8 parameters, nested objects, and no output schema. The description provides only the basic call mechanism and the confirm requirement. It lacks guidance on parameter construction, expected response, error conditions, or authentication, making it incomplete for an agent to use reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (25% – only path and confirm have descriptions). The description adds meaning for confirm (mutations require it) and clarifies that spec and operationId identify the operation, but it does not explain body, query, headers, or pathParams. Given the low coverage, the description should compensate more but only partially does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action ('Call a JAICP/Tovie OpenAPI operation') and identifies the resource via 'spec id + operationId'. It is specific enough to distinguish from sibling tools that list specs or operations, though it does not explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: this tool executes an operation, while siblings likely enumerate specs/operations. However, it does not explicitly state when to use it over alternatives, nor provide exclusions. The mention of confirm for writes hints at a usage condition but not a full guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jaicp_operationsA

List OpenAPI operations from one spec. Optional search over operationId, path, summary.

ParametersJSON Schema

Name	Required	Description	Default
`spec`	Yes
`search`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. The verb 'List' conveys a read-only operation and the description names the search dimensions, but it does not disclose what happens when search is omitted, the output shape, ordering, or edge cases. This is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The primary purpose is front-loaded and the optional search behavior is stated directly. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity two-parameter listing tool, the description is sufficient for an agent to select and invoke it correctly. The spec enum is in the schema, and the description explains the optional search behavior. The absence of an output schema is mitigated by the clear 'List operations' framing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds real meaning to the search parameter by specifying it can filter over operationId, path, and summary, which is not inferable from the schema. For 'spec', the schema's enum already documents valid values, while 'from one spec' clarifies its role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists OpenAPI operations from a single spec and outlines searchable fields. It is specific about the verb and resource, but it does not explicitly contrast with the sibling tools (e.g., jaicp_specs for listing specs, jaicp_call for invoking an operation), so sibling differentiation is left implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'from one spec' gives a clear usage context: use this tool when you need operations belonging to a specific spec. However, there is no explicit guidance about when not to use it or which sibling tool should be chosen instead, such as jaicp_specs for finding available specs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

jaicp_specsA

Official JAICP/Tovie OpenAPI specs this MCP was built from. No network.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It explicitly states 'No network,' which is a useful trait indicating local operation. However, it does not describe the output format, size, or any other behavior, so transparency is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that delivers the essential information—what the tool is and that it is local—without any filler. It is front-loaded and efficiently communicates the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and a simple purpose, the description covers the key facts. It states the tool's source and offline nature, which is sufficient for an agent to decide whether to call it. It could mention that it returns the full OpenAPI spec, but that is implied by the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter-specific information (there are none), but it does clarify that the tool returns specs, which aligns with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (the OpenAPI specs) and its provenance (built from), making the purpose clear. It does not explicitly contrast with sibling tools, but the name and description make it obvious this is about specs rather than calls or operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus jaicp_call or jaicp_operations. The description does not mention use cases, prerequisites, or alternatives, leaving the agent to infer applicability.

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 tool updateSep 9, 2026

Changedjaicp_call4 fields changed

changedInput schema / properties / confirm / description

Previous value: -"Required true for create/update/delete and dialer addPhone GET"New value: +"Required true for mutating calls. Ignored when JAICP_READ_ONLY=true"

addedInput schema / properties / path

Added value: +{
+  "description": "Exact OpenAPI path when operationId is duplicated",
+  "type": "string"
+}

addedInput schema / properties / query / additionalProperties / anyOf

Added value: +[
+  {
+    "type": [
+      "string",
+      "number",
+      "boolean"
+    ]
+  },
+  {
+    "items": {
+      "type": [
+        "string",
+        "number"
+      ]
+    },
+    "type": "array"
+  }
+]

removedInput schema / properties / query / additionalProperties / type
```
Removed value: -[
-  "string",
-  "number",
-  "boolean"
-]
```

3 tool updatesv0.1.0Sep 7, 2026
- First observedjaicp_call
- First observedjaicp_operations
- First observedjaicp_specs

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

A3.8/5.0

Scored 2026-09-09 17:35 across 3 tools

Disambiguation5/5

The three tools occupy clearly separate roles: jaicp_specs exposes available API specifications, jaicp_operations lists operations within a spec, and jaicp_call invokes a specific operation. There is no meaningful semantic overlap between them.

Naming Consistency4/5

All tools share the jaicp_ prefix and use lowercase snake_case, making them predictable. The names are not strictly verb_noun — jaicp_specs and jaicp_operations are resource-style nouns while jaicp_call is a verb — but the convention is still clear.

Tool Count5/5

Three tools is the right size for a dynamic OpenAPI gateway: one for spec discovery, one for operation discovery, and one for execution. Each tool is essential and none is redundant.

Completeness5/5

This covers the full workflow for the domain: discover available specs, inspect and search operations, and call any operation. Since jaicp_call can target any operationId, the entire API surface is reachable without needing per-endpoint tools.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-server AOAuth
com.httpstatus
AI-callable tools for API mocking, testing, monitoring, security, and automation.
API Testing Testing & QA Tools App Automation
92
nexusOAuth
com.civic
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Agent Orchestration Developer Tools App Automation
2
Air Pipe B
io.airpipe
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Developer Tools CI/CD & DevOps App Automation
191
ToolRouter B
io.github.Humanleap
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Agent Orchestration Autonomous Agents
481

Related MCP Servers

openapi-mcp-bridge
Developer Tools API Testing
sssdavid529
A
license
Not graded
quality
B
maintenance
Turns any OpenAPI/Swagger API into MCP tools, enabling AI assistants to call REST API endpoints directly.
Updated 4 months ago (2026-05-31 18:24 UTC)
2
MIT
Open API MCP Server
API Testing Documentation Access Developer Tools
HaoYan-A
A
license
Not graded
quality
F
maintenance
Provides AI assistants with access to OpenAPI specifications, enabling API discovery, schema retrieval, and direct API execution with support for OAuth 2.0 and other authentication methods.
Updated a year ago (2025-10-29 07:50 UTC)
9 npm
1
MIT
api-docs-mcp-server
Documentation Access Developer Tools
geniyangge
A
license
A
quality
B
maintenance
Exposes OpenAPI/Swagger API documentation as MCP tools, enabling AI agents to search, inspect, and call API endpoints through natural language.
Updated a month ago (2026-08-20 11:02 UTC)
5
17 npm
MIT
openapi-to-mcp
Developer Tools
The-Swarm-Corporation
A
license
Not graded
quality
C
maintenance
Enables MCP clients to call any OpenAPI-defined API by automatically converting its operations into tools, with built-in support for authentication, rate limiting, and response handling.
Updated a month ago (2026-08-22 20:36 UTC)
7
Apache 2.0