io.github.flujo-app/mcp-virtual-computer

Official

by flujo-app

Overview Schema Related Servers Score Discussions

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.4
Disambiguation4/5
Most 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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-virtual-computer MCP server](https://glama.ai/mcp/servers/flujo-app/mcp-virtual-computer/badges/card.svg)](https://glama.ai/mcp/servers/flujo-app/mcp-virtual-computer)

Score Badge

Copy to your README.md:

[![mcp-virtual-computer MCP server](https://glama.ai/mcp/servers/flujo-app/mcp-virtual-computer/badges/score.svg)](https://glama.ai/mcp/servers/flujo-app/mcp-virtual-computer)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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