Skip to main content
Glama

logisim_build

Draw a new Logisim circuit from a netlist and save it as .circ. It automatically places and wires components, verifies connections, and renders an image.

Instructions

Draw a NEW Logisim circuit from a netlist and save it as .circ (an existing file is only replaced with overwrite: true; to change an existing hand-drawn circuit, describe it with logisim_inspect first). Placement (signal flows left to right) and wiring are automatic; the file is then loaded back into Logisim to confirm every connection, checked for mistakes and rendered as an image.

components: [{"id": "A", "type": "input"}, {"id": "g1", "type": "and", "inputs": 3}, ...] id: Latin identifier, unique; it is also the label of pins, LEDs, probes and clocks. type: input, output, clock, constant, led, probe, button, dipswitch, not, buffer, and, or, nand, nor, xor, xnor, mux, demux, decoder, encoder, adder, subtractor, multiplier, comparator, shifter, negator, dff, tff, jkff, srff, register, counter, shiftregister, ram, rom, splitter, tunnel, hexdisplay, sevensegment (or any exact Logisim name; see logisim_components for ports and attributes). optional: width (bits), inputs (gate inputs), value (constant), select (mux/decoder select bits), fanout (splitter), facing, label, caption (free text shown next to it, any language), column (0 = leftmost column), at [x, y] (manual position, px), attrs {raw Logisim attributes}. connections: ["A -> g1.in0, g2.a", "g1 -> F", "clk: CLK -> ff1.clk, ff2.clk", "X, Y.in"] "source -> sink, sink"; a port is id.port. A bare id means the component's only port (pins, LEDs, clocks, constants) or its only output (left of ->) / only input (right of ->). Connections that share a port merge. Port names: gates out, in0..in(n-1) (also a, b, c...); not/buffer out, in; mux in0.., sel, out (en); decoder out0.., sel; adder/subtractor a, b, out, cin/bin, cout/bout; comparator a, b, gt, eq, lt; dff d, clk, q, nq, clr, pre; tff t, ...; jkff j, k, clk, q, nq, clr, pre; srff s, r, clk, q, nq, clr, pre; register q, d, clk, clr, en; counter q, d, clk, clr, load, ud, en, carry; splitter bus, b0..b(n-1); ram addr, out, in, ld, st, clk; rom addr, out; dipswitch s1..sN; any port also as #index. tunnels: nets drawn with labelled tunnels instead of long wires, by net name or source id (e.g. ["CLK"]). rails: input pin ids (and ids of NOT gates fed directly by such a pin) drawn textbook style: the pins stand at the top left and each signal runs down the page as a vertical bus that gates tap with horizontal branches. Recommended for combinational logic, e.g. ["A", "nA", "B", "nB", "C"]. title: text above the circuit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the .circ file (absolute, or relative to the working folder)
checkNoSimulate to find conflicts/oscillation (default true)
railsNo
scaleNoImage scale (default 1.5, reduced automatically for large circuits)
titleNo
renderNoReturn a picture (default true)
tunnelsNo
overwriteNoReplace the file if it already exists (default false)
componentsYes
connectionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses automatic placement/wiring, the post-write verification loop ('loaded back into Logisim to confirm every connection'), mistake checking, and image rendering, plus the destructive-replacement condition. It stops short of saying what payload or errors surface when verification fails.

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?

Long, but the first sentence front-loads purpose, overwrite caveat, and the sibling alternative, and the remainder is a labeled mini-grammar (components/connections/tunnels/rails/title) where each line earns its place for a DSL. Slightly dense, but appropriate for the format it must teach.

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?

A 10-parameter, no-annotation, no-output-schema tool needs the description to explain outcomes; it does describe the write-verify-render pipeline, which substitutes for an output schema. Remaining gap is error/failure behavior and whether the verification step can block or fail the build.

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?

Schema coverage is only 50% and 'components'/'connections' are bare arrays in the schema, so the description does the heavy lifting — it documents the id/type grammar, the full component type list, optional per-component fields, the connection string syntax, port naming per gate type, tunnel and rail semantics, and title. This is far beyond what the schema 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?

Opens with a specific verb+resource+scope: 'Draw a NEW Logisim circuit from a netlist and save it as .circ'. It explicitly distinguishes itself from logisim_inspect (for editing hand-drawn circuits) and routes port/attribute questions to logisim_components.

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?

States the when-not condition clearly ('an existing file is only replaced with overwrite: true') and names the alternative tool for the adjacent task (logisim_inspect for changing an existing hand-drawn circuit). The rails section even recommends when to use it ('Recommended for combinational logic').

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