How do I use cysic-mcp?

1. Click on "Install 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., "@cysic-mcp rewrite this email in a friendly tone" 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.

cysic-mcp

by nguyennpduoc

Overview Schema Related Servers Score Discussions

TypeScript

Local

cysic-mcp

A Model Context Protocol (MCP) server in TypeScript/Node.js that exposes the Cysic AI model (minimax-m3) to any MCP client over stdio, with server-side session memory and a tone-rewriting tool.

Problem

AI assistants and other MCP clients need a uniform way to call an LLM, manage multi-turn conversations across many requests, and rewrite text in different tones — but most existing LLM SDKs are HTTP-first and require per-integration boilerplate. A Cysic AI user has to:

Wire axios (or fetch) with the right Authorization: Bearer … header.
Implement retry/backoff for 429 / 5xx / network failures.
Validate every tool input with zod so a misbehaving client cannot crash the server.
Manage session state for multi-turn chat.
Plug the whole thing into their MCP client.

cysic-mcp collapses all five into a single npm install + one configuration file.

Related MCP server: claude-voice-bridge

Solution

cysic-mcp is a single, small Node.js process that speaks the MCP stdio transport. It registers exactly:

3 tools: cysic_chat, cysic_session, cysic_humanize
2 resources: cysic://models, cysic://sessions/{id}
2 prompts: code_review, humanize_text

…and nothing more. The HTTP layer is a typed CysicClient wrapper around axios with explicit timeout + exponential-backoff retries. All tool inputs are validated by zod. All configuration is environment-driven; the server fails fast at startup if the required CYSIC_API_KEY is missing.

Feature Checklist

The shipped surface, one item per row:

Tool: cysic_chat { prompt, system?, temperature? } — single-turn chat with the Cysic AI model. prompt is required (min length 1); system overrides the default "You are a helpful assistant." preamble; temperature is optional in [0, 2].
Tool: cysic_session { session_id, message } — multi-turn chat with server-side history. The server keeps the full conversation per session_id in an in-process Map; each call sends the entire history to the model and appends the assistant reply. Sessions are created lazily on first use.
Tool: cysic_humanize { text, tone? } — rewrite text in a requested tone. tone defaults to neutral and accepts neutral | friendly | formal | concise | confident. Internally uses a tone-specific system prompt and a low sampling temperature (0.2 for concise, 0.4 otherwise) to keep rewrites stable.
Resource: cysic://models — static catalog of models served by this MCP server, rendered as a JSON text/plain payload (e.g. { models: [{ id: "minimax-m3", provider: "cysic", default: true }] }).
Resource: cysic://sessions/{id} — read template for a single session's message history. The {id} path segment is the session_id. Returns the JSON-serialized message array; missing sessions return [].
Prompt: code_review { language?, code } — render a senior-level code-review prompt for a code snippet. language is optional (e.g. "TypeScript"); code is required. The prompt returns two messages the client can render as a chat template.
Prompt: humanize_text { tone?, text } — render a prompt that mirrors the cysic_humanize tool contract so an MCP client can present it as a chat template without invoking the tool.

Distinctive features (innovation callouts):

Server-side session memory — cysic_session keeps a per-id Map<string, Message[]> so the client does not have to round-trip history. History is in-process; sessions are lost on restart and are not shared across processes (acceptable for a single-instance stdio MCP server).
cysic_humanize tone rewriting — five built-in tones (neutral, friendly, formal, concise, confident), each with its own instruction string and temperature. The same tone vocabulary is reused by the humanize_text prompt so the prompt and the tool stay in lock-step.

Architecture

+----------------------+        stdio JSON-RPC        +------------------+
|  MCP client (e.g.    |  <-------------------------->  |  cysic-mcp      |
|  Claude Desktop,     |                              |  (Node.js)       |
|  any stdio MCP host) |                              |                  |
+----------------------+                              |  src/server.ts   |
                                                     |   |              |
                                                     |   v              |
                                                     |  src/tools/      |
                                                     |  src/resources/  |
                                                     |  src/prompts/    |
                                                     |   |              |
                                                     |   v              |
                                                     |  CysicClient     |
                                                     |  (axios + retry) |
                                                     +--------+---------+
                                                              |
                                                              v
                                                  POST /v1/chat/completions
                                                  https://token-ai.cysic.xyz

Project layout

