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., "@kasm-workspaces-mcp Create a Kasm Linux desktop session and share a view-only link."
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.
An MCP server for managing Kasm Workspaces sessions from an LLM — create/destroy/pause/resume sessions, screenshot them, dispatch commands, share view-only links, and (opt-in) manage users/groups/registries.
Written from scratch against the real, live-verified behavior of Kasm's Developer API — see docs/API_BEHAVIOR.md for what that means in practice and why it matters.
pip install -e ".[dev]" # add ".[ssh]" too if you want execute_kasm_command_sshRelated MCP server: AnythingLLM MCP Server
Required environment variables:
Variable | Description |
| e.g. |
| from Kasm Admin → Access Management → API Keys |
| the Kasm user this server acts as (UUID, with hyphens) |
Optional:
Variable | Default | Description |
|
| comma-separated path allowlist |
|
| registers official user/group management tools |
|
| registers undocumented registry/image tools |
|
| registers |
| — | required if |
|
| |
| — | use when |
Any of these can also go in a .env file in the directory you run kasm-mcp
from (see .env.example) — it's loaded automatically and never overrides a
variable already set in the real environment (e.g. by an MCP client's own
env config in .mcp.json).
kasm-mcpOr wire it into a .mcp.json:
{
"mcpServers": {
"kasm": {
"type": "stdio",
"command": "kasm-mcp",
"env": {
"KASM_API_URL": "https://kasm.example.com",
"KASM_API_KEY": "...",
"KASM_API_SECRET": "...",
"KASM_USER_ID": "..."
}
}
}
}docs/ARCHITECTURE.md — module map and data flow
docs/API_BEHAVIOR.md — verified real Kasm API quirks
docs/SECURITY.md — the three opt-in modes and their threat models
docs/ADMIN_UNOFFICIAL.md — the undocumented registry/image module
MIT — see LICENSE.
Create a new Kasm session. Set enable_sharing=True to get a usable share_id back.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | ||
| image_name | Yes | ||
| enable_sharing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It correctly implies a mutating, stateful operation ('Create'), but it does not mention persistence, resource consumption, permission requirements, or cleanup obligations. The only behavioral insight is that enable_sharing=True yields a usable share_id, which is helpful but too narrow to adequately disclose the side effects of provisioning a new session.
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 extremely concise: two sentences, no fluff. It front-loads the core purpose ('Create a new Kasm session') and then adds the key parameter nuance. Each sentence earns its place; there is no redundant wording or structure.
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 tool with 3 parameters, no output schema, and no annotations, the description is too thin. It does not explain what the response will include (e.g., session ID, connection info) and only hints at share_id. It ignores contextual details such as how image_name maps to available workspaces (the sibling get_available_workspaces likely provides this), or why group_id is required. An agent cannot confidently call this tool without further research.
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 parameter descriptions are absent (0% coverage), so the tool description must explain parameters. It adds meaning only for enable_sharing ('get a usable share_id back'), while saying nothing about what image_name and group_id represent, how to obtain valid values, or their roles. group_id is required, and image_name is required, so leaving them unexplained is a serious gap.
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 states a specific action and resource: 'Create a new Kasm session.' It is distinct from sibling tools like destroy_kasm_session, pause_kasm_session, and get_session_status. It lacks explicit sibling differentiation, but the verb and resource make the purpose immediately unambiguous.
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?
There is no guidance about when to use this tool versus alternatives beyond the implied 'creation' context. It does not state prerequisites (e.g., need for an available group or image), nor when not to use it (e.g., if a session already exists or if the user only needs status). The only conditional guidance is about enable_sharing, which is a parameter detail, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently destroy a Kasm session.
| Name | Required | Description | Default |
|---|---|---|---|
| kasm_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'permanently' effectively communicates that the operation is irreversible, which is meaningful behavioral context beyond the tool name. However, with no annotations, it omits other relevant consequences such as whether running processes are killed or whether the action fails under certain session states.
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 one short sentence, front-loads the key verb, and contains no filler. It is maximally concise while still conveying the destructive permanence.
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?
A destructive tool with no output schema and no annotations needs more context about consequences, errors, or prerequisites. The description only states the action and does not cover return behavior, failure conditions, or relationship to pause/resume.
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?
There is zero schema description coverage and the description adds no parameter-level meaning. The single parameter 'kasm_id' is reasonably self-explanatory, but the tool description does not confirm that a session ID is required or describe how it should be provided.
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 ('destroy') plus a clear resource ('Kasm session'), and the word 'permanently' sharply distinguishes it from pause/resume operations. It leaves no ambiguity about what the tool does.
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 given for when to use destroy versus pause, resume, or other sibling tools. An agent is left to infer the operational context without any explicit when-to-use or when-not-to-use cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatch a command inside a session. Kasm's API never returns output/exit_code for this call.
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | ||
| command | Yes | ||
| kasm_id | Yes | ||
| working_dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a critical behavior: the API never returns output or exit code, which is important for setting agent expectations. However, it omits other behavioral aspects like error handling, side effects, or asynchronicity, leaving the agent to guess. This partial disclosure earns a mid-range score.
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 extremely concise, two sentences with no filler. It front-loads the key limitation (no output). However, it is so brief that it under-delivers on necessary information, but that is a completeness issue, not a conciseness problem. As written, it is efficiently structured.
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 tool with four parameters, no schema descriptions, and no annotations, the description is severely incomplete. It fails to define required parameters, explain the expected input format (e.g., how commands are provided), or mention prerequisites like an existing session. An agent cannot confidently call this tool without additional inference.
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 has 0% description coverage, and the description gives no explanation of any parameters. With four parameters (including two required ones), the agent has no information about what kasm_id, command, working_dir, or user mean or how to populate them. The description entirely fails to compensate for the schema gap.
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 action ('dispatch a command') and the resource ('inside a session'). It distinguishes from sibling tools which focus on session lifecycle (create, destroy, pause) or information retrieval, making the purpose unmistakable.
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. It doesn't mention that a kasm_id of an active session is required, nor does it indicate that this is the tool for executing commands as opposed to session management. The context implies it, but there is no explicit 'use this when' or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available workspace images.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. 'List' signals a non-mutating operation and 'available' adds a scoping qualifier, which is useful, but the description does not mention output format, authentication, or any limitations beyond availability.
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 front-loaded sentence with no redundant wording. Every word in 'List available workspace images.' 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?
For a zero-parameter list tool, the description is nearly complete: it states the action and the resource. The only gap is that there is no output schema and the description does not specify what fields the returned images contain, but for this simple tool the gap is minor.
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 and the description coverage is effectively 100%, so there is nothing for the description to add. The baseline of 4 applies because the tool takes no arguments.
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 ('List') and a concrete resource ('available workspace images'), so an agent can tell it is a read-only catalog operation rather than a session-lifecycle mutation. It is clear, though it does not explicitly contrast itself with sibling tools, so it stops short of the strongest differentiation.
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 when-to-use guidance is provided. The description does not say this should be called before create_kasm_session to pick an image ID, nor does it mention any alternative tools. An agent must infer the intended context from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of a session. Pass save_to_file to write a JPEG; otherwise returns base64.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| height | No | ||
| kasm_id | Yes | ||
| save_to_file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output behavior (base64 vs JPEG file) and the side effect of writing a file when save_to_file is set. However, it doesn't mention potential side effects like file size, permissions, or whether the screenshot captures the current state or has any delay. It also doesn't state if the session must be running. The description adds some behavioral context but not comprehensive.
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 action and then the output mode. Every word earns its place. It is concise and structured effectively.
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 has 4 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain width, height, or kasm_id semantics, nor does it describe the return format beyond 'base64'. It also doesn't mention any prerequisites or error conditions. For a tool that captures screenshots, an agent would need more context on dimensions and session state.
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%, so the description must compensate. It only explains save_to_file, leaving width, height, and kasm_id undocumented. The description adds meaning for save_to_file but not for the other parameters. Since there are 4 parameters and only one is explained, the description is insufficient for parameter semantics.
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 function: capturing a screenshot of a session. It specifies the output format (base64 or JPEG file), which distinguishes it from sibling tools that manage sessions or execute commands. However, it doesn't explicitly differentiate it from other potential screenshot tools, but among the listed siblings, it is unique.
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: call this when you need a screenshot of a session. It mentions the save_to_file option, which guides when to use file output vs base64. However, it doesn't provide explicit when-to-use vs alternatives, such as when to use get_session_status instead, or any prerequisites like the session being active. The context is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status of a Kasm session.
| Name | Required | Description | Default |
|---|---|---|---|
| kasm_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Get' signals a read-only, non-mutating operation, which is useful. It does not describe possible status values, error behavior, auth requirements, or the shape of the response, leaving gaps in transparency.
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 short sentence with no fluff or redundant restatement. The verb and object are front-loaded, and every word contributes meaning.
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 one-parameter read-only getter, the description is minimally viable: an agent can infer the operation and the required kasm_id from schema. It lacks detail about what statuses are returned, error conditions, and where kasm_id comes from, which would make it more 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?
Schema description coverage is 0%, and the description does not explain kasm_id at all. The property name and title are self-explanatory enough to guess that it is a session identifier, but the description adds no semantic 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 uses the specific verb 'Get' with a clear resource, 'the current status of a Kasm session,' so an agent understands the core operation. It distinguishes this from lifecycle siblings like create/destroy/pause/resume, though it does not explicitly contrast with list_user_sessions.
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 phrase 'current status' implies the tool is for checking a session's state, which provides some usage context. However, it does not state when to prefer this over list_user_sessions, nor does it mention prerequisites such as obtaining kasm_id from create/list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active sessions for the configured user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly signals a read-only listing operation and limits results to 'active' sessions, but it does not disclose output shape, authentication implications, or whether 'configured user' refers to an ambient configuration.
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, front-loaded sentence with no filler or redundant phrasing. Every word contributes to the operational meaning.
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 zero-parameter, read-only enumeration tool, this description is mostly sufficient for an agent to call it correctly. It lacks a brief note about return values or the meaning of 'configured user,' but those are not critical blockers for simple invocation.
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 tool has zero parameters, so the schema already covers everything. The description still adds value by specifying the implicit subject of the operation ('the configured user'), making invocation semantics clearer than the empty schema alone.
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 names a specific operation ('List'), a specific resource ('sessions'), and a scope ('active sessions for the configured user'). This distinguishes it from the create/destroy/pause/resume sibling tools, though it does not explicitly contrast with get_session_status or clarify who the 'configured user' is.
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 intended use is implied: use this tool when you need to enumerate active sessions. However, there is no explicit when-to-use guidance or alternative routing, so the agent must infer the usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a Kasm session.
| Name | Required | Description | Default |
|---|---|---|---|
| kasm_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Pause' implies a state change, but the description does not disclose behavioral traits such as whether the session becomes suspended, whether resources are freed, or whether the session can be resumed later. This is a significant gap for a state-changing operation.
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 short sentence), but it is under-specified. There is no additional structure or detail, and the single sentence does not provide actionable information beyond the basic action.
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 has no annotations and no output schema, and given the existence of lifecycle-related siblings (destroy, resume), the description is critically inadequate. An agent is missing essential context about side effects, reversibility, and preconditions, making it impossible to call safely and correctly.
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%, meaning the schema query parameters have no descriptions. The description adds no meaning beyond the parameter name 'kasm_id' – it does not explain what a Kasm ID is, how to obtain it, or its format. With a single parameter, the description should clearly compensate, but it does not.
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 states a clear verb and resource ('Pause a Kasm session'), which is better than a tautology. However, it does not distinguish from siblings like 'resume' or 'destroy', and the term 'pause' is not further elaborated (e.g., what state it transitions to).
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 provides no guidance on when to use this tool versus alternatives. For instance, does pausing differ from destroying? The sibling tools list suggests related lifecycle operations, but no context is offered. An agent cannot determine if pause is reversible or if it affects session resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a paused Kasm session.
| Name | Required | Description | Default |
|---|---|---|---|
| kasm_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys a state transition and the precondition that the session must be paused, but it does not disclose side effects, failure behavior, permissions, or what happens if the session is not in a resumable state.
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, front-loaded sentence with no filler. It states the verb and resource directly and earns its place without redundancy.
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 one-parameter lifecycle action, the core operation is clear, but the description leaves validity conditions, return behavior, and error cases to inference. The sibling tool list provides some domain context, but the description alone is only minimally adequate.
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 description adds no explanation of the kasm_id parameter, and schema description coverage is 0%, so the description was expected to compensate. The parameter name is self-explanatory enough to partially mitigate the gap, but the description does not explicitly map kasm_id to the session being resumed.
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 the specific verb 'resume' with the resource 'Kasm session' and the qualifier 'paused,' making the operation unambiguous. It is clearly distinct from sibling tools like pause_kasm_session and destroy_kasm_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 phrase 'paused Kasm session' implies this tool is for sessions that are currently paused, but it does not explicitly say when to use it instead of alternatives or what to do if the session is already running or destroyed. The usage context is implied rather than fully stated.
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.
v0.1.0create_kasm_sessiondestroy_kasm_sessionexecute_kasm_commandget_available_workspacesget_session_screenshotget_session_statusget_share_linklist_user_sessionspause_kasm_sessionresume_kasm_sessionScored across 10 tools
Each tool targets a distinct action or resource: lifecycle operations (create/pause/resume/destroy), status/list, share link, screenshot, command execution, and workspace listing. No two tools appear to overlap in purpose.
Tool names mostly follow verb_noun in snake_case (create_kasm_session, destroy_kasm_session, pause_kasm_session, resume_kasm_session). Minor inconsistency exists: some use 'kasm_session' while others use just 'session' (get_session_status, get_session_screenshot) and 'user_sessions' (list_user_sessions), but the pattern remains predictable.
Ten tools is a well-scoped count for a Kasm session management server. Each tool provides a meaningful operation without redundant or unnecessary functions, making it neither too thin nor too heavy.
The toolset covers the main session lifecycle (create, destroy, pause, resume, status, list) plus sharing, screenshots, command execution, and available workspaces. Minor gaps exist, such as no update/rename session or share revocation, but the core workflows for Kasm session management are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Give your AI agents the tools to build, manage, and run automation workflows.
Manage Rackspace Spot Kubernetes Cloudspaces, node pools, and VMs from your AI assistant.
