Skip to main content
Glama
liqiangcc

agent-runtime-mcp

by liqiangcc

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TMUX_TIMEOUT_MSNoTimeout in milliseconds for tmux backend operations (e.g., command execution or reads).
TMUX_SOCKET_NAMENoName of the tmux socket to connect to (e.g., 'agent-runtime'). Used to discover existing tmux servers.
TMUX_SOCKET_PATHNoFull path to the tmux socket, if not using the default socket path.
TMUX_MAX_CHANNELSNoMaximum number of channels (tmux panes) that can be exposed by the MCP server.
TMUX_READ_MAX_BYTESNoMaximum number of bytes that can be read from a channel in a single operation.
TMUX_READ_MAX_LINESNoMaximum number of lines that can be read from a channel in a single operation.
TMUX_ALLOWED_SESSIONSNoComma-separated list of tmux session names that the MCP server is allowed to access. Enforces scope restrictions.
TMUX_READ_DEFAULT_LINESNoDefault number of lines to read from a channel's output when no explicit limit is provided.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_channelsA

List existing terminal channels visible in the configured backend scope.

get_channelA

Inspect mechanical metadata and capabilities for one terminal channel.

read_channelA

Read bounded recent terminal output from one channel without waiting for semantic completion.

write_textA

Deliver bounded ordinary Unicode terminal text to one existing channel. LF/TAB are allowed; explicit controls use send_control.

send_controlA

Send one explicit reviewed terminal control to an existing channel.

healthA

Report mechanical backend/service health independently of Channel inventory or application state.

wait_channel_eventB

Wait for mechanically observed Channel snapshot activity followed by bounded quiet; never infers completion.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation4/5

Each tool targets a distinct action: listing, inspecting, reading, writing, controlling, waiting, and health checking are all separable. The only mild ambiguity is between wait_channel_event and read_channel, but the descriptions clearly separate waiting for activity from reading output.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern: get_channel, list_channels, read_channel, send_control, write_text. The exception is health, which breaks the pattern by being a bare noun rather than something like get_health or check_health.

Tool Count5/5

Seven tools is a well-scoped size for a terminal-channel runtime. Each tool covers a meaningful operation without redundancy or bloat.

Completeness4/5

The surface covers the core interaction lifecycle for existing channels: inspect, list, read, write, control, and wait. Channel creation/teardown is not exposed, but that may intentionally live outside this server's scope, so it is a minor rather than critical gap.

Maintenance

ActivityMaintained
ResponsivenessResponsive