src/
  server.ts            # MCP server bootstrap, transport wiring
  config.ts            # env loading (loadConfig)
  cysicClient.ts       # axios wrapper + retry/backoff
  state.ts             # in-process session Map (sessions)
  errors.ts            # CysicError + toMcpErrorMessage sanitizer
  tones.ts             # shared tone vocabulary (used by tool + prompt)
  mcpShims.ts          # untyped SDK registration shims
  tools/
    index.ts           # registerTools(server, client, state)
    cysicChat.ts       # cysic_chat tool
    cysicSession.ts    # cysic_session tool
    cysicHumanize.ts   # cysic_humanize tool
  resources/
    index.ts           # registerResources(server, state)
    models.ts          # cysic://models resource
    session.ts         # cysic://sessions/{id} resource template
  prompts/
    index.ts           # registerPrompts(server)
    codeReview.ts      # code_review prompt
    humanizeText.ts    # humanize_text prompt
tests/
  cysicClient.test.ts  # 8 tests (a-e per AC-3, plus a few extras)
  structure.test.ts    # 5 tests defending the AC-5 module split
dist/                  # tsc output (gitignored)

Install

cysic-mcp requires Node.js >= 18.17 (for native fetch / AbortController; we still use axios per the project rubric for explicit timeout + retry control).

git clone <this-repo> cysic-mcp
cd cysic-mcp
npm install
npm run build

The build emits dist/server.js, which is the entry point referenced by the start script and the cysic-mcp bin.

Configure

Copy the example env file and fill in your real Cysic API key:

cp .env.example .env
# then edit .env and set CYSIC_API_KEY=...

The full set of environment variables:

Variable	Required	Default	Description
`CYSIC_API_KEY`	yes	—	Bearer token for the Cysic AI endpoint. Never echoed in logs.
`CYSIC_BASE_URL`	no	`https://token-ai.cysic.xyz/v1`	Base URL for the Cysic AI OpenAI-compatible API.
`CYSIC_MODEL`	no	`minimax-m3`	Default model used by the tools when no per-call override is given.
`CYSIC_TIMEOUT_MS`	no	`30000`	Per-request HTTP timeout in milliseconds.
`CYSIC_MAX_RETRIES`	no	`3`	Retries on `429` / `5xx` / network errors (exponential backoff + jitter).

If CYSIC_API_KEY is missing or empty, the server fails fast at startup with a clear error message that names the variable (but does not echo the value).

Run

Production (after npm run build):

npm start
# equivalent to:  node dist/server.js

Development (live TypeScript via tsx):

npm run dev
# equivalent to:  tsx src/server.ts

The server uses the MCP stdio transport. There is no HTTP port to scrape; stdout is reserved for the MCP JSON-RPC stream. All fatal startup errors are written to stderr so they do not corrupt the MCP channel.

MCP Client Registration

Point your MCP client at the compiled entry point. The exact JSON shape depends on the client; the two common forms are below.

Claude Desktop (`claude_desktop_config.json`)

Add this entry under mcpServers:

{
  "mcpServers": {
    "cysic": {
      "command": "node",
      "args": ["/absolute/path/to/cysic-mcp/dist/server.js"],
      "env": {
        "CYSIC_API_KEY": "sk-your-real-key-here"
      }
    }
  }
}

If you prefer the .env file approach, omit the env block and let the server read it from disk:

{
  "mcpServers": {
    "cysic": {
      "command": "node",
      "args": ["/absolute/path/to/cysic-mcp/dist/server.js"]
    }
  }
}

Generic stdio MCP config

Any MCP host that speaks stdio can launch the server as a child process. The minimum invocation is:

{
  "command": "node",
  "args": ["dist/server.js"],
  "cwd": "/absolute/path/to/cysic-mcp",
  "env": {
    "CYSIC_API_KEY": "sk-your-real-key-here",
    "CYSIC_BASE_URL": "https://token-ai.cysic.xyz/v1",
    "CYSIC_MODEL": "minimax-m3"
  }
}

For a development-mode build, swap node + dist/server.js for npx tsx src/server.ts and the host will run the TypeScript source directly.

Example Tool Calls

The examples below are copy-pasteable. The exact wire format depends on your MCP client; the JSON argument shape is what the server validates with zod.

`cysic_chat` — single-turn chat

{
  "name": "cysic_chat",
  "arguments": {
    "prompt": "What is the capital of France?",
    "system": "You are a concise geography tutor.",
    "temperature": 0.2
  }
}

Returns:

{
  "content": [{ "type": "text", "text": "Paris." }],
  "isError": false
}

`cysic_session` — multi-turn chat with server-side history

Turn 1:

{
  "name": "cysic_session",
  "arguments": {
    "session_id": "user-42",
    "message": "Hi, my name is Alice."
  }
}

