Which integrations are available for this server?

Provides tools for fetching and resolving pull request review comments on GitHub. Allows fetching CI failure logs from GitHub Actions for automated self-healing.

How do I use kiro-frontend-engineer-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kiro-frontend-engineer-mcp run design audit on https://example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

kiro-frontend-engineer-mcp

by Josephjyinn516

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

kiro-frontend-engineer-mcp

A Model Context Protocol (MCP) server implementing a 7-stage agentic frontend workflow:

Design Audit — Web design inspection checklist (accessibility, layout stability, edge cases)
Component Blueprint — AI-driven component generation with full interactive states
Best Practices — React/Next.js guidelines applied before code generation
Browser Validation — Real browser run via kane-cli
E2E Testing — Playwright test execution with pass/fail capture
CI Self-Healing — Auto-fetch GitHub Actions failures and generate fixes
PR Review Loop — Auto-resolve PR review comments

Quick Start — Add to Your Project

Option 1: Kiro (recommended)

Add this to your project's .kiro/settings/mcp.json:

{
  "mcpServers": {
    "frontend-engineer": {
      "command": "node",
      "args": ["<path-to-this-repo>/dist/index.js"]
    }
  }
}

Option 2: npx (after publishing to npm)

{
  "mcpServers": {
    "frontend-engineer": {
      "command": "npx",
      "args": ["-y", "kiro-frontend-engineer-mcp"]
    }
  }
}

Option 3: Clone and build locally

git clone https://github.com/<your-username>/kiro-frontend-engineer-mcp.git
cd kiro-frontend-engineer-mcp
npm install
npm run build

Then point your MCP config to the built output:

{
  "mcpServers": {
    "frontend-engineer": {
      "command": "node",
      "args": ["./kiro-frontend-engineer-mcp/dist/index.js"]
    }
  }
}

Related MCP server: jt-mcp-server

What It Provides

Resources (context the agent reads)

URI	Description
`mcp://research/web-design-guidelines`	WCAG AA checklist, layout stability, responsive breakpoints
`mcp://research/react-best-practices`	Server/Client components, TypeScript patterns, performance

Prompts (agent personas)

Name	Description
`ui-ux-pro-max`	Generates production-ready component blueprints from layout specs

Tools (agent actions)

Name	Description
`run_kane_cli`	Visual browser validation via kane-cli
`execute_playwright_test`	Run Playwright E2E tests
`github_fetch_ci_logs`	Fetch CI failure logs for self-healing
`github_address_review_comments`	Fetch and resolve PR review comments

Orchestration Flow

The agent should chain calls in this order:

Read web-design-guidelines → Call ui-ux-pro-max prompt → Read react-best-practices
→ Generate code → run_kane_cli → execute_playwright_test
→ (if CI fails) github_fetch_ci_logs → fix → push
→ (if PR comments) github_address_review_comments → resolve → push

Prerequisites

Node.js ≥ 18
gh CLI (for CI logs and PR comment tools) — gh auth login
Playwright installed in your project (for E2E tool)
kane-cli (optional, for browser validation tool)

License

MIT

Available Tools

4 tools

execute_playwright_testA

Run local Playwright E2E test suites on generated components. Captures terminal logs, test pass/fail results, and error screenshots.

ParametersJSON Schema

Name	Required	Description	Default
`testPath`	Yes	Path to test file or directory (relative to project root)
`headed`	No	Run in headed mode for debugging (default: false)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses captured outputs (logs, results, screenshots) but omits other behavioral traits like side effects (e.g., file modifications, network requests) or prerequisites. It is not misleading but could be more comprehensive.

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 two sentences long, front-loads the purpose, and includes essential details without any fluff. Every sentence adds value.

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?

For a tool with no output schema, the description covers key outputs (logs, results, screenshots). It could mention error handling or prerequisites (e.g., test framework setup), but overall it provides sufficient context for an agent to understand the tool's function and outputs.

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

Parameters3/5

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

Schema coverage is 100% and parameter descriptions are clear. The tool description does not add additional semantics beyond what the schema already provides, so baseline 3 is appropriate.

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 'run' and the resource 'local Playwright E2E test suites' with scope 'on generated components'. It also lists captured artifacts (logs, results, screenshots). This fully defines the tool's purpose and distinguishes it from sibling tools (GitHub comments, CI logs, CLI).

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 when to use (for running Playwright tests) but provides no explicit when-not-to-use instructions or alternatives. Given sibling tools are unrelated, the implicit usage is adequate but not scored higher due to lack of explicit guidance.

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

github_address_review_commentsC

Fetch open PR review comments from GitHub to feed back into agent context for automated resolution.

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	GitHub repository owner
`repo`	Yes	GitHub repository name
`pullNumber`	Yes	Pull request number

TDQS

C2.9/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 behavioral traits. It only states 'Fetch', which implies a read operation, but gives no details on side effects, authentication, rate limits, pagination, or whether it returns all comments or only specific types. The system's behavior on errors or empty results is also omitted.

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 a single sentence with no extraneous words. It is front-loaded with the action and purpose. While concise, it could include more information without sacrificing brevity, but no waste earns a 4.

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?

