Skip to main content
Glama
kennic

FrameLayoutKit MCP Server

by kennic
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

FrameLayoutKit MCP Server

A Model Context Protocol (MCP) server for FrameLayoutKit, providing AI-powered assistance for iOS developers using the FrameLayoutKit framework. This server helps generate Swift UIKit code using FrameLayoutKit's intuitive syntax, convert existing Auto Layout code, validate layouts, and provide migration guidance.

Features

🚀 Code Generation

Generate FrameLayoutKit code for all layout types:

  • FrameLayout - Single view container with padding and alignment

  • VStackLayout/HStackLayout - Vertical/horizontal stacks

  • ZStackLayout - Overlapping views

  • DoubleFrameLayout - Two-view layouts with distribution control

  • GridFrameLayout - Multi-row/column grid layouts

  • ScrollStackView - Scrollable stacks

  • FlowFrameLayout - Wrapping flow layouts

🔄 Auto Layout Conversion

Convert existing UIKit Auto Layout code to FrameLayoutKit:

  • NSLayoutConstraint conversion

  • UIStackView migration

  • Layout anchor transformation

  • Preserves code structure and comments

✅ Code Validation

Validate FrameLayoutKit code for:

  • Syntax correctness

  • Semantic validity

  • Best practices

  • Performance optimization suggestions

📋 Migration Assistance

Generate comprehensive migration guides:

  • Project-wide analysis

  • File-by-file recommendations

  • Effort estimation

  • Step-by-step migration strategy

Related MCP server: MCP Xcode

Installation

# Clone the repository
git clone https://github.com/kennic/framelayoutkit-mcp.git
cd framelayoutkit-mcp

# Install dependencies
npm install

# Start the server
npm start

Configuration

For Claude Desktop

Add to your Claude configuration file:

{
  "mcpServers": {
    "framelayoutkit": {
      "command": "node",
      "args": ["/path/to/framelayoutkit-mcp/src/index.js"],
      "env": {}
    }
  }
}

For VS Code with Continue

Add to your Continue configuration:

{
  "models": [{
    "title": "Claude with FrameLayoutKit",
    "provider": "anthropic",
    "model": "claude-3-sonnet",
    "mcpServers": [{
      "name": "framelayoutkit",
      "command": "node",
      "args": ["./framelayoutkit-mcp/src/index.js"]
    }]
  }]
}

Usage Examples

Generate a VStackLayout

// Request
{
  "tool": "generate-framelayout",
  "arguments": {
    "layoutType": "VStackLayout",
    "views": [
      {
        "name": "titleLabel",
        "type": "UILabel",
        "text": "Welcome"
      },
      {
        "name": "button",
        "type": "UIButton",
        "text": "Get Started"
      }
    ],
    "configuration": {
      "spacing": 20,
      "padding": 16,
      "distribution": "center"
    }
  }
}

Generated Swift code:

// Add views to stack
let titleLabel = {
    let label = UILabel()
    label.text = "Welcome"
    return label
}()
let button = {
    let button = UIButton(type: .system)
    button.setTitle("Get Started", for: .normal)
    return button
}()

let stackLayout = VStackLayout()
stackLayout.spacing(20).distribution(.center).padding(16)
stackLayout + titleLabel
stackLayout + button

Convert Auto Layout to FrameLayoutKit

// Request
{
  "tool": "convert-autolayout",
  "arguments": {
    "swiftCode": "/* Your existing Auto Layout code */",
    "options": {
      "migrationStrategy": "conservative",
      "useOperatorSyntax": true
    }
  }
}

Validate FrameLayoutKit Code

// Request
{
  "tool": "validate-framelayout",
  "arguments": {
    "swiftCode": "/* Your FrameLayoutKit code */",
    "checkLevel": "full"
  }
}

FrameLayoutKit Syntax Verification

The MCP server correctly implements FrameLayoutKit's syntax patterns:

✅ Operator Usage

  • + operator for adding views to layouts

  • <+ and +> operators for DoubleFrameLayout

  • Chainable method syntax

