smol-mcp

Overview Schema Source Related Servers Score Discussions Admin

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a specific resource and action: machine lifecycle, command execution, file transfer, and image caching are cleanly separated. run-command and run-once may seem similar at first, but the descriptions clearly distinguish running in an existing machine from a throwaway one-shot workflow.
Naming Consistency4/5
Tool names mostly follow a consistent lowercase hyphenated verb-noun pattern (list-machines, get-machine, create-machine, read-file, write-file). Minor deviations like machine-logs (noun-noun) and run-once (verb-adverb) slightly break the pattern but do not cause confusion.
Tool Count5/5
With 11 tools, the server is well-scoped for managing machines, running commands, transferring files, and pulling images. Each tool adds meaningful capability without redundancy.
Completeness4/5
The surface covers the core machine lifecycle (create, list, get, stop, delete), command execution, file transfer, image pulling, and logs. Minor gaps exist, such as no explicit machine update/resize or image listing, but agents can accomplish the main workflows without dead ends.
Average 3.4/5 across 11 of 11 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 52 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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 provided, the description carries the full burden of behavioral disclosure. It states the action and the 'local only' scope, but it does not disclose side effects (e.g., whether existing cache entries are overwritten), network requirements, authentication needs, or failure modes. For a pull operation this is a notable gap.
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 that is concise and front-loads the core action. It avoids unnecessary detail, though it could have included a bit more behavioral context without sacrificing brevity. It is appropriately sized for a simple pull operation.
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?
Given the tool's moderate complexity (3 parameters, an enum, and an output schema) and the complete absence of annotations, the description is too sparse. It does not explain return values, error conditions, or the distinction between local and cloud behavior beyond the one-word 'Local only'. An agent would have to rely on the schema and runtime feedback to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'name' and 'target' but leaves 'image' undocumented. The description adds no parameter-level detail beyond what the schema already provides, and it fails to compensate for the missing 'image' description. With only 67% schema coverage, the description should have clarified the image parameter but did not.
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 ('pull') and resource ('image') with a destination ('into a running machine's local cache'). It also adds a scoping note ('Local only') that distinguishes it from potential cloud operations. However, since no sibling tool performs pulling, the differentiation is implicit rather than explicit.
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?
The description provides minimal context about when to use this tool: it implies it is for pulling into a running machine's local cache. There is no explicit guidance on when not to use it or mention of alternatives, even though the target parameter distinguishes local vs cloud. The agent is left to infer that this is the only tool for image pulling.
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?
The description adds genuine behavioral nuance: 'exitCode comes from the guest; a failing command is not an error.' This is valuable beyond the schema because it tells agents to treat a non-zero exit code as data, not failure. However, it does not explain stdout/stderr delivery, behavior for a stopped machine, or command serialization.
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?
Two sentences, no redundancy. The core action is stated in the first sentence, and the subtle exit-code behavior is given in the second. Every word contributes.
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?
An output schema exists, so return values are not required in the description. The description captures the essential operation and the exit-code nuance, but gives no guidance on selecting this tool over siblings and no parameter hints. Not wholesale but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers no parameter-level information. Schema description coverage is only 57% (the schema covers env, command, target), so the description would need to add meaning for ambiguous parameters like stdin, workdir, and timeoutSecs, but it does not.
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?
States a specific verb ('Run a command') and resource ('in a running machine'). This clearly separates it from machine creation/deletion tools, and the phrase 'running machine' distinguishes it from likely one-shot sibling 'run-once', though that distinction is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'run-once' or prerequisites such as 'machine must be running'. The description shows the intended context in passing but does not explicitly state when not to use the command.
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 merely says 'Read' without explaining side effects (e.g., read-only), error behavior, permission requirements, or how encoding affects the response. The schema hints at target and encoding, but the description itself is silent.
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 zero waste, and the core action is front-loaded. It is appropriately brief given the rich input schema and the presence of an output schema.
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 description plus schema define the required parameters and target, and an output schema exists to explain return values. However, there is no mention of edge cases like file-not-found, permission issues, or encoding's practical effect on the response, leaving noticeable gaps for an agent.
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 75%, and the schema already documents name, path, and target. The description adds no parameter-specific meaning. Encoding lacks an explanation, but its enum values are somewhat self-explanatory, so the schema carries the load adequately.
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 action ('Read a file from a machine') with a clear verb and resource. It is distinct from siblings like write-file and machine-logs, though it does not explicitly name an alternative or contrast with related tools.
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 or alternatives are mentioned. The description only says what the tool does, not when to prefer it over run-command, get-machine, or machine-logs. There is no guidance on selecting local vs cloud target or prerequisites.
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 carries the full burden of behavioral disclosure, but it does not explicitly state that the operation is read-only, has no side effects, or any auth/rate-limit implications. 'Get' implies retrieval, but does not add beyond the tool name or state that the machine is not modified, which is a notable gap for an unannotated tool.
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, direct sentence that communicates the core function without fluff. It is slightly under-specified for a tool with two inputs, but it is not terse to the point of confusion and earns its place.
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 has a knowledgeable output schema and fully documented parameters, so the description does not need to explain return values. However, the absence of any usage context (e.g., when to call this vs. an alternative) makes it less complete for an agent facing several similar sibling tools.
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 input schema already provides meaning for 'name' and 'target'. The description does not add parameter semantics beyond what the schema gives, and therefore appropriately sits at the baseline of 3.
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 ('Get'), a specific resource ('one machine'), and the nature of the result ('state and resources'). The singular 'one machine' cleanly distinguishes it from sibling list-machines, and 'state and resources' separates it from machine-logs.
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?
The description gives no guidance on when to use this tool versus alternatives such as list-machines or machine-logs. There is no mention of scenarios for single-machine inspection, no exclusions, and no conditional guidance for choosing a target (local vs cloud).
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?
Annotations are not provided, so the description carries the full burden of behavioral disclosure. The description only says 'Tail the machine's console log. Local only.' It does not disclose that tailing is a continuous streaming operation (potentially long-running), whether it requires specific permissions, how it handles log rotation, or what the output format is. For a tool that likely streams data, this is a significant 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?
The description is extremely concise at six words, and it is front-loaded with the primary action ('Tail the machine's console log') followed by the scope restriction ('Local only'). Every word earns its place; there is no fluff or repetition.
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?
Given that there is an output schema and the tool complexity is moderate (tail command with 3 params), the description is incomplete. It does not explain what the output looks like (even though an output schema exists, it may not fully capture streaming behavior), nor does it address how the tail parameter affects the call. For a tail operation, one would expect details on streaming behavior or termination conditions, which are 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 67%. The schema already documents the 'name' parameter (machine name) and 'target' parameter (local vs cloud). The description adds the qualifier 'Local only' which reinforces that the target is local, but it does not add new meaning to the 'tail' parameter, which lacks a description in the schema. With 67% coverage, the description partially compensates but does not fully clarify the 'tail' parameter's meaning (number of lines? bytes?).
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 action (tail) and the resource (machine's console log), and specifies 'Local only' to distinguish from cloud targets. This is a specific verb+resource pairing that goes beyond a mere restatement of the name. However, it does not explicitly differentiate from sibling tools like read-file or get-machine, though for an agent the action of tailing is distinct enough from those.
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 mentions 'Local only' which gives a hint about when to use this tool (for local machines), but it does not explicitly state when not to use it or mention alternatives among siblings. It lacks clear guidance on when to prefer this over read-file or get-machine. The sibling tools are numerous, so the absence of explicit exclusions makes this only minimally adequate.
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?
No annotations are provided, so the description carries the full disclosure burden. It only states that machines are listed and does not mention read-only behavior, authentication, connectivity, pagination, or any side effects.
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, front-loaded sentence with no filler. Every word contributes to identifying the operation and scope.
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 simple optional-parameter list operation with an output schema present and a well-documented parameter, the description is nearly sufficient. It lacks behavioral details, but the low complexity and rich schema make it mostly complete.
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 target parameter is fully documented with its enum values and default. The description itself adds no extra parameter meaning beyond what the schema already 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 uses a specific verb ('List') and resource ('machines') and identifies a scope ('on the target'). It is clearly distinct from siblings like get-machine, create-machine, and run-command.
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?
The description gives no guidance about when to use this tool versus alternatives such as get-machine or machine-logs. There is no explicit when-to-use/when-not-to-use context, though the parameter schema explains the local/cloud distinction.
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 must carry disclosure, and it does communicate the create/start/blocking-wait behavior. It does not mention ephemeral-vs-persistent naming, cloud/local target behavior, or that start can be disabled with start=false, so the disclosure is incomplete but not misleading at the default behavior level.
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, presenting a clear sequence: create, start, wait. Every segment earns its place and the core operation is front-loaded.
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?
This is an 11-parameter tool with local/cloud targets, network modes, and lifecycle implications, yet the description gives only the core flow. The rich input schema and output schema compensate substantially, but the tool-level context is still thinner than the complexity warrants.
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 high (82%), so the schema already explains most parameters. The tool description adds no extra parameter semantics beyond 'OCI image' and 'commands', which map to image and cmd but are already documented in the schema.
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+resource ('create a machine from an OCI image') and adds behavioral detail (start it, wait until commands run). It separates the tool from obvious lifecycle siblings like stop-machine and delete-machine, though it does not explicitly distinguish it from run-once.
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 intended use is implied: you want a machine created from an image, started, and ready for commands. It gives no explicit when-not-to-use guidance or alternative routing (e.g., run-once for one-shot tasks), so an agent must infer the boundary between this and run-once.
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 carries the behavioral burden. It usefully discloses that running machines can be deleted, but it does not state permanence, cascading resource effects, or confirmation requirements.
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 front-loaded sentence with no filler, redundant phrasing, or repeated keywords from the name. Every word adds information, especially the qualifier 'running or not.'
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 simple destructive operation with two well-documented parameters and an output schema, the description covers the essential action and state condition. It could be stronger with a note that deletion is permanent or irreversible, but the current wording is minimally adequate.
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 already documents both parameters, including the target enum and default; the description adds no parameter-level meaning. With 100% schema parameter coverage, this is an acceptable baseline.
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 verb 'Delete' plus the object 'machine' clearly identifies the operation, and 'running or not' adds a meaningful scope qualifier. It does not explicitly distinguish itself from the sibling 'stop-machine', though the destructive verb makes the contrast implicit.
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 phrase 'running or not' gives useful context that this operation applies regardless of machine state, which helps an agent decide when deletion is allowed. However, it provides no explicit guidance about when to prefer stop-machine versus delete-machine.
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 carries full burden. It discloses the waiting behavior, which is a useful behavioral trait beyond the schema. However, it doesn't mention whether the file is overwritten if it exists, permissions, or any side effects. The description adds some value but could disclose more about the operation's effects.
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?
Two sentences, clear and to the point. The key behavior (waiting) is front-loaded after the primary action. No fluff, every word adds meaning.
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?
Given the tool's simplicity (write a file) and the presence of an output schema, the description covers timing behavior, which is the critical gap. It doesn't mention overwrite semantics or error conditions, but for a basic write operation, this is fairly complete. The output schema likely covers return values, so no need to explain those.
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 schema coverage is 60%, meaning two parameters (content and encoding) lack descriptions in the schema. The description does not add semantics for these, but the schema already covers name, path, and target well. Since content and encoding are straightforward, the description doesn't need to add much. The description does add the nuance that path should be 'absolute', which is helpful beyond the schema's 'Absolute path' description.
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 the verb 'Write a file' and the resource 'into a machine', clearly identifying the primary action. It distinguishes from siblings like read-file and run-command. However, it doesn't explicitly note that this is for a remote machine vs local, but the context of 'machine' and sibling names make it clear enough.
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 mentions 'Waits until the workload container runs so the file is not lost', providing a timing context that implies when this is safe to use. It doesn't explicitly state when not to use it or compare to alternatives like run-command for writing files. The guidance is implied but not exhaustive.
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 burden of behavioral disclosure. It does disclose the key reversible outcome ('can be started again'), which is useful, but it does not mention what happens if the machine is already stopped, whether resources are released, or any side effects beyond the stop operation.
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?
One concise sentence front-loads the core action and adds a relevant parenthetical about restartability. There is no wasted text.
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 simple lifecycle command with a fully documented schema and output schema present, the description is nearly complete. It lacks only minor details like behavior when the machine is already stopped, but nothing essential is missing for a correct call.
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 fully documents both 'name' and 'target'. The description adds no additional parameter semantics, so the baseline of 3 applies.
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 ('Stop') and resource ('running machine'), and the parenthetical clarifies that stopping is reversible. This clearly distinguishes it from delete-machine and create-machine without ambiguity.
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 indicates this tool is for stopping a running machine, and it names create-machine as the way to start it again. It doesn't explicitly state when NOT to use this tool, but the context and alternative are clear.
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, the description carries full burden. It discloses the guarantee of deletion even on timeout, which is a strong behavioral trait. It also implies resource creation and termination. It does not mention failure modes, such as what happens if creation fails or if the command fails, but the core lifecycle is transparent. The description adds significant value beyond the schema.
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, concise sentence that front-loads the primary action and lifecycle. Every element serves a purpose: 'throwaway' signals no persistent state, 'run one command' specifies the scope, and 'delete even on timeout' highlights a key guarantee. No filler; it's efficient and easily parseable.
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?
Given the tool's complexity (12 params, nested objects, output schema), the description provides essential lifecycle semantics but leaves many parameter-specific details to the schema. Since an output schema exists, return values are documented. The description covers the unique behavioral aspect (deletion) and the core workflow, which is sufficient for an agent to select and invoke it correctly. It does not list replacement logic or edge cases, but these are not always necessary. With the schema and output schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, not high, so the description must compensate. Many parameters (env, cpus, image, stdin, target, command, network, workdir, memoryMb, allowCidrs, allowHosts, timeoutSecs) are already described in the schema, but the description adds critical value by noting that 'allowCidrs' and 'allowHosts' override network, and that 'blocked' egress behaves differently on local vs cloud. This is crucial context not in the schema. Even with some schema coverage, this extra clarification is valuable.
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 purpose with a specific verb ('run'), resource ('machine'), and lifecycle semantics ('create', 'run one command', 'delete'). It distinguishes itself from siblings by emphasizing the throwaway nature and the deletion guarantee even on timeout. The description is dense but conveys the core workflow.
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 usage for one-off commands without cleanup, but it doesn't explicitly contrast with run-command or create-machine. It mentions deletion on timeout, which hints at when to prefer this tool (need for cleanup), but does not provide explicit 'use X instead' guidance. Given five siblings, more explicit routing would improve clarity.
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

smol-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![smol-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/smol-machines/smol-mcp/badges/card.svg)](https://glama.ai/mcp/servers/smol-machines/smol-mcp)

Score Badge

Copy to your README.md:

[![smol-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/smol-machines/smol-mcp/badges/score.svg)](https://glama.ai/mcp/servers/smol-machines/smol-mcp)