Skip to main content
Glama

Check the electrical project

electrical
Read-only

Check electrical and telecom designs against NBR 5410 and NBR 16264: validate points, circuits, panel loads, and Wi-Fi coverage, then get layout suggestions.

Instructions

Electrical and telecom project, NBR 5410 and NBR 16264 (residential cabling). Points are the electrical pieces (catalog electrical: outlets, switches, lighting points, panel, network-outlet RJ45, tv-outlet, wifi-point, telecom-panel) plus every fixture that lights. check (default): {points:{kind:count}, findings:[[sev, place, msg, src, key, accepted?]], pending, orphaned, sources} — orphaned lists acceptances whose finding is gone (the accept tool marks findings looked at, and its prune drops those) — a ceiling lighting point per room, general-use outlets per room (kitchens and laundries one per 3.5 m of perimeter, bathrooms one by the basin, living rooms and bedrooms one per 5 m), RJ45 and TV outlets per room as NBR 16264 table 1 recommends (2 RJ45 and 1 TV in bedrooms, living rooms, offices, kitchens and laundries; 3 and 2 in a home theater; 1 and 1 elsewhere; a Wi-Fi point is not an RJ45 outlet), a power outlet by the telecom panel, a distribution and a telecom panel, points without a circuit, lighting and outlets sharing a circuit, a dedicated load not alone. circuits: rows [name, kinds, points, VA, V, A, wire mm², breaker A, DR] and main_breaker {a, phases, load_a_per_phase}: the supply to ask for, by Enel SP's categories on 127/220 V (single-phase up to 12 kW with no 220 V circuit, two-phase up to 20 kW, three-phase up to 75 kW) and the smallest of its fixed entry breakers (50, 63, 80, 100… A) — power by NBR 5410 (lighting per room by area: 100 VA up to 6 m² and 60 VA per whole 4 m² beyond, shared by its points; 600 VA for each of the first three outlets of a kitchen, laundry or bathroom, 100 VA after and elsewhere; dedicated points at their rated power, a shower 7500 W and air conditioning 1500 until written) unless set; the section is the smallest from 1.5 mm² (lighting) or 2.5 (with outlets) whose capacity, corrected for the circuits sharing its conduit on the laid-out runs (table 42, or grouping written on the project), admits a breaker between the current and it; DR on every point of a room with a bath or shower, on kitchen, laundry, service and garage points (lighting at 2.50 m or higher excepted) and on outdoor and balcony outlets; a shower over 4.4 kVA runs on 220 V. check also says lighting and outlets sharing a circuit only when NBR 5410 9.5.3.3 forbids it (over 16 A, or all lighting or all outlets on shared circuits), kitchen and laundry outlets sharing with anything else, equipment over 10 A not alone, and a voltage drop over 4 % to the farthest point of a laid-out run. circuits also gives panel {devices: [[device, count, DIN modules]], modules {used, capacity, capacity_written, spare}, dps, earthing, icn_ka, selective}: one-pole breakers for 127 V circuits and two-pole for 220 V between phases, a two-pole DR per circuit that needs one, the main breaker, the surge protector (DPS class II, a module per phase and neutral) and NBR 5410's spare ways (2 up to 6 circuits, 3 up to 12, 4 up to 30, 15 % above); capacity is the panel's modules (assign modules on it) or a guess from its size, and check says when it does not fit, when the main breaker is under twice the largest partial (selectivity) and when the short-circuit level was assumed. Automation (catalog smart-relay, smart-switch, dimmer, presence-sensor, smart-lock): each draws its standby on its circuit (assign standby_w; relay, dimmer and sensor 1 W, smart switch 1.2 by default, from manufacturers' sheets), circuits reports standby_w, and check asks a relay or smart switch for a neutral in its box, a dimmer for the room's lighting to fit its max_w (default 1.1 A at the supply voltage, some 140 W at 127 V) and pass 10 W, a ceiling sensor to be between 2.2 and 3 m (manufacturers install at about 2.4) and to see the room's far corner (about 1.45 × its height), a lock to sit on a door. wifi {ids?, standard?: wifi5|wifi6|wifi6e|wifi7, poe?, band?: 2.4|5|6}: writes the standard and PoE on access points (wifi-point) when given, and replies {access_points: [[id, standard, bands, uplink]], coverage: [[room, band, median dBm, worst dBm (9 places in 10), share at -67 dBm or better, grade]], suggested: {standard, band, points: [[x, y, z, room]], short: [rooms still under -67 dBm]}} — signal estimated from free-space loss, distance and each wall crossed by its material and thickness (a door or window where the path goes through one), per band; the suggestion is the fewest ceiling points (up to four) at room centres covering the rooms people use. check also asks each access point for its data cable, power (an outlet within 1.5 m or poe) and a cable category that carries its uplink (uplink up to 2.5 GbE: Cat 5e; 5 GbE: Cat 6; 10 GbE: Cat 6A). Circuit numbers are drawn next to the points on the plan, and with edit_annotations(legend=true) the load schedule under the legend. Changes — assign, voltage, cable, route, and the standard, PoE, uplink or bands of access points — are edit_electrical.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bandNoFor `wifi`: the band the suggestion aims at, `2.4`, `5` (default) or `6`
actionNo`check` (default): points by kind and what the norm finds; `circuits`: the load schedule and the panel; `wifi`: coverage and a suggestion

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
revNoaction=wifi: plan revision
panelNoaction=circuits: the distribution panel
pointsNoPoints by kind
pendingNoFindings not accepted
sourcesNoStandards cited, by code: [title, tier, url]
cables_mNoCable metres: {power, data, tv}
circuitsNoaction=circuits: [name, kinds, points, VA, V, A, wire mm², breaker A, DR]
coverageNoaction=wifi: [room, band, median, worst, good, grade]
findingsNoRows [severity erro|alerta|dica, place, message, source, key, accepted reason?]
orphanedNoAcceptances whose finding is gone: [key, reason, successor key?]
total_vaNoaction=circuits: total load VA
standby_wNoaction=circuits: standby watts
suggestedNoaction=wifi: where access points would go
main_breakerNoaction=circuits: {a, phases, load_a_per_phase}
access_pointsNoaction=wifi: [id, standard, bands, uplink]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior1/5

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