Turn 2 (the server sends the full [user, assistant, user] history to the model):

{
  "name": "cysic_session",
  "arguments": {
    "session_id": "user-42",
    "message": "What's my name?"
  }
}

The full history can be inspected at runtime by reading the cysic://sessions/user-42 resource.

`cysic_humanize` — tone rewriting

{
  "name": "cysic_humanize",
  "arguments": {
    "text": "We're gonna ship the thing on Friday. Probably.",
    "tone": "formal"
  }
}

tone defaults to neutral; the full set of accepted values is neutral | friendly | formal | concise | confident.

`cysic://models` — model catalog

{ "uri": "cysic://models" }

Returns a JSON payload listing the Cysic AI models served by this server (currently { id: "minimax-m3", provider: "cysic", default: true }).

`cysic://sessions/{id}` — per-session history

{ "uri": "cysic://sessions/user-42" }

Returns the JSON-serialized message array for user-42. Missing sessions return [].

`code_review` prompt

{
  "name": "code_review",
  "arguments": {
    "language": "TypeScript",
    "code": "const x: number = 1; console.log(x);"
  }
}

Renders two messages the client can show as a chat template: a "you are a senior TypeScript engineer…" brief and a fenced code block to review.

`humanize_text` prompt

{
  "name": "humanize_text",
  "arguments": {
    "tone": "confident",
    "text": "I think maybe we could try to ship this?"
  }
}

Renders two messages that mirror the cysic_humanize tool contract (the tone instruction as the first message, the text to rewrite as the second). Because the MCP PromptMessage.role enum is restricted to "user" | "assistant", both messages are emitted with role: "user"; the "system" intent from the plan is preserved by the two-message shape, not by a literal role: "system".

Testing

Unit tests use vitest and stub the HTTP layer with nock so no real network is ever made.

npm test

The current suite covers:

tests/cysicClient.test.ts — 8 tests across the AC-3 cases (a) 200 returns first choice, (b) 429 retried then succeeds, (c) 500 retried then fails with no apiKey in the message, (d) 400 fails fast with code: BAD_REQUEST and is not retried, (e) request body includes model and messages, plus extras for temperature pass-through, per-call model override, and empty-messages rejection.
tests/structure.test.ts — 5 tests importing every per-feature registerX function and the CysicError / toMcpErrorMessage / TONE_VALUES / temperatureForTone / TONE_INSTRUCTIONS exports from the compiled dist/ tree, to defend the AC-5 module split.

License

MIT

Available Tools

3 tools

cysic_chatB

Single-turn chat with the Cysic AI model. Returns the model reply as a text content block.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	The user message to send to the model.
`system`	No	Optional system prompt. Defaults to a helpful-assistant instruction.
`temperature`	No	Sampling temperature in [0, 2]. Optional.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It reveals only that the chat is single-turn and returns text. No mention of authorization, rate limits, statefulness, or other side effects. 'Single-turn' adds minimal disclosure.

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 concise sentences front-load the purpose and return format. No filler or redundant information. 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?

Given no output schema, the description explains the return value (text content block). It covers the essential behavior for a simple chat tool. Could mention rate limits or authentication needs, but not critical for basic usage. Adequately complete.

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

Parameters3/5

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

Schema description coverage is 100% (all 3 parameters have descriptions). The tool description does not add any extra meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameters sufficiently.

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

Purpose5/5

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

The description clearly states the tool is for single-turn chat with a specific model and returns a text reply. It uses specific verb+resource ('chat with the Cysic AI model') and the sibling tools suggest different functions (humanize, session), making it easy to distinguish.

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 on when to use this tool vs siblings. There is no mention of alternatives, restrictions, or typical use cases. The description only states what it does, not when or when not to use it.

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

cysic_humanizeA

Rewrite a piece of text in a requested tone. Returns the rewritten text as a text content block.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The text to rewrite (max 20000 characters).
`tone`	No	The target tone. Defaults to neutral.	neutral

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full transparency burden. It only repeats the core transformation ('rewrite') and output type, but fails to disclose any behavioral traits such as whether the operation is read-only, permissions needed, side effects, error behavior, or idempotency.

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 exceptionally concise: two short sentences that front-load the action and output. Every word adds value, with no redundancy or extraneous information.

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's simplicity (2 parameters, no nested objects, no output schema), the description provides adequate context. However, it could be slightly more complete by noting that the original text is not modified and that the output is a new text block, but it is not missing critical information.

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

Parameters3/5

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

