Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
--hostNoExplicit bind address; wins over --local.
--httpNoServes Streamable HTTP at POST /mcp instead of stdio, on all interfaces (0.0.0.0). HTTP mode is key-gated and requires mcp.api_key from every caller.
--portNoHTTP listen port.8315
--localNoBinds the HTTP listener to loopback (127.0.0.1) only.
--configNoKeep both config files in this folder instead of ~/.ctrlpi/.
--no-scanNoNever sweep the LAN, at startup or after. A first run with no config still sweeps once.
--rotate-keysNoReplace the shipped default key on any agent still using it with a random one, and record the date under key_set.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
mcp_agents_listA

List configured agents (Pi, Pico or ESP32). Returns name, ip, port, online (live /hello probe), type (pi/pico/esp32), version, has_default_key, and last_updated_at (UTC "YYYY-MM-DD HH:MM:SS", when the agent list was last saved; every sweep saves it). Unreachable agents are included (online=false). The LAN is swept automatically every hour. Pass rescan=true to sweep it now, but only when the user asks to find new hardware: a sweep takes 10 seconds or more. If has_default_key is true for any agent, tell the user that agent is on the insecure default key and ask whether to change it.

mcp_gpio_readB

Read a GPIO pin value on agent by number or name, or 'all' to read all pins.

mcp_gpio_writeA

Write a value to a GPIO pin on agent ('0', '1', 'on', 'off', or 'toggle'). Optional duration in seconds, after which the pin reverts to its previous state. If the pin has a configured 'max' pulse duration, the effective duration is clamped to it - and if no duration is given but 'max' is set, 'max' is used as the duration automatically.

mcp_gpio_scanA

Scan all hardware GPIO pins on agent and return their value, type, pull resistor, and name: BCM 2-27 on a Raspberry Pi, GP0-GP28 (minus the WiFi-reserved GP23/24/25/29) on a Pico, and every usable pin of the chip on an ESP32 (flash, PSRAM and USB pins are left out).

mcp_gpio_configA

Configure a GPIO pin on agent by number. type: input/output/vcc/gnd/remove. init: 0/1/last. pullup: up/down/none (input only). max: max pulse duration in seconds (output only). reversed: active-low logic (input/output only). watched: trigger webhook on state change (logged on the agent if no notifications.webhook is configured).

mcp_gpio_watchedB

List the GPIO pins that are currently being actively watched (the ones emitting hardware interrupts/webhooks).

mcp_sensor_configA

Configure a named sensor on agent. A sensor runs a script and its output is the reading. script is " [args...]": a bare filename in the agent's scripts/ folder (no paths - that folder is the only allowed location), with letters/digits-only arguments. On a Raspberry Pi it is a shell script run with sh; on a Pico or ESP32 a .py file the agent execs in-process. Pass remove=true to delete the sensor.

mcp_sensor_readA

Read sensors on agent. With no name, reads every configured sensor and returns them merged into one JSON object; with a name, reads just that sensor. Every reading is nested under its sensor's own name: a script emitting a JSON object with several fields nests whole, one emitting a single-field object contributes just that field's value, and any other output is wrapped the same way.

mcp_config_readB

Read agent's global application configuration, grouped: notifications (webhook + webhook_key), bridges (matter/homekit/homebridge callbacks), settings (docs_enabled, logs_enabled, log_days), sensors, and configured pins (gpios). The agent block (platform, os, ip, cpu_temperature, version) is computed live on every read and is not stored.

mcp_config_writeA

Update agent's global configuration dynamically. These are the ungrouped (root) field names; the agent routes each into its group (webhook_url -> notifications.webhook, webhook_key -> notifications.webhook_key, docs_enabled/logs_enabled/log_days -> settings), so a read afterwards shows them nested. log_days controls how long log entries are kept (0-30, clamped; 0 clears the log immediately and keeps only the last hour). docs_enabled is Pi-only. Changing api_key changes the agent's authentication key immediately, and also updates the local agents-config.json file to match automatically.

mcp_config_loadA

Load a full config onto agent from a dict (the agent saves a backup first). Pass an empty dict {} to reset all settings on the agent keeping only its API key.

mcp_agent_restartA

Restart agent's server process. Pass reboot=true to reboot the whole device instead (a Pi, Pico or ESP32); an agent running on a Mac ignores it and restarts the process.

mcp_agent_upgradeA

Upgrade agent to the latest release, then restart it. A Pi runs install.sh --upgrade (re-downloads the release files and reinstalls dependencies); a Pico or ESP32 downloads the new files over WiFi, swaps them in and resets.

mcp_agent_logsA

Read the last 50 lines of agent's server log file.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 14 tools

Disambiguation4/5

The surface splits cleanly by resource: GPIO (read/write/config/scan/watched), config (read/write/load), sensors (config/read), and agent lifecycle (list/restart/upgrade/logs). The only real overlaps are config_write vs config_load (partial dict update vs full-document load) and gpio_read with 'all' vs gpio_scan, but the descriptions make the intended distinctions (nested grouping, backup-then-load, pin metadata vs raw values).

Naming Consistency4/5

All tools share a predictable prefix + domain_action shape (mcp_gpio_read, mcp_config_write, mcp_sensor_read, mcp_agent_restart). Minor deviations: mcp_agents_list uses the plural 'agents' where the lifecycle tools use 'agent', and mcp_gpio_watched is an adjective rather than a verb (a list operation). Overall still readable and largely uniform.

Tool Count5/5

14 tools spread across four coherent domains (GPIO, sensors, config, agent lifecycle) with no filler entries. Each tool covers a distinct operation needed by a device bridge, well within the 3-15 sweet spot.

Completeness4/5

GPIO has full lifecycle coverage (scan, read, write, configure, watched-list) and config supports read/write/load including a reset path; sensors support configure/read plus removal via remove=true. Gaps are minor: no explicit agent add/remove/rename (relying on the hourly LAN sweep) and no dedicated sensor list beyond the config read's sensors group.

Maintenance

ActivityMaintained
ResponsivenessNo issues