Skip to main content
Glama
jayashankarvr

execkit-mcp

by jayashankarvr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

session_create

Open a stateful shell session for local, SSH, or Docker, preserving working directory and environment across commands. Supports secret redaction and undoable remote file changes via checkpoints.

Instructions

Open a stateful shell session. Prefer this over a built-in/inline shell when you need: cwd/env kept across calls, a remote host over SSH (host may be a hostname/IP or a Host alias from the operator's ssh config, /config, default ~/.ssh/config), a Docker container, secret-redacted output, or undoable remote file changes (checkpoints); local has no checkpoints. transport: "local"|"ssh"|"docker". ssh needs host (alias HostName/User/Port/IdentityFile fill in what you omit) + password or key_path (or an alias/default key). docker needs container. Optional fingerprint (pin host key), allow/deny. Returns session_id. Remote checkpoints need git on the remote AND an explicit workspace (set 'workspace'; otherwise off, never defaults to home); tune via auto_snapshot/paths/checkpoint_ignores. output_budget default-shapes every command's output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
denyNoOptional command denylist (program names).
hostNoSSH host (required for ssh). May be a raw hostname/IP, or a Host alias defined in the operator's ssh config (<key_dir>/config, default ~/.ssh/config) - HostName/User/Port/IdentityFile from a matching alias fill in whatever isn't given below.
portNoSSH port (default 22, or the alias's Port).
userNoSSH user (required for ssh, unless the operator's ssh config (<key_dir>/config, default ~/.ssh/config) Host alias sets User).
allowNoOptional command allowlist (program names). If set, only these run.
pathsNoSub-paths under the root to checkpoint (optional; default: whole root).
key_pathNoSSH private-key path (must live under the operator's key dir).
passwordNoSSH password auth. If omitted along with key_path, one key is picked: the first that exists (inside the operator's key dir) of the ssh config (<key_dir>/config, default ~/.ssh/config) alias's IdentityFile entries, then id_ed25519, id_ecdsa, id_rsa in the key dir. If the server rejects that key, no other key is tried.
containerNoDocker container name or id (required for docker).
transportYesTransport: "local" (a local shell), "ssh", or "docker".
workspaceNoRemote workspace root for checkpoints. REQUIRED to enable checkpoints; there is no default (it will not snapshot the cwd/home dir).
fingerprintNoOptional pinned host-key fingerprint ("SHA256:..."). If set, the server requires the host key to match exactly. Otherwise the operator's known_hosts file is used.
auto_snapshotNoAuto-snapshot before changing remote commands (default true, but only takes effect once `workspace` is set; remote only).
output_budgetNoDefault output budget for every exec in this session (optional).
checkpoint_ignoresNoExtra exclude patterns (gitignore syntax) added to the snapshot, on top of the built-in defaults (.git, node_modules, caches, .ssh, ...).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.10.1
    • addedInput schema / $defs / KeepParams / properties / mode / enum
      Added value: +[
+  "all",
+  "tail",
+  "head",
+  "head_tail"
+]
    • changedInput schema / properties / host / description
      Previous value: -"SSH host (required for ssh)."New value: +"SSH host (required for ssh). May be a raw hostname/IP, or a Host alias\ndefined in the operator's ssh config (<key_dir>/config, default\n~/.ssh/config) - HostName/User/Port/IdentityFile from a matching\nalias fill in whatever isn't given below."
    • changedInput schema / properties / password / description
      Previous value: -"SSH password auth."New value: +"SSH password auth. If omitted along with key_path, one key is picked:\nthe first that exists (inside the operator's key dir) of the ssh\nconfig (<key_dir>/config, default ~/.ssh/config) alias's\nIdentityFile entries, then id_ed25519, id_ecdsa, id_rsa in the key\ndir. If the server rejects that key, no other key is tried."
    • changedInput schema / properties / port / description
      Previous value: -"SSH port (default 22)."New value: +"SSH port (default 22, or the alias's Port)."
    • addedInput schema / properties / transport / enum
      Added value: +[
+  "local",
+  "ssh",
+  "docker"
+]
    • changedInput schema / properties / user / description
      Previous value: -"SSH user (required for ssh)."New value: +"SSH user (required for ssh, unless the operator's ssh config\n(<key_dir>/config, default ~/.ssh/config) Host alias sets User)."
  2. First observedv0.8.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses statefulness, secret-redacted output, that remote checkpoints require git plus an explicit workspace and never default to home, and the key-selection fallback ("if the server rejects that key, no other key is tried"). It omits session lifecycle (expiry, limits, need to destroy) and overall error behavior, so it falls short of exhaustive.

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

Conciseness4/5

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

Front-loaded with the core action, and every sentence carries information. It is a single very dense run-on paragraph, however, with topics (auth, checkpoints, budgets) packed together rather than grouped, which costs readability for a 15-parameter tool.

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 complex 15-parameter tool with no output schema and no annotations, it covers purpose, transport-specific requirements, checkpoint semantics, and states the return value (session_id). Missing pieces are session lifecycle and concurrency/error expectations, which are not derivable elsewhere.

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 coverage is already 100%, so the baseline is 3; the description adds value by stating cross-parameter relationships the schema does not, e.g. ssh needs host plus password or key_path, docker needs container, and workspace must be set for checkpoints while auto_snapshot/paths/checkpoint_ignores tune them. That is meaningful semantics beyond the per-field text.

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?

Opens with a specific verb and resource: "Open a stateful shell session." It immediately scopes the tool (stateful vs. built-in/inline shell) and enumerates the transports it supports, so an agent can tell it apart from session_exec or session_destroy without inspecting schemas.

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

Usage Guidelines5/5

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

Gives explicit selection criteria: use this "when you need: cwd/env kept across calls, SSH, Docker, secret-redacted output, or undoable remote file changes (checkpoints); local has no checkpoints." It also states the per-transport prerequisites (ssh needs host + password or key_path; docker needs container), which is effectively when-it-applies guidance.

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

Deploy Server

Other Tools