Both parameters (text, tone) are fully described in the input schema with min/max lengths and enumerated values. The description adds minimal extra meaning beyond the schema (only noting 'text content block' for output). With 100% schema coverage, baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the action ('Rewrite') and the resource ('a piece of text in a requested tone'), and mentions the output format. This distinguishes it from sibling tools like cysic_chat (chatting) and cysic_session (session management).

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 when to use the tool (rewriting text to adjust tone), but it does not provide explicit guidance on when to avoid using it or how it compares to siblings. No 'when to use' or 'alternatives' are stated, leaving the agent to infer context.

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

cysic_sessionA

Multi-turn chat with the Cysic AI model and a server-side session memory. Each call sends the full prior history to the model and appends both turns to the session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes	Identifier for the session. Created lazily on first use.
`message`	Yes	The new user message for this turn.

TDQS

A3.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Clearly discloses that each call sends full history and appends both turns to session. Does not mention error handling or rate limits, but core behavior is well explained.

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, front-loaded with core concept, then behavioral detail. No wasted words; structure is optimal for quick comprehension.

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

Completeness3/5

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

Describes main behavior but lacks output specification (no output schema) and does not address error conditions or usage limits. Could be more complete given the tool's simplicity.

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

Parameters3/5

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

Schema coverage is 100% with good param descriptions. Description adds context about statefulness but does not significantly enhance understanding beyond what the schema already provides. Baseline 3 is appropriate.

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?

Clearly states it's for multi-turn chat with server-side session memory, but does not explicitly differentiate from sibling cysic_chat (likely single-turn). Purpose is clear but sibling distinction is 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?

Describes use case (multi-turn with session) but provides no when-not-to-use guidance or alternatives. The agent must infer that this is for ongoing conversations versus single queries.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a distinctly clear purpose: single-turn chat, text rewriting, and multi-turn chat. No overlap or ambiguity.

Naming Consistency3/5

All tools use the 'cysic_' prefix, but the second part mixes verb forms ('chat', 'humanize') with a noun ('session'), creating a slight inconsistency in naming pattern.

Tool Count4/5

Three tools is reasonable for a focused AI interaction server, though slightly minimal. It covers essential functions without unnecessary bloat.

Completeness4/5

The tool set covers the core use cases (single/multi-turn chat and text rewriting). Missing features like session management or system prompt configuration are minor gaps.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Quallaa
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

riven-mcpofficial
AI & Machine Learning Autonomous Agents
rivenai
A
license
A
quality
B
maintenance
This MCP server exposes Riven's chat, research, council, and usage capabilities as tools over stdio, enabling any MCP-compatible client to interact with Riven directly.
Updated a month ago (2026-07-30 21:36 UTC)
4
MIT
claude-voice-bridge
shepard5
F
license
Not graded
quality
C
maintenance
Exposes headless Claude Code as a remote MCP server with a voice client, enabling hands-free task execution and session management via OpenAI's Realtime API.
Updated 2 months ago (2026-07-18 01:40 UTC)
supermemory-stdio-mcp
jfreels123
A
license
Not graded
quality
D
maintenance
A stdio-based MCP server that wraps Supermemory's REST API, providing persistent memory, semantic search, and user profiles via stdio transport for universal compatibility with MCP clients.
Updated 8 months ago (2026-01-05 17:41 UTC)
2
MIT
PoYo MCP Serverofficial
AI & Machine Learning Autonomous Agents
PoyoAPI
A
license
Not graded
quality
B
maintenance
Local stdio bridge to the hosted PoYo MCP server, enabling discovery and execution of AI models via chat, generation tasks, and agent skills.
Updated 2 days ago (2026-09-01 02:54 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/nguyennpduoc/mcp-tool'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

cysic-mcp

Problem

Solution

Feature Checklist

Architecture

Project layout

Install

Configure

Run

MCP Client Registration

Claude Desktop (claude_desktop_config.json)

Generic stdio MCP config

Example Tool Calls

cysic_chat — single-turn chat

cysic_session — multi-turn chat with server-side history

cysic_humanize — tone rewriting

cysic://models — model catalog

cysic://sessions/{id} — per-session history

code_review prompt

humanize_text prompt

Testing

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

riven-mcpofficial

claude-voice-bridge

supermemory-stdio-mcp

PoYo MCP Serverofficial

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)

`cysic_chat` — single-turn chat

`cysic_session` — multi-turn chat with server-side history

`cysic_humanize` — tone rewriting

`cysic://models` — model catalog

`cysic://sessions/{id}` — per-session history

`code_review` prompt

`humanize_text` prompt