Skip to main content
Glama
circuitry-dev

Circuitry MCP Server

Official

layout.createSection

Creates HTML sections with proper layout structure in Circuitry Designer mode, ensuring correct stacking and positioning for headers, footers, and content containers.

Instructions

PREFERRED METHOD for creating HTML in Designer mode.

Creates both a layout container AND an HTML component inside it together. This ensures:

  • Proper parent-child structure

  • Correct vertical stacking (content sections stack below each other)

  • Clean preview/export with proper positioning

Use container param for auto-positioning:

  • "header" - positions at top

  • "footer" - positions at bottom

  • "content" - stacks below previous content sections

CRITICAL CSS STRUCTURE - Prevents zoom scaling bugs:

NEVER put visual styles on :host - causes border-radius to scale incorrectly when zooming.

WRONG:

:host {
  background: #1a1a3e;
  border-radius: 16px;
  padding: 20px;
}

CORRECT:

:host { display: block; }
.card {
  background: #1a1a3e;
  border-radius: 16px;
  padding: 20px;
}

Always wrap HTML content in a container div and apply all visual styles (background, border-radius, padding, box-shadow) to that inner element, NOT to :host.

Headers & Footers MUST have opaque backgrounds - content scrolls behind them:

  • Use solid color: background: #1a1a3e;

  • Or gradient: background: linear-gradient(...);

  • Or blur: background: rgba(26,26,62,0.9); backdrop-filter: blur(10px);

Cards narrower than screen should be centered:

  • Use margin: 16px auto; in CSS to center horizontally

  • Or set position.x to center: (screenWidth - cardWidth) / 2

Returns both layoutId and htmlId so you can reference either element later.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name for the section (e.g., "Profile Card", "Settings Menu")
layoutTypeNoLayout type: card, container, header, footer, etc.
containerNoSemantic container type - determines auto-positioning: header (top), footer (bottom), content (stacked)
htmlYesHTML content for the section
cssNoCSS styles for the HTML content
jsNoOptional JavaScript for interactivity
positionNoPosition { x, y } - auto-calculated based on container if not provided
dimensionsNoDimensions { width, height } - uses layout type defaults if not provided
screenIdNoTarget screen ID or name (uses selected screen if not specified)
autoAnalyzeNoRun layout.analyze with autoFix after creation (default: false)
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It excels by detailing behavioral traits: it ensures proper parent-child structure and vertical stacking, prevents zoom scaling bugs with specific CSS rules, requires opaque backgrounds for headers/footers, handles auto-positioning based on container, and returns both layoutId and htmlId for future reference. This covers creation, styling constraints, and output behavior comprehensively.

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?

The description is well-structured and front-loaded with the primary purpose and key benefits. It uses bold text and code blocks effectively to highlight critical information. While it's detailed, every sentence earns its place by providing essential guidelines, examples, and warnings. A slight deduction to 4 due to the length, but it remains focused and avoids redundancy.

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?

Given the complexity of a 10-parameter tool with no annotations and no output schema, the description is highly complete. It covers the tool's purpose, usage scenarios, behavioral details, parameter semantics, and output information (returns layoutId and htmlId). It addresses potential pitfalls and provides practical examples, making it sufficient for an agent to understand and invoke the tool correctly in context.

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?

The schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the semantic use of the 'container' param for auto-positioning (header, footer, content) and providing context for 'position' and CSS-related parameters through examples and guidelines. However, it doesn't deeply elaborate on all 10 parameters, keeping it at a 4 for meaningful but not exhaustive enhancements.

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?

The description clearly states the tool's purpose: it's the 'PREFERRED METHOD for creating HTML in Designer mode' that 'Creates both a layout container AND an HTML component inside it together.' It distinguishes itself from siblings like 'layout.create' or 'html.create' by emphasizing the combined creation with proper structure and positioning, which is specific and differentiated.

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?

The description provides explicit usage guidance: it's preferred for HTML creation in Designer mode, specifies when to use the 'container' param for auto-positioning (header, footer, content), and offers alternatives like manual positioning with 'position.x'. It also includes critical exclusions, such as avoiding styles on :host to prevent bugs, ensuring headers/footers have opaque backgrounds, and centering narrow cards.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/circuitry-dev/circuitry-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server