✅ Layout Properties

  • Correct alignment enums (.top, .center, .bottom, .fill, .fit)

  • Distribution options per layout type

  • Proper padding/spacing application

✅ View Wrapping

  • All views automatically wrapped in FrameLayout instances

  • Individual item configuration support

  • Correct frame calculation delegation

✅ Layout Hierarchies

  • Proper nesting of layout types

  • Correct parent-child relationships

  • Internal stack management for Grid and Flow layouts

Architecture

The server is built with:

  • Node.js with ES modules

  • @modelcontextprotocol/sdk for MCP implementation

  • Zod for schema validation

  • Modular class structure for each tool

Key Components

  1. FrameLayoutGenerator - Generates FrameLayoutKit code

  2. AutoLayoutConverter - Converts Auto Layout to FrameLayoutKit

  3. FrameLayoutValidator - Validates syntax and semantics

  4. MigrationAnalyzer - Analyzes projects for migration

Contributing

Contributions are welcome! Please ensure:

  • Code follows FrameLayoutKit's official syntax

  • All generated code is valid Swift

  • Tests cover new functionality

  • Documentation is updated

License

MIT License - see LICENSE file for details

Support

For issues and questions:

Acknowledgments

  • FrameLayoutKit by Nam Kennic

  • Anthropic's Model Context Protocol

  • The iOS development community

Available Tools

5 tools
convert-autolayoutB

Convert Auto Layout code to FrameLayoutKit syntax

ParametersJSON Schema
NameRequiredDescriptionDefault
swiftCodeYes
optionsNo

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description only says 'convert', which is a generic action. It does not disclose whether the conversion is a pure transformation, if it modifies code in place, or any performance or permission implications. Minimal behavioral context.

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?

The description is a single short sentence, which is highly concise. However, it may be too brief to convey all necessary context. Front-loading is not needed but structure is flat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 parameters, nested object, no output schema), the description lacks completeness. It does not explain input constraints, output format, or edge cases. The agent would have limited understanding of how to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has two parameters (swiftCode and options) but no descriptions within the schema (0% coverage). The tool description adds no meaning beyond the schema, leaving the agent to infer the purpose of parameters like 'options' and its subfields.

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?

Description clearly states 'Convert Auto Layout code to FrameLayoutKit syntax', specifying the action, input, and output format. It distinguishes from siblings like generate-framelayout (generates new code) and validate-framelayout (validation).

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 but not explicit. The description does not mention when to use this tool versus alternatives like generate-framelayout or generate-migration-guide. No contextual guidance on prerequisites or appropriate scenarios.

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

generate-framelayoutC

Generate FrameLayoutKit code for iOS layouts

ParametersJSON Schema
NameRequiredDescriptionDefault
layoutTypeYes
viewsYes
configurationNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only says 'generate code', which is non-destructive, but doesn't clarify idempotency, side effects, or whether it modifies anything.

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?

