Skip to main content
Glama

Change the electrical project

edit_electrical
Destructive

Assign electrical circuits and voltage, route power/data/TV cables, and compute cable lengths and materials for telecom and electrical projects.

Instructions

Change the electrical and telecom project (the electrical tool reads it: check, circuits, wifi). assign {ids, circuit, va?} — or the whole division at once, circuits {"C1": [ids], "C2": [ids]} — writes the circuits (and power, and volts 127|220 per point — a 220 V outlet makes its circuit 220 V) on points in one undoable step. voltage {volts?, short_ka?, earthing?: TN-S|TN-C-S|TT}. cable {kind: power|data|tv, pts} (with ids or circuit instead of pts, it is a route): draws a run of the electrical project, told apart on the plan (power solid, network dashed, TV dash-dot); check then reports cables_m, the length by kind with a tenth for the drops, and network or TV points no run reaches, or a telecom panel none reaches. route {kind: power|data|tv, ids? | circuit?, via?: ceiling|floor|wall|tape, cat?: cat5e|cat6|cat6a, from?}: lays the run the way it is built, along the walls and inside them (or in the slab), from the nearest panel of its kind to the points (all of the kind when none given), sharing the trunk, and draws it replacing the earlier run of the same circuit and the cables drawn by hand to its points (listed in replaced_drawn); replies {via, suggested, length_m {horizontal, vertical, total}, by_premise_m, bends, materials: [[item, qty, unit]]} — conduit, boxes, wire by conductor, cable, connectors. via=tape lays adhesive flat wiring tape (Eletrofitas) on the surface of walls and ceiling for power only: the model by the load and whether any point is a socket (sockets take the earthed EF18.9.18), refused over its rating or in a bathroom or outdoors, bought as Leroy Merlin kits by piece (codes, prices, splices) with tape {model, tracks, rated_a, load_a, earthed, pieces_m, splices, total_brl, notes}. Without via it takes the cheapest premise that can be built; a via that cannot reach a point (wall with a point out of every wall; ceiling with a low point out of every wall, nowhere to drop) is refused naming the points. wifi {ids, standard?, poe?, uplink?, bands?} writes those on the access points (wifi-point), in one undoable step. assign on automation points takes standby_w, on a dimmer max_w, on a panel modules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vaNoPower per point, VA, instead of the norm's default
catNoFor `route` of data: `cat5e`, `cat6` (default) or `cat6a`
idsNoPoint ids for `assign`
poeNoFor `wifi`: whether `ids` are fed by their data cable (`PoE`)
ptsNoFor `cable`: the run's points `[[x,y], …]`, cm
viaNoFor `route`: where the run passes, `ceiling` (slab, dropping in the walls), `floor` or `wall`. Omitted: the cheapest that can be built
bandNoFor `wifi`: the band the suggestion aims at, `2.4`, `5` (default) or `6`
fromNoFor `route`: the panel it starts from; default the nearest of its kind
kindNoFor `cable`: what the run carries, `power`, `data` or `tv`
bandsNoFor `wifi`: the bands they radiate when fewer than their generation's, e.g. `2.4,5` for a dual-band Wi-Fi 7
max_wNoFor `assign` on a dimmer: the most lighting it takes, W
voltsNoSupply voltage, V; with `assign`, the points' own, 127 or 220
actionNo`assign`: put `ids` on `circuit` (empty takes them off), with `va` to set their power; `voltage`: the supply, 127 or 220 V; `cable`, `route` or `wifi`
uplinkNoFor `wifi`: the access points' wired uplink, Gbps (1, 2.5, 5, 10)
circuitNoCircuit name, e.g. `C3`
modulesNoFor `assign` on a distribution panel: the DIN modules it holds
circuitsNoFor `assign`: the whole division at once, `{"C1": [ids], "C2": [ids]}`, in one undoable step
earthingNoFor `voltage`: the earthing scheme, `TN-S`, `TN-C-S` or `TT`
short_kaNoFor `voltage`: the presumed short-circuit current at the delivery point, kA, as the utility informs it
standardNoFor `wifi`: the access points' standard, `wifi5`, `wifi6`, `wifi6e` or `wifi7`, written on `ids`
standby_wNoFor `assign` on automation points: standby consumption, W

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vNoPlan version written to, when there are several
okNoAlways true
idsNoIds created or touched
revNoPlan revision
runNoThe run: <system>:<circuit|all|ids>
viaNoWhere it runs: ceiling, floor, wall (or tape)
goneNoIds removed, or their count
tapeNovia=tape: the tape light system
textNoThe reply as written
addedNoIds added, or their count
bendsNoBends along the run
changedNo{id, from, to} per element changed; a count past 20
coverageNoaction=wifi: [room, band, median, worst, good, grade]
length_mNoMetres: {horizontal, vertical, total}
warningsNoData points past 90 m
materialsNoBill of materials: [item, quantity, unit]
suggestedNoRoute: the one the rules suggest; action=wifi: where access points would go
propertiesNoProject properties changed
annotationsNoAnnotation switches {from, to}
by_premise_mNoTotal metres by route: {ceiling, floor, wall}; a reason instead where one is impossible
access_pointsNoaction=wifi: [id, standard, bands, uplink]
replaced_drawnNoHand-drawn lines this run replaced

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses extensive behavioral details: writes circuits, draws cables, replaces earlier runs, refuses routes that cannot reach points, and lists refusal conditions (e.g., via=tape refused over rating, in bathrooms). It also describes side effects like replacing drawn cables and provides output details for route actions. These go far beyond the annotation and give the agent a precise model of what the tool will do.

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

Conciseness3/5

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

The description is a single dense wall of text covering six sub-actions with semicolon-separated clauses. It is not concise, and the lack of bullet points or clear sections makes it harder for an agent to scan. However, every sentence carries substantive information, so it is not redundant. Given the tool's complexity, a score of 3 reflects the poor structure relative to the potential for clearer organization.

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?

The description is remarkably complete for a tool of this complexity. It covers all sub-actions, their parameters, behavioral side effects, refusal conditions, and output descriptions for route. An output schema exists, so return values are already specified. Nothing essential for correct invocation appears missing, making this a complete reference for an agent.

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?

While the schema has 100% coverage with per-parameter descriptions, the description adds rich inter-parameter semantics: it explains how `circuit` and `circuits` relate, how `via` affects routing, how `pts` vs `ids`/`circuit` changes cable vs route behavior, and how `volts` interacts with `assign`. It also documents defaults (e.g., cat6 default, cheapest via when omitted) and conditions (e.g., sockets require earthed tape). This is far more than the schema provides, earning a 5.

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 'Change the electrical and telecom project', which is a specific verb + resource. It then details multiple sub-actions (assign, voltage, cable, route, wifi) that clearly distinguish this tool from siblings like edit_plumbing and edit_cameras. It also explicitly contrasts itself with the 'electrical' read tool, making its purpose and scope unambiguous.

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

Usage Guidelines4/5

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

The description implies the tool is for writing while 'electrical' is for reading ('the electrical tool reads it'), providing a clear usage context. It does not, however, explicitly enumerate alternatives or state when not to use this tool (e.g., for plumbing or camera edits), which would earn a 5. The guidance is implicit rather than explicit, so a 4 is appropriate.

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