The tool has no output schema and the description does not explain the return format, structure, or content of the fetched comments. For a tool that feeds back into agent context, details on what the agent receives (e.g., list of comment objects, text, status) are critical. The description is incomplete in this aspect.

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions (owner, repo, pullNumber). The tool description does not add any extra semantics beyond the schema, such as formatting or constraints. Baseline 3 is appropriate since the schema itself is sufficient.

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 the tool fetches open PR review comments from GitHub for automated resolution. The verb 'Fetch' and resource 'open PR review comments' are specific, and the purpose is evident. Although the name 'address_review_comments' is ambiguous, the description clarifies. Sibling tools are in different domains, so no confusion.

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. The description does not specify prerequisites, conditions, or scenarios where another tool would be more appropriate. For instance, there is no mention of when to use 'github_fetch_ci_logs' or others instead.

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

github_fetch_ci_logsA

Fetch CI build/lint failure logs from GitHub Actions. Used for self-healing: agent reads failures and generates fixes.

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	GitHub repository owner
`repo`	Yes	GitHub repository name
`runId`	Yes	GitHub Actions workflow run ID

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description must disclose behaviors. It implies a read-only fetch but omits details like permissions, rate limits, or handling of missing logs.

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?

Two sentences, no unnecessary words. Front-loaded with action, then states purpose. Highly concise.

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?

Given three required parameters and no output schema, the description adequately covers purpose and usage. Could mention return format (e.g., raw logs) or limitations for full completeness.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already describes all three parameters. The description adds no additional meaning beyond 'owner', 'repo', and 'runId'.

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 verb 'Fetch' and resource 'CI build/lint failure logs from GitHub Actions' are specific. The self-healing use case distinguishes it from unrelated siblings.

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?

It explicitly states the use case 'Used for self-healing: agent reads failures and generates fixes', providing clear context but no when-not-to-use or alternatives.

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

run_kane_cliB

Orchestrate a real browser run via kane-cli. Accepts a target URL and optional interaction sequences (click, type, scroll) to visually validate rendered components.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Target URL to open in headless browser
`interactions`	No	Ordered list of browser interactions to perform

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description provides some behavioral context: 'real browser run' and 'visually validate rendered components'. However, it omits side effects, required permissions, or error scenarios, leaving gaps despite lacking annotation support.

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?

A single, well-structured sentence immediately conveys the tool's purpose and key inputs. No unnecessary words or repetition.

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

Completeness3/5

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

For a tool with two well-documented parameters and no output schema, the description adequately explains what the tool does. However, it lacks information about return values or result format, which is expected given the absence of an output schema.

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

Parameters3/5

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

Schema description coverage is 100% for both parameters. The description mentions 'optional interaction sequences (click, type, scroll)' which aligns with the schema but adds no extra meaning beyond the schema's own descriptions.

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 orchestrates a real browser run via kane-cli, accepts URL and optional interactions for visual validation. This distinguishes from siblings like github tools but not from execute_playwright_test, which is a similar browser testing tool.

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 explicit guidance on when to use this tool versus alternatives such as 'execute_playwright_test'. The description lacks context for selection criteria or prerequisites.

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.

4 tool updatesv1.0.0Jun 24, 2026
- First observedexecute_playwright_test
- First observedgithub_address_review_comments
- First observedgithub_fetch_ci_logs
- First observedrun_kane_cli

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-06-24 09:15 across 4 tools

Disambiguation5/5

Each tool serves a distinct purpose: local testing, PR review comments, CI logs, and visual browser validation. There is no overlap, so an agent can easily distinguish them.

Naming Consistency3/5

Three tools follow a verb_noun pattern (execute_, github_fetch_, run_), but 'github_address_review_comments' breaks the pattern—it reads as a noun phrase with 'address' as a verb ambiguous. This inconsistency reduces predictability.

Tool Count5/5

With 4 tools, the server is tightly scoped to core frontend engineering feedback loops: local tests, review comments, CI logs, and visual validation. No tool feels redundant or missing.

Completeness4/5

The set covers the primary stages of a frontend CI/CD workflow (test, review, CI, visual). A minor gap is the absence of a tool to directly apply generated fixes, but the agent can use existing tools iteratively.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2
UI Verify A
io.github.igrlk
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
Testing & QA Tools CI/CD & DevOps
9118
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

VibeServe
Coding Agents Developer Tools AI & Machine Learning
ncsound919
A
license
C
quality
A
maintenance
A production-grade MCP server that turns natural language intent into fully-architected, accessible, production-ready UI code through a 7-step agentic pipeline.
Updated a month ago (2026-08-10 16:15 UTC)
20
1
Apache 2.0
jt-mcp-server
Developer Tools Project Management Knowledge & Memory
HoukasaurusRex
A
license
Not graded
quality
C
maintenance
MCP server that equips AI agents with dev workflow tools including GitHub project management, conventional commits, visual regression testing, Jira/Confluence integration, and a persistent memory knowledge graph.
Updated 4 months ago (2026-05-13 18:32 UTC)
5 npm
MIT
PixelCheck
Browser Automation Web Scraping Testing & QA Tools
xcodethink
A
license
Not graded
quality
C
maintenance
An MCP server that gives AI agents real browser capabilities including screenshotting, action execution, data extraction, and multi-persona auditing for frontend validation.
Updated a day ago (2026-09-14 01:07 UTC)
23 npm
6
MIT
MCP SDD Server
Developer Tools Software Architecture Code Analysis
yi-john-huang
A
license
C
quality
A
maintenance
An MCP server implementing Spec-Driven Development workflows for AI-agent CLIs and IDEs like Claude Code and Cursor, enabling spec-first development with automated workflow guidance and quality checks.
Updated 2 months ago (2026-07-25 06:01 UTC)
16
12 npm
52
MIT