Skip to main content
Glama
ChanMeng666

ArchLang

by ChanMeng666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Compile ArchLang → SVG, ASCII, Plan JSON or PNG

compile
Read-onlyIdempotent

Converts ArchLang .arch source or Plan JSON into SVG, ASCII, JSON, or PNG floor plans and returns diagnostics to correct errors.

Instructions

Compile ArchLang .arch source (or a Plan-JSON object) to an SVG floor plan, or with format to a plain-text ASCII plan ("txt"), Plan JSON ("json") or an image ("png"). Format "json" returns the plan as an object, with schema naming its JSON Schema; passed back as plan_json it compiles to the same drawing, unless the plan uses a part of the language Plan JSON does not carry (the sheet, styles, curves, roofs, storeys, place, accessibility metadata). Returns the output plus diagnostics; a diagnostic usually carries a byte span with line/col and an E_/W_ code, and often a fix, sometimes one the fix tool can apply. Errors come back as data, never as exceptions: read diagnostics and correct the source. A multi-storey plan (level <n> { … }) returns the lowest storey in output and every storey in pages[] ({ level, name, output }); pass level to render just one. format "png" returns the usual result as text, then the drawing (the lowest storey, or level) as image content, as wide as width says; it needs the optional renderer @resvg/resvg-js, and without it the call returns ok:false with an error saying how to install it.

Input Schema

NameRequiredDescriptionDefault
levelNoRender only this storey of a multi-storey plan. An undeclared level is an error, not a guess.
widthNopng only (any other format refuses it): the image width in pixels, clamped to 256-4096, and narrower for a tall plan so neither side exceeds 4096; default 1600.
formatNosvg (default), txt (zero-dependency ASCII), json (Plan JSON, the shape `plan_json` takes) or png (an image; needs the optional renderer).
sourceNoArchLang source (a `plan "…" { … }`). Provide this OR plan_json.
overlayNoDraw an opt-in circulation overlay (SVG only).
plan_jsonNoPlan JSON (RPLAN shape) as an alternative to `source`; converted to .arch then compiled.
accessibleNoEmit <title>/<desc>/role/aria accessibility metadata (SVG only).

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?

Annotations already carry readOnly/idempotent/non-destructive, yet the description adds real substance: errors returned as data rather than exceptions, diagnostics with byte spans, line/col, E_/W_ codes and suggested fixes, multi-storey behavior (`output` = lowest storey, `pages[]` for all), and the optional @resvg/resvg-js dependency that yields ok:false with install instructions for png. This is exactly the context an agent cannot infer from the annotations.

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?

Front-loaded with the compile action and format list, and every subsequent clause (round-trip caveats, diagnostics-as-data, storeys, png dependency) carries distinct information. It is a single dense paragraph that would read better as short sections, which keeps it off a 5.

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?

There is no output schema, so the description must describe return values — and it does: the output, `diagnostics` with spans/codes/fixes, `pages[]` structure for multi-storey plans, and the png result containing both text and image content. Combined with the dependency and error-model notes, an agent has everything needed to call and interpret it.

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 coverage is 100%, so baseline is 3, but the description goes further: it names the lossy feature set that Plan JSON does not carry (sheet, styles, curves, roofs, storeys, `place`, accessibility metadata), which the schema cannot express, and clarifies that `level` selects one storey while the default returns the lowest. `width` and `overlay` nuance stays in the schema and isn't echoed, keeping this at 4.

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 (compile) and resource (ArchLang `.arch` source or Plan JSON) and enumerates every output form (SVG/ASCII/Plan JSON/PNG) up front. This clearly separates it from read-only siblings like validate, lint and score, which check rather than produce artifacts.

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?

Explains the input alternatives (source OR plan_json), the round-trip path through format "json" and back via `plan_json`, and that `fix` can apply some suggested fixes. It never explicitly contrasts itself with validate/lint or states when NOT to compile, so it falls short of full routing guidance.

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

Deploy Server

Other Tools