Ketan-OS MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KETAN_WORKSPACE | Yes | The absolute path to the project workspace. This corresponds to the --workspace command line argument shown in the README configuration. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ketan_init_workspaceA | Initialize Ketan-OS for a workspace directory. This MUST be called before any other Ketan-OS tools if you are switching workspaces. Creates a KetanHarness that manages transactional snapshotting, invariant enforcement, and causal tracing for the given workspace. Args: workspace_path: Absolute path to the project/workspace directory to protect. |
| ketan_get_statusA | Get the current Ketan-OS ground-truth state report. Returns step count, checkpoint count, CTG node/edge counts, failure count, and workspace directory. |
| ketan_snapshotA | Take an atomic filesystem snapshot of the entire workspace. Creates a checkpoint you can roll back to if anything goes wrong. Always call this before a risky sequence of operations. Returns the checkpoint ID you can use with ketan_rollback. |
| ketan_rollbackA | Time-travel rollback the workspace to a previous checkpoint. Reverts ALL filesystem changes (file writes, deletions, renames) that occurred after that checkpoint was taken, in sub-second time. Args: checkpoint_id: The checkpoint ID to roll back to (from ketan_get_checkpoints or ketan_snapshot). |
| ketan_get_checkpointsA | List all available checkpoints in the Ketan dual-ledger (newest first). Each checkpoint captures the full workspace filesystem state and conversation prompt stack, enabling atomic rollback to any point. |
| ketan_write_file_safeA | Write a file to the workspace with FULL Ketan-OS protection:
Always prefer this over direct file writes for safe, reversible mutations. Args: filepath: Path relative to workspace root (e.g., "src/main.py") content: Full file content to write |
| ketan_run_bash_safeA | Execute a shell command with FULL Ketan-OS protection:
Always prefer this over raw bash for state-changing commands. Args: command: Shell command to run (executed in workspace directory) timeout_seconds: Maximum execution time before timeout (default: 30s) |
| ketan_check_invariantA | Run a pre-flight invariant check WITHOUT executing anything. Validate a planned action before committing to it. Args: tool_name: Name of the tool you plan to call (e.g., "write_file", "bash") tool_args_json: JSON string of the arguments you plan to pass |
| ketan_get_ctgA | Get the Causal Trace Graph (CTG) as a Mermaid diagram. The CTG is a live DAG showing every tool call, checkpoint, failure, and rollback in the session with causal edges between them. Paste the output into mermaid.live to visualize it. |
| ketan_explain_failureA | Get a root-cause explanation of the most recent failure in the CTG. Traces the exact execution chain that led to the failure. Returns a clean message if no failures exist. |
| ketan_observe_beliefA | Record a factual observation into the Epistemic Belief Engine. The engine tracks beliefs about the workspace and detects contradictions (e.g., "tests pass" followed by "tests fail") to prevent hallucination loops. Args: subject: What the belief is about (e.g., "tests/test_main.py") predicate: The relationship (e.g., "exists", "passes", "contains_bug") value: The observed value (e.g., "true", "false", "syntax_error") confidence: Confidence level 0.0–1.0 (default 1.0) |
| ketan_list_beliefsA | List all active beliefs tracked by the Epistemic Belief Engine. These are facts observed about the workspace during this session. |
| ketan_read_fileA | Read a file from the workspace. Also records its existence as a belief. Args: filepath: Path relative to workspace root (e.g., "src/main.py") |
| ketan_list_filesA | List all files in the workspace (or a subdirectory of it). Args: subdirectory: Optional subdirectory relative to workspace root (default: root) |
| ketan_session_summaryA | Get a complete markdown summary of the Ketan-OS session: steps taken, checkpoints created, failures recorded, beliefs tracked. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools are clearly distinct: snapshotting, rollback, safe file writes, safe bash, invariant checks, CTG, beliefs, and file operations all target unique actions. The only overlap is between get_status and session_summary, both providing session state, but at different detail levels (quick report vs comprehensive markdown), so agents can distinguish them with care.
All tools share the ketan_ prefix and use snake_case, with a dominant verb_noun pattern (get_status, list_files, write_file_safe). Minor deviations include one-word verbs (snapshot, rollback) and session_summary lacking a verb, but the pattern is predictable and readable overall.
With 15 tools, the server sits at the upper edge of the well-scoped range. Each tool earned its place in the workspace-protection workflow, though get_status and session_summary are slightly redundant, making the count marginally heavier than necessary.
The tool surface covers the full lifecycle: initialization, atomic snapshots, rollback, guarded mutations, invariant checks, causal tracing, failure explanation, and belief tracking. Minor gaps exist, such as no explicit checkpoint deletion or belief retraction, but these are workaroundable and do not block core workflows.