3D New Era AI

Overview Schema Source Related Servers Discussions Admin

Check the electrical project

electrical

Read-only

Review power and telecom points, circuits, panel and Wi-Fi coverage against NBR 5410/16264, returning findings, load schedules and access point suggestions.

Instructions

Electrical and telecom review, NBR 5410 and NBR 16264: points are the catalog's electrical pieces (outlets, switches, lighting points, panels, RJ45, TV, Wi-Fi, automation) plus every fixture that lights. action check (default) answers {points:{kind:count}, findings:[[sev, place, msg, src, key, accepted?]], pending, orphaned, sources}: outlets and lighting per room, circuits, DR, the panel, voltage drop, access points' cables. circuits answers the load schedule, rows [name, kinds, points, VA, V, A, wire mm², breaker A, DR], with main_breaker {a, phases, load_a_per_phase} and panel {devices, modules, dps, earthing, icn_ka, selective}. wifi {band?} answers access_points, coverage per room and band [[room, band, median dBm, worst dBm, share at -67 dBm or better, grade]] and suggested ceiling points. What each check demands: rules topic=electrical. Changes are edit_electrical; accept marks a finding right as drawn.

Input Schema

TableJSON Schema

Name	Required	Description
`band`	No	For `wifi`: the band the suggestion aims at, `2.4`, `5` (default) or `6`
`level`	No	Storey to review, an id like `lv3` (default: the one shown)
`action`	No	`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

Name	Required	Description	Default
`rev`	No
`panel`	No
`points`	No
`pending`	No
`sources`	No
`cables_m`	No
`circuits`	No
`coverage`	No
`findings`	No
`orphaned`	No
`total_va`	No
`standby_w`	No
`suggested`	No
`main_breaker`	No
`access_points`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv3.0.0Sep 30, 2026

addedInput schema / properties / action / enum

Added value: +[
+  "check",
+  "circuits",
+  "wifi"
+]

addedInput schema / properties / level

Added value: +{
+  "description": "Storey to review, an id like `lv3` (default: the one shown)",
+  "type": "string"
+}

removedOutput schema / properties / access_points / description

Removed value: -"action=wifi: [id, standard, bands, uplink]"

removedOutput schema / properties / cables_m / description
```
Removed value: -"Cable metres: {power, data, tv}"
```

removedOutput schema / properties / circuits / description

Removed value: -"action=circuits: [name, kinds, points, VA, V, A, wire mm², breaker A, DR]"

removedOutput schema / properties / coverage / description

Removed value: -"action=wifi: [room, band, median, worst, good, grade]"

removedOutput schema / properties / findings / description

Removed value: -"Rows [severity erro|alerta|dica, place, message, source, key, accepted reason?]"

removedOutput schema / properties / main_breaker / description

Removed value: -"action=circuits: {a, phases, load_a_per_phase}"

removedOutput schema / properties / orphaned / description

Removed value: -"Acceptances whose finding is gone: [key, reason, successor key?]"

removedOutput schema / properties / panel / description

Removed value: -"action=circuits: the distribution panel"

removedOutput schema / properties / pending / description
```
Removed value: -"Findings not accepted"
```
removedOutput schema / properties / points / description
```
Removed value: -"Points by kind"
```
removedOutput schema / properties / rev / description
```
Removed value: -"action=wifi: plan revision"
```

removedOutput schema / properties / sources / description

Removed value: -"Standards cited, by code: [title, tier, url]"

removedOutput schema / properties / standby_w / description
```
Removed value: -"action=circuits: standby watts"
```

removedOutput schema / properties / suggested / description

Removed value: -"action=wifi: where access points would go"

removedOutput schema / properties / total_va / description
```
Removed value: -"action=circuits: total load VA"
```

First observedv0.1.0Sep 24, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavior beyond that: it spells out the return shapes for each action ({points, findings, pending, orphaned, sources}, the circuits row layout, wifi per-room dBm grades) and points to `rules` topic=electrical for check requirements. Return behavior is somewhat covered by the output schema, so not a full 5.

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?

Dense, comma-spliced sentences with heavy domain jargon and parenthetical return-shape dumps run together. The action semantics are front-loaded reasonably, but several clauses would be clearer as a list, and some output detail duplicates the schema.

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?

For a read-only review tool with an output schema and full annotation coverage, the description supplies enough: what each action evaluates, what the other paths are, and where requirements live (`rules` topic=electrical). Only the verbose, uneven structure keeps it from being fully complete.

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?

Schema description coverage is 100%, so all three params are already documented; baseline would be 3. The description compensates by explaining what each action actually returns and how `level`/`band` feed the wifi and per-storey views, adding meaning the schema does not carry.

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

Purpose4/5

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

States a specific verb+resource: an electrical and telecom review against NBR 5410/NBR 16264, with the `check`/`circuits`/`wifi` actions named. It also explicitly routes mutations to the `edit_electrical` sibling, so the agent can separate it from neighbors. It stops short of a crisp one-line purpose, burying the intent in dense enumeration.

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?

Gives explicit when-to-use for each action (`check` default, `circuits` for load schedule/panel, `wifi` for coverage) and names alternatives for the other paths: changes go to `edit_electrical`, marking a finding goes to `accept`. It does not state any when-not-to-use exclusions, keeping it below a 5.

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