Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tronbyt-mcp Put 'Meeting in 5' on the sign in green."
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.
Let your AI assistant put things on your LED sign.
If you have a Tidbyt or Tidbyt-style LED matrix display managed by a self-hosted tronbyt/server, this connects it to Claude (or any other AI tool that speaks MCP, the open standard for giving assistants access to tools). Once installed, your display becomes something you can just talk to your assistant about:
"Put BREAD'S DONE on the sign in amber." "Dim the display to 20% and turn on night mode from 10pm to 7am." "What apps are on the sign right now? Disable the stock ticker." "Show the clock app for a bit."
The assistant handles the rest — rendering text into the display's pixel format, talking to your server, managing the app rotation. Everything runs on your own machine against your own server; nothing goes through any cloud service.
tronbyt-mcp is a small MCP server that wraps tronbyt/server's documented
REST API. Your MCP client (Claude
Code, Claude Desktop, and friends) launches it locally and talks to it over stdio; it
talks to your Tronbyt server over HTTP with a device API key.
Related MCP server: ulanzi-mcp
A display managed by a self-hosted tronbyt/server (v2.x). Any device the server manages works — it doesn't need to have started life as a Tidbyt: Tidbyt Gen1/Gen2, Tronbyt S3 and S3 Wide kits, MatrixPortal S3 (including the Waveshare variant), Waveshare S3, Pixoticker, Raspberry Pi displays, and homebrew panels typed "other". Both standard 64×32 and wide 128×64 (2x) panels are supported.
Node.js ≥ 20.9
An MCP client: Claude Code, Claude Desktop, or anything else that supports MCP stdio servers.
In the Tronbyt web UI, open your device's settings and copy (or generate) its API key. Keys are scoped to a single device — one key, one display.
Claude Code (one command):
claude mcp add tronbyt \
-e TRONBYT_BASE_URL=http://tronbyt.local:8000 \
-e TRONBYT_API_KEY=<your-device-key> \
-- npx -y tronbyt-mcpClaude Desktop: edit the config file —
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json,
Windows: %APPDATA%\Claude\claude_desktop_config.json — and add:
{
"mcpServers": {
"tronbyt": {
"command": "npx",
"args": ["-y", "tronbyt-mcp"],
"env": {
"TRONBYT_BASE_URL": "http://tronbyt.local:8000",
"TRONBYT_API_KEY": "<your-device-key>"
}
}
}
}Then restart Claude Desktop.
Any other MCP client: configure a stdio server with command npx, args
["-y", "tronbyt-mcp"], and the two environment variables above.
From source (instead of npx):
git clone https://github.com/jonfishr/tronbyt-mcp.git
cd tronbyt-mcp
npm install && npm run buildThen use node /path/to/tronbyt-mcp/dist/index.js as the server command in your MCP
client config (same environment variables).
Multiple displays? API keys are per-device, so add one entry per display
(tronbyt-kitchen, tronbyt-office, …), each with its own key.
Ask your assistant something like "List my Tronbyt devices." You should get back your
display with its brightness, night mode, and app list. (In Claude Code, /mcp also
shows the server and its tools.)
Env var | Required | Default | Notes |
| yes | — | Your tronbyt/server, e.g. |
| yes | — | Per-device API key from the Tronbyt web UI |
| no |
| Per-request timeout |
You don't call these directly — your assistant picks the right tool from your request — but this is what it has to work with:
Tool | What it does |
| Devices visible to the key: brightness, night mode, pinned app, last seen |
| Set brightness, rotation interval, night/dim mode, pinned app |
| Reboot the display |
| Apps installed on the device, with state and config |
| Enable/disable, pin/unpin, or retime an installation |
| Remove an installation and its rendered images |
| Render a server-side app (with optional config) and show it |
| Push a base64 WebP (64×32, or 128×64 for wide displays) straight to the display |
| Render text to a display-sized WebP locally and push it |
Push tools take background: false (default) interrupts the display and shows the
push immediately; true saves it into the rotation without interrupting. When a key
sees exactly one device (the normal case), device_id never needs to be specified.
push_textText is rendered with the Tom Thumb
3×5 pixel font, word-wrapped and centered. Printable ASCII only; \n forces a line
break. Colors are hex (#ffcc00), default white on black.
Canvas size is detected from the device type (size: "auto"): standard displays get
64×32, wide/2x displays (tronbyt_s3_wide, raspberrypi_wide) get 128×64. On wide
displays the font is doubled by default — same 16 chars × 5 lines, twice the pixels.
Pass text_size: "small" for native-size glyphs (32 chars × 10 lines), or override
the detection entirely with size: "64x32" / "128x64".
Claude Code: claude mcp remove tronbyt
Claude Desktop / other clients: delete the "tronbyt" entry from the config
file and restart the client.
If you installed from source: delete the cloned directory. If you used npx, a
cached copy may linger under ~/.npm/_npx; it's small and harmless, or clear it
with npm cache clean --force.
On the server: anything you pushed shows up as an installation on the device — ask your assistant to delete it, or remove it in the Tronbyt web UI. Revoke the API key in the web UI if you're done with it. Nothing else is stored anywhere.
npm install
npm test # vitest: unit + in-process MCP + stdio e2e (builds first)
npm run build # tsc -> dist/
npm run gen:font # regenerate src/font.ts from scripts/tom-thumb.bdfSmoke test against a real server (non-destructive — pushes to the rotation in background mode, then deletes the installation). Run from the repo root after a build:
TRONBYT_BASE_URL=http://tronbyt.local:8000 TRONBYT_API_KEY=<key> scripts/smoke.shupdate_firmware_settings — deliberately excluded; a bad value can leave a display
unreachable
Animation (multi-frame WebP), image-by-URL
HTTP transport (stdio only)
MIT. The bundled pixel font is Tom Thumb / "Fixed4x6" by Brian J. Swetland and Robey
Pointer (MIT), vendored as scripts/tom-thumb.bdf. This project is not affiliated with
Tidbyt (the company) or the Tronbyt project.
Delete an app installation from a device, including its rendered images. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | Device ID. Omit when the API key can see exactly one device. | |
| installation_id | Yes | Installation name (iname) from list_installations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, but the description adds specific behavioral details: deletion includes rendered images and is irreversible. This goes beyond the annotation, providing useful context about the operation's scope and permanence.
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 concise sentences, no fluff. The first sentence states the action and scope, the second emphasizes irreversibility. Structure is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers purpose, scope (including images), and irreversibility. There is no output schema, but it's not strictly necessary for a delete. Some agents might benefit from knowing return format, but overall it's sufficiently 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 100%, so parameters are already well-documented. The tool description does not add extra meaning beyond what's in the schema. It mentions 'rendered images' but that pertains to the action, not the parameters.
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?
Tool name is 'delete_installation' and description states 'Delete an app installation from a device, including its rendered images.' The verb and resource are clear, and the description adds specific scope (rendered images). This distinguishes it from siblings like 'update_installation' and 'list_installations'.
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 mentions 'This cannot be undone,' implying caution but does not explicitly state when to use this tool vs alternatives. It lacks guidance on prerequisites (e.g., need to call list_installations first) or when not to use. However, the destructive nature is clear, giving some implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Tronbyt devices visible to the configured API key, including brightness, night mode, pinned app, and last-seen time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates the tool is read-only. The description adds useful context about the fields returned but does not disclose potential rate limits, pagination, or other behavioral traits. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word earns its place, with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately informs the agent about the returned fields. It does not mention pagination or response structure, but for a simple list with no parameters, this is sufficiently 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?
There are no parameters, so the schema coverage is effectively 100%. The description does not need to add parameter semantics. A baseline score of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('all Tronbyt devices') with a scope ('visible to the configured API key'). It also lists included fields, clearly distinguishing it from sibling tools like update_device or reboot_device.
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 clearly implies when to use this tool (to list devices), but does not explicitly state when not to use it or mention alternatives. However, the context is clear given the distinct sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List app installations on a device: installation id (iname), app, enabled/pinned state, timing, and config.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | Device ID. Omit when the API key can see exactly one device. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms read-only behavior matching the readOnlyHint annotation. It adds value by listing the specific fields returned (installation id, app, state, timing, config), which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (15 words) that front-loads the action and key output fields. No unnecessary words or 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?
For a simple list tool with one optional parameter and no output schema, the description adequately covers the purpose and return fields. It is largely complete, though could mention pagination or ordering if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for device_id. The tool description does not add additional semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists app installations on a device and specifies the fields returned (installation id, app, state, timing, config). This distinguishes it from sibling tools like list_devices or update_installation.
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 on a device but does not explicitly state when to use this tool vs alternatives like push_app or update_device. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a server-side app (optionally with config) and push it to the display. Use installation_id alone to re-activate an existing installation with its saved config.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | No | App identifier, e.g. "clock". Required unless installation_id names an existing installation. | |
| config | No | App config; omitted = the installation's saved config. | |
| device_id | No | Device ID. Omit when the API key can see exactly one device. | |
| background | No | false (default): interrupt the display and show this immediately. true: save into the rotation without interrupting. | |
| installation_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the burden. It mentions rendering and pushing, and re-activation behavior, but lacks details on error handling, permissions, or whether the action is destructive. Some behavioral context is provided, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and provides essential information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 5 parameters, and no annotations, the description covers the core functionality but omits return values and error scenarios. It is adequate but not fully complete for a complex 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 coverage is high (80%), so baseline is 3. The description reiterates the installation_id re-activation use, but adds minimal value beyond the schema. The config parameter's behavior is already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a server-side app and pushes it to the display, and also explains re-activation using installation_id. This distinguishes it from sibling tools like push_image or push_text.
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 specific guidance on using installation_id alone for re-activation, and implies usage for new apps with app_id and config. However, it does not explicitly state when to use this tool versus other push tools or 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.
Push a base64-encoded WebP image directly to the display (64x32; 128x64 for wide/2x devices).
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | Base64-encoded WebP image bytes. | |
| device_id | No | Device ID. Omit when the API key can see exactly one device. | |
| background | No | false (default): interrupt the display and show this immediately. true: save into the rotation without interrupting. | |
| installation_id | No | Name for this pushed image. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains the effect of the background parameter (interrupt vs save into rotation), which adds value beyond annotations. However, no disclosure of other behaviors like size validation, device authorization, or potential errors.
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?
Single sentence with parenthetical, front-loaded with purpose. Efficient but could be slightly more structured by separating resolution info.
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?
Lacks output/return value information. With no output schema, description should mention what agent can expect (e.g., success/error). Missing some details like exact image dimension requirements and whether the tool validates inputs.
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?
Adds context beyond schema: background parameter effect explained, resolution constraints provided (64x32; 128x64). Schema already has descriptions for all 4 parameters, so baseline is 3; the extra information lifts it to 4.
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?
Clearly states the action (push image), input format (base64 WebP), and target (display with resolution constraints). Distinguishes from sibling tools like push_text and push_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., push_app, push_text). The description implies direct display but does not explain when to use background vs foreground or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render text into an image sized for the display (64x32, or 128x64 for wide/2x devices) and push it. Word-wrapped and centered, printable ASCII only. At default sizing: 16 chars/line, 5 lines.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Canvas size. "auto" (default) detects it from the device type (wide/2x devices get 128x64). | auto |
| text | Yes | Text to display. \n forces a line break. | |
| color | No | Text color as hex, e.g. "#ffcc00". Default white. | |
| device_id | No | Device ID. Omit when the API key can see exactly one device. | |
| text_size | No | "large" doubles the 4x6 font, "small" is native size. "auto" (default): large on 128x64 (16 chars x 5 lines), small on 64x32. Use small on 128x64 for 32 chars x 10 lines. | auto |
| background | No | false (default): interrupt the display and show this immediately. true: save into the rotation without interrupting. | |
| installation_id | No | Name for this pushed image (default "text"). | text |
| background_color | No | Background hex color. Default black. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: image sizing, word-wrapping, centering, character set, and default line/char limits. Since annotations are absent, it bears full burden but does not clarify overwriting behavior, error conditions, or how background mode affects display queue.
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 uses three short sentences. First sentence states the core action and display sizes, second adds constraints, third gives default metrics. Every sentence carries essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and no output schema. The description covers core behavior and constraints but lacks details on parameter interactions (e.g., how text_size changes line counts beyond defaults) and does not explain background vs immediate display behavior. Sibling tools are listed but no usage comparison is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond schema by specifying default text size yields 16 chars/line and 5 lines, and mentioning word-wrapping and centering. These details help the agent understand typical output layout not present in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders text into an image sized for the display and pushes it. It specifies display sizes (64x32, 128x64) and default character limits, distinguishing it from siblings like push_image which likely handles arbitrary images.
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 for text display with word-wrapping and centering, and restricts to printable ASCII. However, it does not explicitly state when to use this tool versus alternatives like push_image or push_app, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reboot a Tronbyt device. The command is sent immediately; the device reboots asynchronously.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | Device ID. Omit when the API key can see exactly one device. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows it's a destructive action. The description adds that the command is sent immediately and the reboot is asynchronous, which is valuable behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—with no filler. It front-loads the key action and communicates essential behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reboot tool with one optional parameter and no output schema, the description adequately covers the async behavior and immediate command. Minor gap: no mention of confirmation or response, but overall complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for device_id. The tool description does not add any additional meaning or context beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reboot') and the resource ('a Tronbyt device'), distinguishing it from siblings like update_device or list_devices. It also adds useful context about the command being sent immediately and the reboot being asynchronous.
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 (reboot a device) but provides no explicit guidance on when to use versus alternatives, nor any conditions or exclusions. Given the sibling list, confusion is unlikely, but the description could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update device settings: brightness, app rotation interval, night mode, dim mode, or the pinned app. Only provided fields change.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | Device ID. Omit when the API key can see exactly one device. | |
| brightness | No | Display brightness, 0-100. | |
| pinned_app | No | Installation to pin (always show). Empty string unpins. | |
| interval_sec | No | Seconds each app shows in rotation. | |
| night_mode_app | No | App to show during night mode. | |
| night_mode_enabled | No | ||
| dim_mode_brightness | No | ||
| dim_mode_start_time | No | "HH:MM". | |
| night_mode_end_time | No | "HH:MM", e.g. "07:00". | |
| night_mode_brightness | No | ||
| night_mode_start_time | No | "HH:MM", e.g. "22:00". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that 'Only provided fields change,' indicating partial updates, but lacks details on permissions, device online requirement, or potential conflicts among parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose and lists settings, the second adds the important constraint about partial updates. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description provides a high-level summary but does not detail effects of each setting or side effects like whether the device must be online.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes most parameters (73% coverage). The description groups parameters by category but adds minimal new meaning beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update device settings') and enumerates the categories of settings (brightness, app rotation interval, night mode, dim mode, pinned app). This distinguishes it from sibling tools like list_devices or reboot_device.
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 when you want to modify device settings, but it does not explicitly state when to use this tool versus alternatives, nor provides any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an installation: enable/disable it in the rotation, pin/unpin it, or change its render interval and display time.
| Name | Required | Description | Default |
|---|---|---|---|
| pinned | No | ||
| enabled | No | ||
| device_id | No | Device ID. Omit when the API key can see exactly one device. | |
| installation_id | Yes | Installation name (iname) from list_installations. | |
| display_time_sec | No | Seconds shown per rotation. | |
| render_interval_min | No | Minutes between re-renders. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must bear the full burden. It only states what fields can be updated, with no disclosure of side effects, authorization requirements, idempotency, or whether changes are reversible. For a mutation tool, this is insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Front-loaded with the verb 'Update' and immediately conveys the resource and actions. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters and no output schema, the description covers the core purpose but lacks details on return value, error conditions, or prerequisites. It is minimally adequate but incomplete for an agent to understand all implications of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description maps human-readable actions (enable/disable, pin/unpin, change interval/time) to schema parameters, adding meaning beyond the schema's type/descriptions. For example, 'enable/disable' corresponds to 'enabled' boolean; 'pin/unpin' to 'pinned'. This adds value, though not all parameters (like device_id) are explained in the description.
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?
Description clearly states the verb 'update' and resource 'installation' and enumerates specific operations (enable/disable, pin/unpin, change render interval and display time). This distinguishes it from sibling tools like update_device (which updates device settings) and list_installations (which lists installations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The description lists what can be changed, but does not mention prerequisites (e.g., need installation_id from list_installations) or when not to use this tool (e.g., vs. delete_installation). Implied usage is clear but lacks structured guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0delete_installationlist_deviceslist_installationspush_apppush_imagepush_textreboot_deviceupdate_deviceupdate_installationEach tool targets a distinct action: device management, installation management, or content pushing. The three push tools are clearly separated by input type (app, image, text), and there is no overlap.
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_devices, push_image). The verbs are appropriate and uniform, making the set predictable.
9 tools is well-scoped for managing Tronbyt devices: 3 for device settings, 3 for installations, and 3 for pushing content. No redundant or missing tools at this scale.
Covers core workflows: device listing/update/reboot, installation CRUD (with push_app creating installations implicitly), and content push. Minor gaps: no device creation/deletion or single device retrieval, but these are acceptable given the assumed external device management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jonfishr/tronbyt-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
