Skip to main content
Glama
ostapondo

plonk-mcp

by ostapondo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_app_rule

Assign an app to open future windows into a numbered zone on a selected monitor, preserving your layout across reboots and screen renumbering.

Instructions

Make an app's windows open into a numbered zone from now on, so an arrangement holds without anyone dragging: 'Slack always in zone 1 on the second monitor'. 'app' is matched anywhere in the app's name or bundle id, case-insensitively, the way get_state.excluded_apps entries are; a bundle id such as 'com.tinyspeck.slackmacgap' is the safest form. 'zone' is the number Plonk draws on the zone (1-based) in the set assigned to that monitor. 'screen' is a monitor index from get_state and is stored as that display's identity, so it survives a reboot renumbering the screens; omit it and the window stays on whichever screen it opened on. One rule per app: setting it again replaces the old one; a rule that names the app exactly wins over a bare-word rule. Applies to ordinary windows that open after it is set, not to windows already open (use snap_window for those) and not to dialogs or panels. An app on get_state.excluded_apps is left alone even with a rule. A rule beats the habit Plonk keeps of where an app's last window went, and both beat filling an empty zone. Current rules are get_state.app_rules. Fails when 'screen' names a monitor that is not attached or a zone that monitor's set does not have.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appYesApp name or bundle id to match, e.g. 'com.apple.Safari' or 'Safari'
zoneYes1-based zone number, as shown on the drag overlay
screenNoMonitor index from get_state (0 = primary); omit for the screen the window opens on

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.3

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and handles it thoroughly. It discloses matching semantics, case-insensitivity, safe bundle-id form, screen identity persistence across reboots, one-rule-per-app replacement, exact-name priority, inapplicability to dialogs/panels, excluded-app behavior, and failure conditions for invalid screens/zones.

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

Conciseness4/5

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

The description is long, but nearly every sentence adds a necessary behavioral or edge-case detail. It is front-loaded with the core purpose and then expands into parameter semantics and caveats; some restructuring into separate behavioral notes could improve scannability, but no sentence is wasted.

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?

For a tool with no annotations and no output schema, this description is unusually complete. It covers matching, zone/screen interpretation, replacement, precedence, timing, exclusions, and failure modes. The only minor omission is return-value/confirmation behavior, but an agent has enough to select and call the tool correctly.

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

Parameters5/5

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

Although schema descriptions already cover all three parameters at 100%, the description adds substantial meaning: how 'app' is matched, why bundle id is safest, what 'zone' visually refers to, how 'screen' identity survives renumbering, and the consequence of omitting it. This goes well beyond the schema.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Make an app's windows open into a numbered zone from now on.' It clearly distinguishes the tool from sibling snap_window by stating it applies only to windows opened after the rule is set, not already-open windows.

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?

It explicitly says when not to use it ('use snap_window for those') and describes precedence behavior: a rule beats the app's last-window habit and both beat filling an empty zone. It also states excluded apps, replacement semantics, and exact-name priority, giving an agent unambiguous selection and invocation guidance.

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

Deploy Server

Other Tools