Skip to main content
Glama

power_off_all

Cut power to all DCC systems simultaneously for a complete layout shutdown. Use for emergencies when all locomotives must stop, including those not acquired.

Instructions

Cut power to EVERY DCC system at once — the real "stop absolutely everything" button.

No arguments. Call for "cut the power", "cut everything", "kill the power", "coupe le courant", "coupe tout", "coupe l'alimentation" — any generic power-cut request with no specific system named. Use this even when the phrase sounds like a stop command — "coupe le courant" means THIS tool, not emergency_stop_all, since the user is naming power, not motion. For a genuine layout-wide emergency, this reaches every locomotive regardless of who's driving it (JMRI panel, PanelPro, another session) — unlike emergency_stop_all, which only e-stops locomotives THIS session has acquired and never touches power.

More drastic than emergency_stop_all: also stops anything with no throttle acquired, but re-powering afterward requires an explicit set_power(system, turn_on=True) per system before any locomotive can move again — don't use this for a routine "stop the train", only a real emergency.

Each system's result is re-read and confirmed like set_power — check "confirmed" per system (see set_power's docstring for the "outdated_jmri_version" upgrade note, also per system here).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description fully discloses that this is a drastic action that cuts power to all systems, requires explicit re-powering, and re-reads and confirms results per system. References set_power's docstring for an upgrade note, showing awareness of version-specific behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Somewhat verbose with alternative phrasings and comparisons, but each sentence adds value. Could be slightly more concise, but the information is well-organized and front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers return behavior (confirmation per system), side effects (power loss and need for re-powering), and contextualizes relative to siblings. It fully explains the tool's behavior and impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so no parameter description needed. The description does not discuss any input schema details, but that is appropriate given zero parameters. Baseline 4 for no-param tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Cut power to EVERY DCC system at once' with explicit verb 'cut power' and resource 'all DCC systems'. Clearly distinguishes from sibling emergency_stop_all by explaining the scope (all locos regardless of session) and the fact it cuts power, not just e-stops. Also provides alternative phrasings like 'coupe le courant' to avoid confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call for generic power-cut request with no specific system named' and contrasts with emergency_stop_all when user mentions 'power' vs 'stop'. Warns not to use for routine stop and explains re-powering requirement. Provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HO44-PROJECT/MrJ-JMRI-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server