A single sentence is concise but too brief for a 3-parameter tool with nested objects. It lacks necessary detail without being wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (3 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It fails to explain enum values, view structure, configuration options, or output format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain parameters. It does not mention layoutType, views, or configuration, leaving the agent to infer from the schema alone.

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?

Description clearly states the tool generates FrameLayoutKit code for iOS layouts, distinguishing it from siblings like convert-autolayout or validate-framelayout. However, it lacks specificity about output format (e.g., Swift, XML).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like convert-autolayout or generate-viewcontroller. The description does not mention prerequisites or exclusions.

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

generate-migration-guideC

Generate a migration guide for converting projects to FrameLayoutKit

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathNo
swiftFilesNo
outputFormatNomarkdown

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only says 'Generate a guide', implying a non-destructive operation, but does not specify side effects, authorization needs, or whether it modifies any files. The behavioral traits are vague.

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?

The description is a single sentence, which is concise but lacks structured front-loading of key information. It could benefit from additional context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, error conditions, or how to interpret the generated guide.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero description coverage (no descriptions for parameters). The tool description does not add any meaning to parameters like 'projectPath' (directory or file?), 'swiftFiles' (relative/absolute paths?), or 'outputFormat' (what each format produces?).

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 verb 'Generate' and the resource 'migration guide' with a specific purpose: converting projects to FrameLayoutKit. It distinguishes itself from sibling tools like 'convert-autolayout' which does the actual conversion, and 'generate-framelayout' which generates layouts.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for its usage. The description lacks any conditions or exclusions.

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

generate-viewcontrollerC

Generate complete view controller with FrameLayoutKit layouts

ParametersJSON Schema
NameRequiredDescriptionDefault
classNameNoCustomViewController
layoutStructureYes

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states generation of a view controller but omits details on side effects (e.g., file creation, overwriting), permissions, or output format. This is insufficient.

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?

The description is extremely short and concise, but conciseness comes at the cost of missing critical information. A slightly longer description with more structure would be preferable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the input schema and lack of output schema or annotations, the description is far from complete. It does not describe the generated output, integration with other tools, or any constraints, leaving the agent with insufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no semantic information about the parameters. The complex nested layoutStructure object is not explained, making it difficult for an agent to construct valid inputs.

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?

The description clearly states it generates a complete view controller with FrameLayoutKit layouts, specifying the verb and resource. However, it does not explicitly differentiate from sibling tools like generate-framelayout, which might generate only layouts.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as convert-autolayout or generate-framelayout. Prerequisites or preferred usage contexts are absent.

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

validate-framelayoutB

Validate FrameLayoutKit code for syntax and semantic correctness

ParametersJSON Schema
NameRequiredDescriptionDefault
swiftCodeYes
checkLevelNofull

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, and the description lacks details on side effects, return values, or error handling. The agent is left unaware of what happens upon validation failure or whether the tool is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no superfluous content. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters and no output schema, the description is incomplete. It lacks explanation of validation outcomes, the different check levels, and error behavior, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not mention the 'swiftCode' or 'checkLevel' parameters. The description adds no meaning beyond the schema's names and enum, failing to compensate for the low coverage.

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 explicitly states the tool validates FrameLayoutKit code for syntax and semantic correctness, providing a clear verb and resource. It distinguishes from sibling tools like 'convert-autolayout' or 'generate-framelayout' which handle conversion/generation.

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?

The description implies usage for validation but offers no explicit guidance on when to use or alternatives. However, sibling tools have distinct purposes, so an agent can infer context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv1.0.1
    • Addedconvert-autolayout
    • Addedgenerate-framelayout
    • Addedgenerate-migration-guide
    • Addedgenerate-viewcontroller
    • Addedvalidate-framelayout
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a distinct purpose: conversion, generation, migration guide, view controller generation, and validation. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, e.g., convert-autolayout, generate-framelayout.

Tool Count5/5

5 tools is well-scoped for a focused framework assistance server, covering key developer tasks without excess.

Completeness5/5

The tool set covers the main workflows: converting existing code, generating new layouts, validating, creating view controllers, and providing migration guides. No obvious gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Xcode MCP Server

    ebowwa
    A
    license
    B
    quality
    C
    maintenance
    Provides programmatic access to Xcode functionality, enabling AI assistants to create, build, test, and manage iOS/macOS projects directly.
    33
    7
    5
    MIT

  • MCP Xcode

    Stefan-Nitu
    A
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to build, test, run, and manage Apple platform projects (iOS, macOS, tvOS, watchOS, visionOS) directly through Xcode. Provides comprehensive control over Xcode projects, Swift packages, simulators, and development workflows without leaving your editor.
    5
    41
    1
    MIT

  • Figma to Flutter MCP Server

    mhmzdev
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI coding agents to extract Figma design data and convert it into Flutter widgets and screens. Supports theme setup, component analysis, asset exports, and provides Flutter implementation guidance from Figma designs.
    58
    244
    MIT

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/kennic/framelayoutkit-mcp-server'

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