Enables Hermes to manage and interact with CLI sessions through Cicall's MCP interface.
Click 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., "@Cicall list my active sessions"
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.
Run and orchestrate CLI agents from any terminal.
Cicall is a terminal-independent, local MCP runtime for CLI agents. It owns the agent processes and their pseudo-terminals in a small background daemon. Your terminal, editor, desktop app, or MCP client is only a replaceable frontend.
Claude Code / Codex / Kimi / OpenCode
│ MCP (stdio)
cicall-mcp
│ local Unix socket
cicall daemon
│ PTY
any CLI agent or commandThis repository is an independent extraction of the session-orchestration idea first prototyped in Helios. Cicall does not depend on Helios, Ghostty, AppKit, or any particular terminal emulator.
Cicall is an early, usable MVP for macOS and Linux. The current release is local-only and has no network listener. Do not expose its Unix socket to users you do not trust: a connected client can launch commands with your account.
Related MCP server: interminal
Python 3.9 or newer is required. The simplest install keeps Cicall in its own
environment and exposes the commands through ~/.local/bin:
curl -fsSL https://raw.githubusercontent.com/basionwang-bot/cicall/main/scripts/install.sh | sh
~/.local/bin/cicall setup --client hermes --project my-app --cwd "$PWD"You can inspect scripts/install.sh before running it. A manual installation from the GitHub release is documented in docs/TESTING.zh-CN.md.
cicall setup starts the local runtime and prints the exact MCP configuration
for the current installation. The MCP server also starts the daemon automatically,
so users do not have to manage it before opening their MCP client.
For development from a source checkout:
cd ~/Desktop/cicall
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
pip install -e .
cicall setup --client generic --project my-appNo Python package is required at runtime beyond the standard library.
Start an interactive CLI and stay attached:
cicall run --project my-app --cwd ~/code/my-app -- claudeStart it in the background:
cicall run --detach --project my-app --cwd ~/code/my-app -- codex
cicall list --project my-app
cicall attach s-xxxxxxxxxxxxRead or drive a session without attaching a terminal UI:
cicall read s-xxxxxxxxxxxx
cicall send s-xxxxxxxxxxxx "Please run the tests" --enter
cicall key s-xxxxxxxxxxxx ctrl-c
cicall close s-xxxxxxxxxxxxSwitching from Terminal.app to iTerm, Ghostty, Warp, VS Code, or SSH does not
change the managed process. Run cicall attach SESSION_ID from the new terminal.
Running cicall setup prints a ready-to-paste configuration. A manual example:
cicall setup --client hermes --project my-app --cwd "$PWD"Supported setup targets are generic, hermes, claude, and codex. Codex
can be registered automatically:
cicall setup --client codex --project my-app --cwd "$PWD" --applyCheck an installation at any time:
cicall doctor --fixThen register the server with a fixed project scope:
{
"mcpServers": {
"cicall": {
"command": "/absolute/path/to/cicall-mcp",
"args": ["--project", "my-app", "--cwd", "/absolute/path/to/my-app"]
}
}
}The MCP server exposes:
list_sessions
read_output
send_text
send_key
start_session
close_session
Cicall follows the standard newline-delimited MCP stdio transport. It also
auto-detects LSP-style Content-Length framing for compatibility with hosts
such as HermesPet; replies use the same framing selected by the client.
An MCP server started with --project my-app cannot read, control, or close
sessions belonging to another project.
With --cwd configured, an agent can start a CLI with only its argv:
{"command": ["claude"]}Variable | Meaning | Default |
| Runtime state directory |
|
| Unix socket path |
|
| Default MCP project scope | current directory name |
The daemon passes CICALL_SOCKET, CICALL_PROJECT, and CICALL_SESSION_ID to
every managed child. An MCP client launched inside a managed session therefore
inherits the correct runtime and project automatically.
Cicall deliberately separates three concerns:
daemon.py owns PTYs, process lifetime, output buffers, and the local socket.
mcp.py translates MCP tool calls into runtime operations.
cli.py is one human-facing client; it can be replaced by a GUI or web UI.
The PTY is an execution backend, not a terminal emulator. Cicall does not render terminal output. This is what makes it independent from the terminal application.
Persist and restore session metadata across daemon restarts.
Add task/delegation tools above the session primitives.
Add structured activity detection and wait_until_idle.
Add Docker, SSH, tmux, and remote-agent backends behind a backend interface.
Add HTTP/SSE MCP transport with authentication for remote deployments.
Ship signed binaries, Homebrew packaging, and Linux packages.
Add a protocol SDK so third-party GUIs can become Cicall frontends.
Issues and pull requests are welcome. Keep the local runtime dependency-light, make dangerous capabilities explicit, and preserve project isolation.
MIT License. See LICENSE.
Terminate a managed CLI session in this project.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only says 'terminate' without detailing side effects, what happens to the session process, or any prerequisites for closing.
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?
The description is concise (one sentence) but lacks any structure or additional context. It is minimally acceptable but not well-organized.
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?
Given no output schema and low complexity, the description is overly minimal. It does not mention whether the action is irreversible or what happens to active processes inside the session.
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?
Schema description coverage is 0%, and the description does not explain the session_id parameter beyond its name, failing to compensate for the lack of schema explanations.
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?
The description clearly states the verb 'Terminate' and the resource 'managed CLI session', distinguishing it from siblings like list_sessions and start_session.
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?
No explicit guidance on when to use vs alternatives, but the context of closing a session is implied. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CLI sessions in this Cicall project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It fails to disclose behavioral traits such as whether the operation is read-only, safe, or has any side effects. For a list operation, stating it is a read-only query would be helpful but is missing.
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?
The description is a single sentence that is front-loaded and contains no extraneous information. Every word earns its place.
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?
Given the tool's simplicity (no parameters, no output schema), the description is adequate. However, it could optionally mention the return format (e.g., list of session IDs or names) to be fully complete.
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?
The input schema has zero parameters, so the description does not need to add parameter meaning. Baseline 4 applies because no parameter documentation is required.
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?
The description 'List CLI sessions in this Cicall project' clearly states the verb (list), resource (CLI sessions), and scope (this Cicall project). It distinguishes the tool from siblings like start_session and close_session by focusing on listing.
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?
The description implies usage when you need to view existing sessions, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., if you need to interact with a session, you'd use other tools). No when-not or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the recent output of a managed CLI session.
| Name | Required | Description | Default |
|---|---|---|---|
| max_bytes | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Read the recent output' but fails to explain if output is truncated, if 'recent' implies limits, or how max_bytes affects behavior. No side effects or safety info.
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?
The description is a single sentence with no extraneous words, but it is too brief, omitting necessary details. It is suitable in length for clarity but lacks substance.
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?
Given the lack of output schema and annotations, the description should compensate. It does not explain return values, possible output formats, or how session output is managed. Incomplete for a 2-parameter tool.
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?
The schema coverage is 0% and the description provides no explanation of 'session_id' (what it identifies) or 'max_bytes' (its purpose and default). The description adds no value over raw schema.
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?
The description uses a specific verb 'Read' and identifies the resource as 'recent output of a managed CLI session'. It clearly distinguishes the tool's function from siblings like 'send_text' or 'start_session'.
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?
No guidance is provided on when to use this tool versus alternatives, such as after sending commands with 'send_text' or 'send_key'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a special key such as enter, escape, arrows, or ctrl-c.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description lacks any behavioral details such as side effects, safety, or what happens when a key is sent (e.g., simulation, state changes).
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?
The single sentence is very concise and front-loaded, but it omits necessary structure like parameter descriptions or usage context.
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?
With no output schema, no annotations, and minimal parameter info, the description fails to convey essential context like return values, error conditions, or prerequisites (e.g., active session).
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?
Schema coverage is 0%, but the description only reiterates examples from the key enum and ignores session_id entirely, adding minimal value beyond the schema.
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?
The description clearly states the tool sends a special key (enter, escape, arrows, ctrl-c) and distinguishes from siblings like send_text which sends text input.
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?
No guidance on when to use this tool versus alternatives like send_text or read_output. No context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into a session. Set submit=true to append Enter.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| submit | No | ||
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only reveals the submit behavior (appending Enter) but omits other behavioral traits like effects on session state, handling of edge cases (e.g., empty text, inactive session), or required prerequisites, despite no annotations existing to cover these.
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?
Two concise sentences provide the core functionality and an important option without extraneous information. The structure is front-loaded and efficient.
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?
For a simple tool with 3 parameters and no output schema, the description is minimally adequate. It covers the main action and the submit toggle but lacks details about session_id sourcing, return value, or error conditions.
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?
With 0% schema description coverage, the description adds meaning only for the 'submit' parameter (explaining its effect). It does not elaborate on 'text' or 'session_id' beyond their names, leaving some ambiguity for the agent.
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?
The description clearly states the tool's action ('Type text into a session') and its key option ('Set submit=true to append Enter'), differentiating it from sibling tools like send_key which handles key presses.
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?
The description lacks guidance on when to use this tool versus alternatives such as send_key or start_session. No context for appropriate or inappropriate scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start any CLI program in a managed PTY in this project. cwd defaults to the MCP server's configured working directory. Returns only the new session id for easy follow-up calls.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| cols | No | ||
| rows | No | ||
| command | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only shares basic behavior: starting a PTY command and default cwd. It omits critical details like session persistence, resource consumption, blocking nature, or that sessions need to be closed.
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?
The description is two sentences, front-loaded with the main purpose. Every sentence adds value: purpose, default behavior, return value. No redundant or irrelevant details.
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?
Despite good purpose clarity, the description lacks context for a complex interaction tool. No mention of how to interact via sibling tools (send_text, read_output), lifecycle management, error handling, or environment. The return value is specified, but behavioral guidelines are missing.
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?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It clarifies cwd's default but says nothing about command structure, cols, or rows, leaving their meaning and constraints (e.g., terminal dimensions) unexplained.
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?
The description clearly states the tool starts any CLI program in a managed PTY within the project, with a specific verb and resource. It distinguishes from sibling tools like close_session or list_sessions, as it initiates a session.
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?
The description implies use for starting a new CLI session but does not explicitly provide when to use or when not to use it, nor does it mention alternatives among the sibling tools. Usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0close_sessionlist_sessionsread_outputsend_keysend_textstart_sessionEach tool targets a distinct operation on CLI sessions: starting, closing, listing, sending text, sending keys, and reading output. No overlap in functionality.
All tools follow a consistent verb_noun pattern (e.g., start_session, close_session, list_sessions, send_text, send_key, read_output).
With 6 tools, the set is well-scoped for managing CLI sessions. Each tool serves a necessary role without excess or insufficiency.
The tools cover the full lifecycle of a CLI session: creation, interaction (text, keys, output reading), and destruction, plus listing. No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/basionwang-bot/cicall'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
