This server gives an AI agent a persistent Docker virtual computer with a viewable desktop, file system access, command execution, and optional lifecycle/network controls.
Execute shell commands in a persistent Debian Docker container via terminal_execute, including stdin, args, working directory, and timeout options.
Open an interactive virtual computer UI with computer_ui, returning a browser-accessible URL and MCP resource URI.
Manage files using read_file, write_file, edit_file (exact match or replace all), and list_directory, all relative to /workspace or absolute paths.
Check runtime status with runtime_status to monitor lazy container setup.
Control network access dynamically with set_network_access (enable/disable real network).
Toggle desktop environment with set_desktop_environment (virtual vs real Xfce desktop).
When the real desktop is enabled, additionally get screen/accessibility snapshots via look_at_screen, interact via click, type, and scroll, and manage Xfce windows with list/switch/move/maximize/restore/minimize/close tools.
Access live resources like computer://screen/current.png and computer://screen/accessibility.json.
Lifecycle controls can be exposed to the model by setting EXPOSE_LIFECYCLE_TOOLS=true; by default they remain app-only.
Provides a persistent Dockerized computer, allowing command execution in the configured container and UTF-8 file read/write/edit operations.
Enables desktop automation for an Xfce environment, including screen capture, accessibility tree inspection, clicking, typing, scrolling, and window management.
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., "@io.github.flujo-app/mcp-virtual-computer List the files in /workspace and open the first text file"
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.
A VM for your agent. And for you.
click the mug to switch between a virtual desktop or a real one
unplug the network cable and cut network access
use the computer screen like a normal screen
copy and paste text between the host browser and the Xfce desktop
model can use terminal, create/read/edit files, see the screen, click, type
little fun thing: if either you or the llm types text, you see that on the keyboard; if one uses the cursor, you see the mouse move on the table.
automatically installs Docker Desktop on Windows for local mode, or flyctl for Fly mode
{
"mcpServers": {
"virtual-computer": {
"command": "uvx",
"args": ["mcp-virtual-computer"],
"env": {
"COMPUTER_ID": "agent-workstation",
"DESKTOP_ENVIRONMENT": "true",
"NETWORK_ACCESS": "true",
"AUTO_INSTALL_DOCKER": "true",
"EXPOSE_LIFECYCLE_TOOLS": "false"
}
}
}
}On a fresh machine, start the MCP once, run the exact flyctl auth login command shown by its error, and restart the MCP client
{
"mcpServers": {
"virtual-computer-fly": {
"command": "uvx",
"args": ["mcp-virtual-computer", "--backend", "fly"],
"env": {
"COMPUTER_ID": "agent-workstation",
"DESKTOP_ENVIRONMENT": "true",
"NETWORK_ACCESS": "true",
"AUTO_INSTALL_FLYCTL": "true",
"EXPOSE_LIFECYCLE_TOOLS": "false"
}
}
}
}Related MCP server: Docker MCP Server
terminal_execute — run a command in the configured Docker container or Fly Machine.
read_file — read a UTF-8 text file relative to /workspace or by absolute path.
write_file — atomically write a UTF-8 text file.
edit_file — replace one exact text match, or all matches when requested.
computer_ui — open or attach the Three.js computer view. Its result includes
both the MCP App resource_uri and a real loopback url/dashboard_url that
opens in an external browser, including for stdio clients.
DESKTOP_ENVIRONMENT defaults to true. With the real desktop enabled it
additionally exposes:
look_at_screen — return the current PNG framebuffer, AT-SPI snapshot, or both.
click, type, and scroll — interact by AT-SPI element reference or coordinates.
list_windows and switch_window — enumerate and activate real Xfce windows.
move_window, maximize_window, restore_window, minimize_window, and close_window — control a selected window by ID, title, or class.
computer://screen/current.png — current live framebuffer resource.
computer://screen/accessibility.json — Playwright-like AT-SPI tree with element refs, roles, names, actions, focus state, and screen bounds.
The MCP App can always call runtime_status, set_network_access, and set_desktop_environment. Set EXPOSE_LIFECYCLE_TOOLS=true to additionally expose those lifecycle controls to the model; they remain model-hidden by default.
Fly mode builds the bundled Xfce image with Fly's remote builder and deploys it as one permanent Machine. The root filesystem and /workspace survive MCP restarts, and the Three.js screen uses the same noVNC desktop through Fly's HTTPS/WebSocket proxy.
This is the Xfce framebuffer returned by look_at_screen from a deployed Fly Machine. The same live desktop appears on the rendered computer after computer_ui connects to VNC:
No app name, region, CPU size, memory size, Docker installation, or VNC configuration is required.
The package's MCP Registry declaration, including the docker and fly backend choices, is in server.json. See Fly setup for the complete first-run and authentication flow.
On first use, virtual-computer finds fly/flyctl or downloads the current official release to ~/.fly/bin. It uses a cached fly auth login session or FLY_API_TOKEN, selects the personal organization when available, creates and remembers a generated app, lets Fly choose the closest placement, and defaults to one shared CPU with 1 GB RAM.
Authentication is the only unavoidable account step. On a fresh machine, start the MCP once, run the exact flyctl auth login command shown by its error, and restart the MCP client. The first computer call can take several minutes while Fly remotely builds Xfce. Later starts attach to the same Machine.
Optional overrides remain available as FLY_ORG, FLY_APP_NAME, FLY_REGION, FLY_API_TOKEN, and the --fly-* flags. Set AUTO_INSTALL_FLYCTL=false to require a preinstalled CLI. Deleting or factory-resetting the computer destroys its persistent Fly root filesystem; ordinary MCP shutdown leaves the permanent Machine running. Stop or delete it from Fly when you no longer want it to incur usage.
MIT licensed. This project is a persistent-computer fork of Kilntainers with Docker and Fly backends.
Open the interactive Three.js laptop and its computer screen.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the screen is 'interactive' but says nothing about what happens after opening, whether the call blocks, what the user sees, or any side effects. For an opening/display tool with zero annotation coverage, this is a significant transparency gap.
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?
A single sentence with the action verb front-loaded and no filler. Every word contributes — 'interactive,' 'Three.js,' 'laptop,' and 'computer screen' all carry meaning. Length is appropriate for the tool's zero-argument simplicity.
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 tool with no output schema, the description is workable and probably invokable as-is. However, it omits what the agent or user experiences after invocation (e.g., whether an interactive session is handed off) and whether any confirmation is returned. Adequate but leaves behavioral gaps an agent would want resolved.
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 there is nothing for the description to document beyond what the (trivially complete) empty schema already conveys. The baseline of 4 applies because parameter semantics cannot add value where no parameters exist.
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 verb ('Open') and a specific resource ('the interactive Three.js laptop and its computer screen'), with the 'Three.js' detail adding useful specificity. It is clearly distinct from the terminal/file/runtime siblings, though it does not explicitly differentiate itself from set_desktop_environment, which a literal-minded agent could conflate with a UI-opening tool.
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 on when to use this tool versus alternatives. The sibling set_desktop_environment overlaps conceptually with 'opening' a visual environment, yet the description offers no exclusions or routing hints. An agent is left to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace exact UTF-8 text and show it being selected, overwritten, and saved.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | UTF-8 text file path, absolute or relative to /workspace. | |
| new_text | Yes | Replacement UTF-8 text. | |
| old_text | Yes | Exact text to select and replace; include context if ambiguous. | |
| replace_all | No | Replace every exact match instead of requiring one match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the replacement will be visually shown, but it does not explain matching failure behavior, whether changes are reversible, permission requirements, or what happens when old_text is ambiguous or absent. 'Replace' is essentially the operation implied by the tool name.
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 efficient sentence that front-loads the core action ('Replace exact UTF-8 text') and adds a concise behavioral detail about the visual selection and save process. No unnecessary padding is present.
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?
The tool is moderately simple and the schema thoroughly documents parameters, but there is no output schema and no annotation context. The description does not cover failure modes, return values, or how the tool behaves when old_text is not found, leaving some important operational context unstated.
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 100%, so the schema already documents all parameters including path, old_text, new_text, and replace_all. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
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 identifies the action ('Replace exact UTF-8 text') and the resource (a UTF-8 text file). It distinguishes this from more general file writing by emphasizing exact text replacement, though it does not explicitly name sibling alternatives.
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 the tool is for targeted in-place text replacement, which suggests when to use it over write_file, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The guidance is implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a Docker directory for the interactive virtual Explorer.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path, absolute or relative to /workspace. | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' clearly signals a non-mutating read operation, but the description does not disclose return format, hidden-file inclusion, recursion, or error behavior. It is minimally adequate for a simple listing tool.
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 redundancy. The action and resource are front-loaded, and every phrase contributes to identifying the tool's purpose.
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?
The tool is simple and has one optional parameter, so the description is nearly sufficient. However, there is no output schema and no note about return values or behavior with invalid paths, leaving an agent to infer directory-listing semantics.
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 100%, so the path parameter is already documented as absolute or relative to /workspace. The description adds 'Docker directory' as light context but does not meaningfully enrich the parameter semantics beyond what the schema provides.
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 resource ('a Docker directory'), making the core action clear. It is distinguishable from sibling read/write/edit and terminal tools, though 'interactive virtual Explorer' is vague and does not clarify recursion or output detail.
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 about when to use this tool versus alternatives such as terminal_execute or read_file. The description does not state any exclusions or context that would help an agent choose it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a UTF-8 text file and show it being opened and scrolled on the virtual computer.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | UTF-8 text file path, absolute or relative to /workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that it reads and shows the file being opened and scrolled, which implies a read-only, non-destructive operation, but it does not clarify whether the content is returned to the agent, how errors are handled, or if any special permissions are needed. The visual 'show' behavior is a useful but incomplete disclosure.
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, efficient sentence without redundancy. It is relatively front-loaded, stating the primary action and the distinctive visual behavior. It could be slightly more structured, but it is appropriately concise for a simple tool.
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 one parameter fully documented in the schema and no output schema, the description is mostly sufficient. However, the phrase 'show it being opened and scrolled' is ambiguous—it does not clearly state whether the tool returns the file content for programmatic use or merely displays it on the virtual screen, which could affect agent behavior when selecting and using the tool. This is a notable gap given the sibling tools include write/edit operations.
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 100% for the single parameter 'path', which already documents it as a UTF-8 text file path relative to /workspace. The description adds no additional semantic detail beyond what the schema provides, so it meets the baseline for high coverage but does not go further.
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 'Read' and the resource 'UTF-8 text file', plus an extra behavior (showing it opened/scrolled). It distinguishes from siblings like write_file and edit_file implicitly by focusing on reading, though it doesn't explicitly name alternatives. The virtual computer context is unique enough to set it apart from terminal_execute or list_directory.
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 mention of when to use this tool versus alternatives like terminal_execute (which could also cat a file) or list_directory. There is no explicit guidance, no exclusions, and no conditions. The usage context is only implied by the tool's name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read genuine lazy container-runtime setup progress.
| 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 full burden, and it only states 'Read', which implies a non-mutating operation. It does not explain whether the call blocks, triggers lazy initialization, or what progress looks like, and 'genuine lazy' is unexplained.
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 short and front-loaded, but the word 'genuine' is unnecessary noise and 'lazy' is ambiguous. It is appropriately sized for a zero-parameter tool, but not 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?
There is no output schema, so the description should explain how progress is reported or when the setup is considered complete. It provides neither, leaving the agent unable to interpret the result or decide when to call the 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 tool has zero parameters, so there is nothing for the description to add beyond the schema. Baseline 4 applies because schema coverage is effectively complete.
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 verb ('Read') and a clear resource ('container-runtime setup progress'), which is enough to distinguish it from unrelated siblings like terminal_execute and read_file. The odd phrase 'genuine lazy' adds confusion but does not obscure the core purpose.
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. There is no mention of when to poll this status, what triggers setup, or how this tool relates to terminal_execute or other setup commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the running computer between virtual and Xfce desktops.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | Use a real Xfce desktop instead of the virtual desktop. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It only says 'Switch', implying a state change, but does not mention side effects, reversibility, impact on running sessions, or whether Xfce must already be available. This is a significant gap for a mutation tool.
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?
A single sentence with no filler, front-loading the action and both target states. Every word earns its place for the small amount of information conveyed.
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 state-changing tool with no annotations and no output schema, the description is under-specified. It fails to communicate what happens to the current desktop session, whether the switch is reversible, or what a successful invocation looks like. The simple boolean schema reduces complexity, but key operational context is still 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 description coverage is 100%, and the boolean parameter's description already explains that true means 'Use a real Xfce desktop instead of the virtual desktop.' The tool description aligns with this but adds no additional semantic detail beyond what the schema provides.
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 verb ('Switch'), a clear resource ('the running computer'), and the exact scope ('between virtual and Xfce desktops'). This distinguishes it from sibling tools like terminal_execute or computer_ui, which target different concerns, without needing to inspect schemas.
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, nor are there any exclusions or prerequisites. An agent can infer the tool is for desktop environment switching, but nothing in the description helps decide between this and related computer-control tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the running Docker computer's real network access.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | Whether the Docker computer may access the network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavioral traits. 'Change' implies mutation, but the description does not say whether the change is persistent, what happens to active connections, whether it requires a restart, or what 'real' network access means versus any other kind. This is a significant gap for a tool that can sever connectivity.
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 wasted words. It front-loads the action and resource. It could earn a 5 with a brief consequence note, but as written it is efficient and on point.
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?
The tool is a network toggle with no annotations and no output schema. The description omits important context: what 'real' network access means, whether the change is reversible, whether it affects the entire Docker computer or just one container, and what impact it has on running processes. For a tool that can disrupt connectivity, this is incomplete.
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 fully documents the single parameter 'enabled' with a clear description. The tool description adds little semantic value beyond labeling the access as 'real', which is not explained. With 100% schema coverage, the baseline of 3 is appropriate.
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 ('change') and resource ('the running Docker computer's real network access'). It is distinguishable from all sibling tools, none of which deal with network access. The qualifier 'real' is slightly ambiguous but does not obscure the core purpose.
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 on when to use this tool versus alternatives. While the sibling list makes it obvious this is the only network-related tool, the description does not mention prerequisites, expected side effects, or conditions under which enabling/disabling network access is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a shell command in one persistent Debian Docker computer. Commands run in bash. Each call is independent — no state (shell variables, working directory) persists between calls (however filesystem does persist). Use the working_directory parameter or chain commands with && to control execution context.
To write files or pass data without shell escaping, use the stdin parameter (e.g., command="cat > file.txt" with content in stdin). Commands time out after 120 seconds by default (override with the timeout parameter for long-running operations).
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | List of arguments for direct execution (mutually exclusive with command). | |
| stdin | No | Content to pipe to stdin. | |
| command | No | Shell command string (mutually exclusive with args). | |
| timeout | No | Timeout in seconds (defaults to server config). | |
| working_directory | No | Working directory for the command (must be absolute). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that 'Each call is independent — no state (shell variables, working directory) persists between calls (however filesystem does persist),' and that commands time out after 120 seconds by default. This gives agents a clear model of the execution environment. It does not describe error handling or exit code behavior, but the core behavioral traits are well covered.
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 compact yet thorough. The first sentence states the purpose, followed by essential behavioral notes, then parameter-specific guidance. Each sentence serves a purpose—there is no filler or repetition. Paragraph breaks separate high-level behavior from parameter usage, making it easy to scan.
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 terminal tool with 5 parameters and no output schema, the description covers the key operational aspects: persistent filesystem, stateless calls, working directory control, stdin usage, and timeout override. It does not explicitly mention how output is returned (e.g., stdout/stderr captured in response), but this is often assumed for such tools. Given the complexity and the absence of annotations, the description provides sufficient context for correct 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema: it explains the rationale for `working_directory` (because state does not persist), demonstrates stdin usage with a concrete example, and clarifies the default timeout (120s) vs. the hidden server config default. It also reinforces the mutual exclusivity of `command` and `args` implicitly. These insights help agents select and use parameters correctly.
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 core function: 'Execute a shell command in one persistent Debian Docker computer.' It identifies the specific verb (execute), resource (shell command), and environment (Debian Docker), and immediately notes 'Commands run in bash.' This is unambiguous and distinct from the sibling tools, which handle UI, file operations, status, and network—none of which overlap with general shell execution.
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 concrete usage guidance: it explains how to control execution context with 'working_directory parameter or chain commands with &&,' and recommends using stdin for writing files without escaping. It also mentions overriding the timeout for long-running operations. However, it does not explicitly state when to use this tool over specific siblings (e.g., 'use read_file/write_file for direct file access instead of shell commands'), though the context makes this implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a UTF-8 text file and show it being typed and saved on the virtual computer.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | UTF-8 text file path, absolute or relative to /workspace. | |
| content | Yes | Complete UTF-8 text to save. | |
| create_parent_directories | No | Create missing parent folders before saving. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does mention the unusual 'show it being typed and saved' animation, which is a behavioral trait. However, it does not disclose whether the tool overwrites existing files, requires specific permissions, or what happens on failure. For a simple write operation, this is partial 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 sentence with no filler. It front-loads the core purpose ('write a UTF-8 text file') and then adds the visual detail. Every word earns its place; it is appropriately brief for a straightforward tool.
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?
The tool is simple (3 parameters, no output schema), and the description covers the basic purpose and a unique behavior. However, it omits overwrite semantics and does not explicitly differentiate from edit_file, which is important context for correct selection. Given the tool's low complexity, the description is adequate but not comprehensive.
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 100% – all three parameters (path, content, create_parent_directories) have descriptions. The tool description adds no new information about parameters, only restating 'UTF-8' which is already in the schema. Baseline 3 is appropriate as the schema carries the full load.
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 ('write') and resource ('UTF-8 text file'), and adds a distinctive visual behavior ('show it being typed and saved on the virtual computer') that sets it apart from siblings like read_file and edit_file. An agent can immediately tell this tool creates a new file with visual feedback rather than reading or editing.
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 this tool is for writing new files, but it does not explicitly state when to use it versus edit_file or terminal_execute. There is no mention of exclusions or alternatives, leaving the agent to infer usage from sibling names rather than receive direct guidance.
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.2.4computer_uiedit_filelist_directoryread_fileruntime_statusset_desktop_environmentset_network_accessterminal_executewrite_fileMost tools target clearly distinct actions: shell execution, file read/write/edit/list, network, desktop, UI, and status. Some overlap exists between terminal_execute and the dedicated file tools, since terminal commands can also create and edit files, but the descriptions clarify their intended specializations.
The majority follow a verb_noun pattern (read_file, write_file, list_directory, edit_file, set_network_access, set_desktop_environment), but terminal_execute, computer_ui, and runtime_status break that pattern with noun-first or noun-only names. The inconsistency is noticeable but not chaotic.
Nine tools is a well-scoped set for a virtual computer MCP server. Each tool addresses a distinct part of the workflow: terminal access, file operations, runtime status, UI launch, and configuration switches, with no obvious bloat.
The tool surface covers the main lifecycle: executing commands, reading/writing/editing/listing files, controlling network and desktop environment, and checking runtime status. Missing file operations like delete or rename are not critical because terminal_execute can handle them, but they are minor gaps in the dedicated file-tool set.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate, edit, and deploy immersive 3D/WebGL web projects from any MCP assistant.
Build a real 3D website by chatting: pages, models and text in space, published to a live URL.
Remote shell and detached long-running jobs on your own machines — no SSH, open ports or VPN.
On-demand GPU nodes for agents: create nodes, run commands, and submit jobs, billed by the minute.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flujo-app/mcp-virtual-computer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