The description is unusually transparent about calculations, defaults, assumptions, and exceptions, but it also says 'wifi ... writes the standard and PoE on access points' while annotations declare `readOnlyHint: true`. Even though the final sentence routes changes to `edit_electrical`, the explicit 'writes' claim contradicts the read-only annotation.

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

Conciseness2/5

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

The content is dense and valuable, but it is one enormous unstructured paragraph of hundreds of words. It is front-loaded with scope, but an agent would struggle to scan the relevant action-specific details quickly.

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

Completeness4/5

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

Covers outputs, defaults, norm references, exceptions, assumptions, and routing to `edit_electrical`, making it mostly complete for invoking the tool. The write/read-only contradiction and the undocumented wifi input fields keep it from being fully trustworthy.

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

Parameters2/5

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

The schema documents `action` and `band` at 100%, and the description adds useful defaults such as `check` for action and `5` for band. However, it introduces `wifi {ids?, standard?, poe?}` inputs that are absent from the schema, which has `additionalProperties: false`, so an agent cannot tell which values are actually accepted.

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?

Clearly states it checks the electrical/telecom project against NBR 5410 and NBR 16264, with three distinct actions (`check`, `circuits`, `wifi`). It differentiates itself by explicitly routing changes to `edit_electrical`.

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?

States that `check` is the default action and explicitly routes modifications to `edit_electrical`. It does not enumerate exclusions against every sibling check tool, but the scope and the edit-tool alternative are clear enough.

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