Manage and monitor one or many PiKVMs through their web API and root SSH, with confirmations for changes and risky actions.
List configured PiKVMs and inspect version, hardware, health, and status.
Control ATX power, including on, soft/hard off, hard reset, and power/reset button presses.
Take screenshots with optional OCR and save full-size images.
Type text or keyboard shortcuts on the target machine.
Manage the virtual USB drive: status/list images, select ISO/disk, connect/disconnect, download from URL, and remove images.
Read kvmd logs and discover or call PiKVM web API endpoints.
Run read-only SSH health checks and arbitrary SSH commands, with risky commands gated by confirmation.
Read and write allowed PiKVM config files with diff preview, backup, kvmd -m validation, rollback on failure, and read-only disk restoration.
Check, start, restart, reload, enable, disable, or stop PiKVM services.
Target multiple PiKVMs by name, or use all for read-only calls; passwords come from environment variables and secret files are blocked.
Click on "Deploy 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., "@PiKVM MCP take a screenshot of pikvm1 and tell me what's on screen"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP tool that lets Claude look at and configure your PiKVMs.
App side: the PiKVM web API. Power (ATX), screenshots, keyboard, virtual drive (MSD), GPIO, KVM switch, logs.
Server side: SSH as root. Config files, services, health checks.
Many PiKVMs in one tool. Name one, or use all for read-only calls.
Asks before it changes anything.
Every call has a level.
Read. Runs right away.
Change. Needs confirm=true. Claude must ask you first.
Risky. Needs confirm=true and a confirm_phrase. Power off, reset, deleting images, restarting kvmd, stopping services, reboot, package changes.
Also:
Passwords come only from environment variables. They are never saved, shown or logged.
Files with passwords, keys and 2FA secrets are blocked, for reading and writing.
Config writes make a backup, check the file with kvmd -m, and put the old file back if the check fails. The PiKVM disk is set back to read-only afterward.
In multi-PiKVM mode, each PiKVM only gets its own password.
The PiKVM certificate is self-signed, so the tool does not check it by default. Set PIKVM_VERIFY_TLS=true to check it.
SSH host keys are accepted the first time. Fine for a home network.
Related MCP server: MCP Remote Access
App side:
pikvm_servers lists your PiKVMs.
pikvm_info shows version, hardware and health.
pikvm_status shows power, screen, keyboard and mouse, and virtual drive in one go.
pikvm_power controls ATX power.
pikvm_snapshot takes a picture of the target screen. Optional OCR. The PiKVM video stream usually only runs while someone is watching, so if it fails, open the PiKVM web page or VNC first.
pikvm_type types text or a shortcut on the target.
pikvm_msd manages the virtual drive. Select, connect, download an ISO from a URL, remove.
pikvm_log shows the kvmd log.
pikvm_endpoints lists the web API paths.
pikvm_call runs any web API path.
Server side:
pikvm_system_info runs a read-only health check.
pikvm_config_read reads /etc/kvmd/override.yaml and other allowed files.
pikvm_config_write replaces a config file. Shows a diff first.
pikvm_service checks, restarts or stops a service.
pikvm_ssh runs any command.
Get the files: git clone https://github.com/drmogie/pikvm-mcp (or use D:\GitHub-Projects\pikvm-mcp).
Add the entry from claude_desktop_config.example.json to the Claude desktop MCP config.
Fill in the passwords there. Only in that file. Never in this repo.
Restart Claude.
The default PiKVM web login is admin. SSH is root. Use your own passwords.
"env": {
"PIKVM_URL": "https://192.168.1.29",
"PIKVM_PASSWORD": "...",
"PIKVM_SSH_PASSWORD": "..."
}PIKVM_URL, PIKVM_USER (default admin), PIKVM_PASSWORD
PIKVM_SSH_HOST (default: the host in the URL), PIKVM_SSH_PORT, PIKVM_SSH_USER (default root)
PIKVM_SSH_PASSWORD, or PIKVM_SSH_KEY (path to a private key)
PIKVM_VERIFY_TLS, PIKVM_DOWNLOAD_DIR
Several PiKVMs: PIKVM_SERVERS, then PIKVM_URL_<NAME>, PIKVM_PASSWORD_<NAME>, PIKVM_SSH_PASSWORD_<NAME>. <NAME> is the name in capitals with other characters turned into _.
If 2FA is on for the PiKVM web login (the file /etc/kvmd/totp.secret exists), the web API refuses the plain password with a 403 error. Two ways to fix it:
Keep 2FA. Set PIKVM_TOTP_SECRET_<NAME> to the secret. The tool makes the 6 digit code itself. To get the secret, SSH in and run cat /etc/kvmd/totp.secret yourself. This tool will not show it. Paste it only into the Claude desktop config.
Turn 2FA off for that PiKVM (kvmd-totp del over SSH, with the disk set writable). Only do this if you are happy with it.
The PiKVM clock must be right, or the codes will not match.
Built and tested against a fake PiKVM and a fake SSH layer (python tests/test_server.py, python tests/test_ssh_write.py). Tested through a real uvx launch. Not yet tested on a real PiKVM. Please report what breaks.
Not built: uploading image files from your PC to the virtual drive, the PiKVM Switch firmware tools, and Redfish.
MIT
Call any PiKVM web API path (see pikvm_endpoints).
method: GET or POST (DELETE too). path: starts with /api/. params: query options. Reads run right away. Changes need confirm=true after the user says yes. Power off, reset, deleting images and similar also need confirm_phrase equal to the path. Login and websocket paths are blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| path | Yes | ||
| method | Yes | ||
| params | No | ||
| server | No | ||
| confirm | No | ||
| max_chars | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden well by disclosing the read-versus-write confirmation model, the extra phrase requirement for destructive actions, and that login/websocket paths are blocked. It leaves some behavioral details implicit, such as how body content is interpreted and whether errors are returned differently.
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, front-loaded, and organized in functional lines. Every sentence adds operational meaning without repetition.
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?
It covers the critical safety and routing behavior, and an output schema exists so return values need not be explained. However, for an 8-parameter generic API caller with no annotations, the missing body/server/max_chars semantics leave meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains method, path, params, confirm, and confirm_phrase, but says nothing about body, server, or max_chars, leaving important parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and scope: call any PiKVM web API path, with a pointer to pikvm_endpoints for available paths. It is distinguishable as the generic escape hatch, though it does not explicitly contrast itself with dedicated siblings such as pikvm_power or pikvm_snapshot.
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?
It gives clear operational rules: method choices, path must start with /api/, reads execute immediately, changes require confirm=true, and destructive actions require confirm_phrase equal to the path. It does not say when to prefer this generic tool over dedicated sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a PiKVM config file over SSH.
Default is /etc/kvmd/override.yaml, the file where your own settings live. Allowed: text files in /etc/kvmd/, /boot/config.txt, /boot/cmdline.txt, /etc/hostname. Files with passwords, keys or 2FA secrets are blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | /etc/kvmd/override.yaml | |
| server | No | ||
| max_chars | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the SSH transport, the exact allowlist of readable paths, and — critically — that files with passwords, keys, or 2FA secrets are blocked, which tells the agent about failure modes before it calls. It omits auth prerequisites, connection failure behavior, and truncation behavior.
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?
Three short sentences, purpose front-loaded, then default, then constraints. Every sentence adds a new, load-bearing fact with no repetition of the tool name or filler.
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?
An output schema exists, so return values need not be explained. The path and safety envelope are well covered. The remaining gap is the multi-server dimension: 'server' defaults to an empty string with no explanation of what that selects, which matters in a toolset with an explicit pikvm_servers listing 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?
Schema description coverage is 0%, so the description must compensate. It partially does: it documents the meaning and default of 'path' plus the allowed set. However, 'server' (which PiKVM host, meaningful given the pikvm_servers sibling) and 'max_chars' (truncation threshold) are entirely unaddressed in both schema and description, leaving two of three parameters opaque.
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 first sentence states a specific verb and resource ('Read a PiKVM config file over SSH'), which immediately separates it from the mutation sibling pikvm_config_write. It stops short of explicitly naming that sibling or the alternative read surfaces (pikvm_ssh, pikvm_log), so sibling differentiation is implied by the verb rather than stated.
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?
It tells the agent the default target ('/etc/kvmd/override.yaml, the file where your own settings live'), which implies the common use case. But there is no explicit when-to-use versus pikvm_ssh or pikvm_log, and no guidance on when to pass a non-default path beyond the allowed list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace a PiKVM config file over SSH. Needs one PiKVM.
path: same allowed files as pikvm_config_read. content: the WHOLE new file (read it first with pikvm_config_read, change it, send it all back). The first call shows a diff and does nothing. After the user says yes, call again with confirm=true. The tool makes the disk writable, saves a backup next to the file (.bak-date), writes the file, runs "kvmd -m" to check /etc/kvmd/*.yaml files (and puts the old file back if the check fails), then makes the disk read-only again. restart: optional service to restart after a good write, usually kvmd. A restart of kvmd, kvmd-nginx or kvmd-otg also needs confirm_phrase equal to the service name.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| server | No | ||
| confirm | No | ||
| content | Yes | ||
| restart | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it discloses the disk writable/read-only cycle, a .bak-date backup, a 'kvmd -m' validation that rolls back the old file on failure, and the extra confirm_phrase gate for restarting kvmd, kvmd-nginx or kvmd-otg. This is exactly the context an agent needs before performing a destructive write.
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?
Front-loads the verb and the target, then moves through path/content, confirmation flow, side effects, and restart. Dense but almost every clause earns its place; the label-style line breaks ('path:', 'content:', 'restart:') read a bit terse and fragment the flow, which keeps it just short of a 5.
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 destructive 6-parameter write tool with no annotations, the description covers the confirmation protocol, the side effects and their rollback, the restart semantics, and the prerequisite read tool. An output schema exists, so the absence of return-value detail is not a gap.
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 0%, so the description must compensate and mostly does: path is tied to pikvm_config_read's allowed set, content is defined as the WHOLE new file, confirm is bound to the second call, and restart/confirm_phrase are explained together with their values. The one gap is 'server', which is never described beyond the phrase 'Needs one PiKVM', even though it is the parameter that selects the target device.
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?
States a specific verb and resource: 'Replace a PiKVM config file over SSH', with an explicit scope qualifier ('Needs one PiKVM'). An agent can immediately distinguish this write path from the sibling pikvm_config_read and from the other PiKVM tools.
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?
Gives an explicit workflow: read the file first with pikvm_config_read, edit, send the whole content back. It also spells out the two-step confirmation ('The first call shows a diff and does nothing. After the user says yes, call again with confirm=true') and names the sibling it depends on, leaving no ambiguity about when and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the PiKVM web API paths this tool knows, with their options.
query: a word to look for. group: system, hid, atx, msd, gpio, streamer, switch, export. Use pikvm_call to run one.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose an important behavioral trait — that this lists paths 'this tool knows' (the wrapper's known set, not necessarily a live probe) — and the output schema covers the return shape. However, it says nothing about side effects, whether results reflect server state, or pagination of the listing.
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?
Three short lines, front-loaded with the purpose and ending with the routing instruction. Nothing is padded, and each line adds a distinct fact (what it returns, how to filter, what to do next).
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 two-optional-param discovery tool with an output schema, this covers purpose, both filters, and the follow-up action. The only omission is any statement about scope or freshness of the catalog, which would matter for an agent deciding whether this reflects the live server.
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 0%, so the description must compensate, and it largely does: 'query: a word to look for' explains the search semantics, and it enumerates the accepted group values (system, hid, atx, msd, gpio, streamer, switch, export) that the schema itself does not constrain with an enum. Minor gap: no mention of whether query and group combine or how matching works.
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?
States a specific verb and resource: 'List the PiKVM web API paths this tool knows, with their options.' An agent can tell this is a discovery/catalog tool rather than an execution tool, especially since it names pikvm_call as the executor. It doesn't distinguish itself from the other read-style siblings (pikvm_info, pikvm_type, pikvm_config_read), so it falls short of a 5.
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?
'Use pikvm_call to run one' explicitly hands off to the correct alternative and defines the discovery-then-execute workflow. There are no negative exclusions (e.g. 'not for reading live config — use pikvm_config_read'), which keeps it just under a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show PiKVM details: version, hardware, health (throttling, temperature), name.
fields: any of auth, extras, fan, hw, meta, system (comma separated).
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | system,hw,meta | |
| server | No | ||
| max_chars | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Show' implies a read, which is helpful, but it says nothing about whether output is truncated (the max_chars default of 12000 is undisclosed), how multiple servers are handled, or any auth requirements for the auth/fields option.
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?
Two short lines, front-loaded with what the tool returns and followed by the parameter hint. No filler text; the only weakness is that the fields hint is terse to the point of missing the other parameters.
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?
An output schema exists, so return values need not be explained, and the content list is adequate. But for a tool that exposes server targeting and output truncation, those behaviors are left unaddressed, and the overlap with sibling info tools is unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the 'fields' parameter well (valid values and comma-separated syntax), but 'server' and 'max_chars' are never mentioned, leaving two of three parameters undocumented anywhere.
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?
States a specific verb and resource ('Show PiKVM details') and enumerates the content returned: version, hardware, health, name. That is far more informative than the bare name. It does not, however, distinguish itself from overlapping siblings such as pikvm_status and pikvm_system_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool rather than pikvm_status, pikvm_system_info, or pikvm_config_read, all of which plausibly return similar data. The fields list implies usage but leaves the agent to infer the routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the PiKVM (kvmd) log. Newest lines at the end.
lines: how many lines from the end to keep.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | ||
| server | No | ||
| max_chars | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire behavioral burden. It does disclose one useful trait -- ordering, with newest lines at the end -- but says nothing about whether output is truncated, whether this needs authentication, or how the multi-server case is handled.
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?
Two short lines, front-loaded with the purpose, and the ordering note is placed immediately after. No filler, though the second line spends words on the one parameter that least needs explanation while the two non-obvious ones get nothing.
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?
An output schema exists, so return-value explanation is not required, and the core purpose is clear. However, for a tool with three parameters at 0% schema coverage and no annotations, the omission of server and max_chars semantics leaves real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It explains only 'lines' (and only restates what is largely obvious from the name); 'server' and 'max_chars' -- the latter implying output truncation behavior -- are left entirely undocumented.
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?
States a specific verb and resource ('Show the PiKVM (kvmd) log'), which is unambiguous and distinct from read/write config or power siblings. It does not explicitly contrast itself with the nearest alternates (pikvm_status, pikvm_config_read), so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to reach for this tool versus pikvm_status, pikvm_info, or pikvm_config_read, and no mention of prerequisites or per-server targeting. The agent must infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The virtual USB drive (mass storage) that shows an ISO or disk image to the target.
action: status (also lists images), select (pick an image), connect, disconnect, download (fetch an image from url into the PiKVM), remove (delete an image). select: image name, cdrom=true for ISO, read_write=true for a writable disk. download: url, plus image for the file name. remove needs confirm_phrase equal to the path.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| cdrom | No | ||
| image | No | ||
| action | No | status | |
| server | No | ||
| confirm | No | ||
| read_write | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It usefully states that remove needs confirm_phrase equal to the path, which signals a destructive action and a safety requirement. However, it does not describe permissions, side effects of connect/disconnect, the role of confirm, or other operational constraints.
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 front-loaded with the resource and purpose, then compactly lists actions and parameter notes. Every sentence contributes relevant information. The dense action list could be slightly more structured, but it remains efficient.
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?
An output schema exists, so return values need not be described. However, with 8 parameters, no annotations, and 0% schema description coverage, the description leaves server and confirm unexplained and omits behavioral details for connect, disconnect, and remove. It is adequate for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply meaning for the 8 parameters. It explains the action values and gives semantics for image, cdrom, read_write, url, and confirm_phrase, including conditional usage. It leaves server and confirm unexplained, preventing a 5.
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 resource, the virtual USB drive (mass storage), and states that it shows an ISO or disk image to the target. It also enumerates the supported actions, so the tool's overall purpose is clear. It does not distinguish this tool from any sibling tool, which keeps it from a 5.
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 gives clear context for each action: status lists images, select picks an image, download fetches an image from a URL, and remove deletes an image. It also specifies key parameter usage for select, download, and remove. It does not provide explicit exclusions or alternatives, but the action-level guidance is sufficient for choosing the right operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Power control of the target machine through ATX.
action: status, on, off (soft, like a short press), off_hard (cut power, long press), reset_hard, click_power, click_power_long, click_reset. Everything except status and on can shut the machine down or restart it. Those need confirm=true and confirm_phrase equal to the path shown in the reply.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | status | |
| server | No | ||
| confirm | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose the destructive semantics of each action (soft short press vs. hard power cut vs. reset) and the safety gate required before executing them. It omits operational details such as permission requirements, what happens if confirmation is wrong or stale, and whether any action is idempotent.
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?
Front-loaded with the core purpose, then a compact action list and the confirmation rule. The action enumeration is long but each item carries distinct semantic information, and no sentence is filler.
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?
An output schema exists, so return-value explanation is unnecessary, but the definition still leaves gaps for a tool with four undocumented parameters and no annotations: the 'server' parameter, the default action of 'status', and the mechanics of obtaining a valid confirm_phrase are all 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 0% and all four parameters are undocumented in the schema, yet the description only covers 'action' (enumerating values and defaults implicitly) and the confirm/confirm_phrase pairing. The 'server' parameter is never mentioned at all, so a meaningful portion of the surface remains undocumented.
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?
States a specific verb and resource: power control of the target machine via ATX, with an enumerated action list that makes the operation concrete. It is clearly a power-management tool rather than an info/status tool, though the overlap between 'action: status' and the sibling pikvm_status is never addressed.
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?
Explicitly warns that every action except status and on can shut down or restart the machine, and states that those need confirm=true plus a confirm_phrase taken from the reply – effectively describing a two-step confirmation protocol. It does not say when to prefer this over pikvm_status for plain status reads, and the source of the confirm_phrase ('the path shown in the reply') is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the PiKVMs this tool can reach.
Shows names, addresses and whether SSH is set up. Never shows passwords.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does add real value: it discloses the returned fields and makes a security guarantee ('Never shows passwords'), which tells the agent no credentials will leak. It omits whether the call is read-only, whether it performs network probing (latency/partial failure behavior), and any auth prerequisites, which is a meaningful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the purpose and immediately followed by return contents and the security guarantee. No filler, though the sentence break for 'Never shows passwords' is a touch fragmented.
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?
An output schema exists, so return values need not be re-explained, and there are no parameters to cover. The remaining gap is behavioral: no indication of whether listing probes the network or what happens for unreachable hosts, which matters for a discovery 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?
Zero parameters, so there is nothing to document; baseline 4 applies. The description correctly does not waste space on phantom inputs.
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?
States a specific verb and resource ('List the PiKVMs this tool can reach') and adds the fields returned, so the agent knows exactly what it gets. It does not differentiate from the sibling 'pikvm_endpoints', which reads as an overlapping concept, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'this tool can reach' implies a discovery use case, but there is no explicit when-to-use, when-not-to-use, or named alternative among the 14 siblings. An agent must infer that pikvm_endpoints is not the right pick for enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check or control a service on the PiKVM over SSH.
action: status, start, restart, reload, enable, disable, stop. unit: for example kvmd, kvmd-nginx, kvmd-vnc, kvmd-ipmi, kvmd-janus, kvmd-webterm. Status runs right away. Stop and disable, and any restart of kvmd, kvmd-nginx, kvmd-otg, ssh or networking, need confirm_phrase equal to the unit name.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes | ||
| action | Yes | ||
| server | No | ||
| confirm | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work: it discloses which actions are destructive (stop, disable) and which units are dangerous to restart (kvmd, kvmd-nginx, kvmd-otg, ssh, networking), plus the confirmation guard. It does not say what happens on failure, whether actions are idempotent, or what privileges the SSH connection needs.
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?
Front-loaded with the core verb and resource, then tight enumerations of actions and units, then the safety constraint. The closing sentence is a run-on that mixes action names with unit names, but nothing is wasted.
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?
An output schema exists, so return values need no explanation, and the mutating nature of the tool is covered adequately. However, for a destructive multi-target tool with zero annotations and zero schema descriptions, the undocumented `server` and `confirm` parameters and the absent failure behavior leave real gaps.
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 0%, so the description must compensate. It documents action values and unit naming well and explains confirm_phrase's required value, but leaves `server` and the `confirm` boolean entirely unexplained, and never clarifies how `confirm` relates to `confirm_phrase`, leaving 2 of 5 parameters ambiguous.
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?
States a specific verb pair (check/control) and resource (a service on PiKVM over SSH), and the action/unit lists make clear this is systemd unit management rather than power control or arbitrary shell access. It does not explicitly name the siblings it is not (e.g. pikvm_power, pikvm_ssh), so differentiation is inferred rather than stated.
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?
Enumerates every valid action and shows the unit-naming convention with concrete examples, and it calls out the exact conditions under which confirm_phrase is mandatory. No explicit 'use X instead when Y' routing to sibling tools, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a picture of what the target machine is showing on its screen.
ocr: also read the text on the screen. max_width: shrink the picture (pixels). save: also keep the full size picture as a file on this computer. Needs one PiKVM (not "all").
| Name | Required | Description | Default |
|---|---|---|---|
| ocr | No | ||
| save | No | ||
| server | No | ||
| max_width | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose two important behaviors: save writes a full-size file to the local machine, and ocr performs text extraction. It omits what happens on failure, permissions needed, and crucially how the image itself is returned to the caller.
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?
Front-loaded with the core action, followed by a compact per-option list. Every line earns its place, though the fragmentary style ('max_width: shrink the picture (pixels)') reads more like notes than a polished description.
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?
With no annotations and no output schema, the description should explain how the captured image is delivered (inline data, file path, URL) and what save's file location is. It covers the options well but leaves the return behavior entirely unspecified, which matters for a tool whose whole purpose is producing an artifact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does: ocr, save, and max_width all get meaningful semantics beyond their bare types (text extraction, local file retention, pixel-based downscaling). The remaining gap is server, which is only obliquely covered by 'Needs one PiKVM (not "all")' rather than being named and explained.
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?
States a concrete verb and resource: capture an image of the target machine's screen. This is clearly distinguishable from informational siblings like pikvm_info, pikvm_status, and pikvm_system_info. It doesn't explicitly name an alternative tool, but the action is unique enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the option list (ocr for reading text, save for keeping a full-size file on this computer) and adds the constraint 'Needs one PiKVM (not "all")'. However, there is no explicit when-to-use guidance versus siblings or statement of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one command on the PiKVM over SSH (as root).
Safe read-only commands run right away (cat of /etc/kvmd files, systemctl status, journalctl, df, uptime, ip a, vcgencmd measure_temp, kvmd -m, pacman -Q, ls, and pipes into head, tail, grep, wc). Anything else needs confirm=true after the user says yes. Risky ones (rm, reboot, pacman, pikvm-update, passwd, stopping services and similar) also need confirm_phrase equal to the first word of the command. Files with passwords or keys are blocked. The PiKVM disk is read-only. To change a config file use pikvm_config_write instead.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | ||
| command | Yes | ||
| confirm | No | ||
| timeout | No | ||
| max_chars | No | ||
| confirm_phrase | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so well: it discloses the confirmation ladder, that secret-bearing files are blocked, that commands execute as root, and that the PiKVM disk is read-only. It stops short of explaining timeout behavior or that max_chars truncates output, which are material behavioral traits for a shell-execution 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 safety gate and the escalation path are front-loaded in the first three lines, with the config-write redirect at the end. Dense but each sentence carries an operational rule; minor redundancy in 'and similar' hedging.
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?
An output schema exists, so return values need not be described. For a root shell tool the critical unknowns (confirmation, blocking, disk state) are covered; the remaining gap is the undefined server/timeout/max_chars parameters, which leaves it just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully defines the semantics of confirm and confirm_phrase (including that the phrase is the first word of the command) but says nothing about server selection, timeout, or max_chars, leaving half the parameters undocumented anywhere.
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?
States a specific verb and resource ('Run one command on the PiKVM over SSH (as root)') and immediately frames the guardrail model. It also names the sibling it is not for config edits (pikvm_config_write), so an agent can distinguish it from pikvm_call, pikvm_config_read, or pikvm_service without opening a schema.
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?
Gives a concrete allowlist of read-only commands that run without confirmation, states that everything else requires confirm=true after user approval, and adds a second escalation tier (confirm_phrase) for risky commands. It also routes the alternative case ('To change a config file use pikvm_config_write instead'), which is exactly the when/when-not/alternative structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One look at the target machine: power (ATX), screen (streamer), keyboard and mouse (HID), and virtual drive (MSD).
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | ||
| max_chars | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real behavior: the call aggregates four distinct subsystems (ATX, streamer, HID, MSD). However, it never states that it is a read-only operation, what happens when a subsystem is unreachable, or that output may be truncated by max_chars.
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 compact sentence that front-loads the overview intent and then lists the covered subsystems. No filler, though the fragment style ('One look at...') costs a bit of precision.
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?
An output schema exists, so return values need not be explained, and the subsystem list covers what is returned. The gap is the two undocumented parameters and the absence of any safety/behavior notes on a tool with zero annotation coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does not — neither the 'server' selector (which PiKVM target) nor 'max_chars' (truncation limit) is mentioned. An agent cannot tell from the description how to target a specific host or control output size.
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 enumerates exactly what the status covers (ATX power, streamer screen, HID keyboard/mouse, MSD virtual drive), which makes the resource and its scope concrete. The verb is only implied by 'one look,' and no sibling (e.g. pikvm_power, pikvm_system_info, pikvm_snapshot) is named to sharpen the distinction, keeping it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this aggregate status versus single-subsystem siblings like pikvm_power or pikvm_msd, and no exclusions or prerequisites. The agent must infer usage purely from the enumerated subsystems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A read-only health check over SSH: OS, kvmd version, uptime, disk, memory, temperature, throttling, USB gadget, network addresses, and the state of the main PiKVM services.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | ||
| max_chars | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it does disclose read-only semantics and the SSH transport, which is genuinely useful. It says nothing about authentication/credential requirements for the SSH connection, whether the call is slow or rate-limited, or how failures surface — meaningful gaps for an SSH-based probe.
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?
One front-loaded sentence that leads with the operation type and transport, then enumerates payload. The long list of metrics is dense but each item is informative; no filler sentences.
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?
An output schema exists, so return-format explanation is not required, and read-only behavior is stated. However, the two undocumented parameters — especially how "server" resolves and what "max_chars" truncation does — leave real gaps an agent must guess at before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters, and the description does not compensate at all. "server" is never explained (target host? alias from pikvm_servers?), and "max_chars" clearly implies output truncation behavior that goes entirely undocumented.
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?
Names a specific verb (health check) and resource (PiKVM system) and enumerates the exact data collected — OS, kvmd version, uptime, disk, memory, temperature, throttling, USB gadget, network, service state. An agent knows precisely what this returns, though it never distinguishes itself from overlapping siblings like pikvm_status or pikvm_info.
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?
"Health check" implies a diagnostic context, but there is no explicit guidance on when to pick this over pikvm_status, pikvm_info, or pikvm_endpoints, all of which plausibly return overlapping state. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type on the target machine like a USB keyboard.
text: text to type. shortcut: keys together, like ControlLeft,AltLeft,Delete. Give one of them. This changes what the machine does, so it needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| slow | No | ||
| text | No | ||
| keymap | No | ||
| server | No | ||
| confirm | No | ||
| shortcut | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description usefully discloses that this is a mutating action and requires confirmation. It still leaves key behavioral details unstated, such as target server selection, keymap behavior, slow typing, failure behavior, and permission requirements.
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-loads the main action and side effect. It is efficient, though the phrase 'Give one of them' is slightly informal and the breakdown omits several parameters.
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?
An output schema exists, so return values need not be explained. For a six-parameter mutation tool with no annotations and no schema descriptions, the description covers the core interaction and confirmation requirement but is not complete enough regarding server, keymap, and slow typing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains text, shortcut with an example, mutual exclusivity via 'Give one of them,' and confirm, but it leaves slow, keymap, and server undocumented.
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 and resource: 'Type on the target machine like a USB keyboard.' This clearly distinguishes keyboard input from other KVM operations, though it does not explicitly contrast with siblings such as pikvm_ssh or pikvm_call.
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?
It states that the caller should give either text or shortcut and that confirm=true is required because the action changes machine behavior. However, it does not say when to use this tool instead of related alternatives like pikvm_ssh or pikvm_call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0pikvm_callpikvm_config_readpikvm_config_writepikvm_endpointspikvm_infopikvm_logpikvm_msdpikvm_powerpikvm_serverspikvm_servicepikvm_snapshotpikvm_sshpikvm_statuspikvm_system_infopikvm_typeScored across 15 tools
Most tools target distinct resources (power, HID, MSD, config, services, logs). The main soft spots are pikvm_info vs pikvm_system_info vs pikvm_status, and pikvm_ssh vs pikvm_system_info, but descriptions clarify the API-vs-SSH vs target-state split, and pikvm_call is explicitly framed as an escape hatch rather than a competing tool.
Every tool shares the pikvm_ prefix with consistent snake_case, which makes the set very legible. The only deviation is mixing noun-oriented names (pikvm_info, pikvm_status, pikvm_servers) with verb-oriented ones (pikvm_call, pikvm_type, pikvm_power), but the pattern remains predictable.
15 tools is a reasonable, well-scoped surface for a device-control server spanning power, HID, storage, config, and services. A few tools (pikvm_info/pikvm_status, pikvm_system_info) feel slightly redundant, but each still covers a distinct slice.
Core lifecycle coverage is strong: read/write config, service control, power actions, HID input, MSD management, snapshots, logs, and a generic API passthrough that fills remaining gaps. Minor omissions like local image upload to MSD are workable via pikvm_call.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Manage your IoT device fleet directly from Claude. Create device templates with datastreams and events, provision new devices, read live sensor data, and control outputs. The Blynk connector integrates with the Blynk IoT platform, enabling direct configuration and monitoring of connected devices and infrastructure.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Read, edit, publish, and preview your pepita websites from Claude.
