uniwire

Official

by uniwire-dev

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Edit an electrical diagram

apply_patch

Read-onlyIdempotent

Edit electrical diagrams by node ID to change ratings, add circuits, move loads, rename nodes, or link controls. Returns the updated document or names the failing operation.

Instructions

Edit an electrical diagram by node id (change a rating, add a circuit, move a load...) and return the new document. ops (applied in order): {"op":"set","id":ID,"path":"in_A","value":20} (null value removes; no id = document root, e.g. path "installation.earthing"); {"op":"add","parent":ID,"node":{...},"index":0} (or "at":"sources"); {"op":"remove","id":ID}; {"op":"move","id":ID,"parent":ID,"index":0}; {"op":"rename","id":ID,"new_id":NEW}; {"op":"link","link":{"kind":"control","from":ID,"to":ID}}; {"op":"unlink","id":LINK_ID} or {"op":"unlink","from":ID,"to":ID,"kind":K}. On failure returns ok=false and errors naming the failing op index (null = validation of the result).

Input Schema

TableJSON Schema

Name	Required	Description
`ops`	Yes	The edit operations, applied in order (list, or its JSON text): see the description for the operation forms.
`document`	Yes	The uniwire document of the electrical installation: a JSON object, or its JSON text, as returned by get_example, apply_patch or normalize (a file path is accepted when the server runs locally).
`validate`	No	Validate the resulting document (default true).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.3-devOct 15, 2026

addedInput schema / properties / document / description

Added value: +"The uniwire document of the electrical installation: a JSON object, or its JSON text, as returned by get_example, apply_patch or normalize (a file path is accepted when the server runs locally)."

addedInput schema / properties / ops / description

Added value: +"The edit operations, applied in order (list, or its JSON text): see the description for the operation forms."

addedInput schema / properties / validate / description

Added value: +"Validate the resulting document (default true)."

First observedv0.1.1Oct 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered; the description adds real value beyond that by disclosing that ops are applied in order and that failures return ok=false with errors naming the failing op index (null meaning result validation failed). It doesn't explicitly confirm that edits are non-persisting (returned rather than saved), which the readOnly annotation implies but the text never states outright.

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?

Purpose and return value are front-loaded in the first clause, and the dense op examples each carry required information rather than filler. The block is long and the inline JSON snippets are syntactically crowded, but every line earns its place given the schema defers op detail to the text.

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?

With an output schema present, return values need not be explained, yet the description still covers the failure shape, which is genuinely useful. The document and validate parameters are documented in-schema. A brief note on non-persistence/idempotency would round it out, but nothing needed to invoke it correctly is missing.

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?

The ops parameter's own schema is an opaque array/string with additionalProperties:true and defers with 'see the description', so the description is the only source of the op grammar — set/add/remove/move/rename/link/unlink, their fields, ordering, and the null-value-removes and no-id-equals-root conventions. That is substantive semantics no structured field provides.

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?

States a specific verb and resource ('Edit an electrical diagram by node id'), enumerates representative edit kinds (rating, circuit, load), and says the new document is returned. This cleanly separates it from read-only siblings like normalize, validate, render and viewer_link without needing their schemas.

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

Usage Guidelines3/5

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

Usage is implied by the op grammar rather than stated: an agent can infer 'use this to make edits' but the description never says when to prefer apply_patch over normalize/render/validate, nor any ordering or prerequisite for getting a document first. Mentions get_example/apply_patch/normalize only as document sources, which is a weak routing hint.

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

Deploy Server