Which integrations are available for this server?

Allows running Google Lighthouse analysis on specified URLs to measure performance, SEO, accessibility, and best practices. Offers Next.js-specific code review, SEO metadata validation, and bundle optimization analysis for pages and layouts. Provides code quality analysis for React components, including checks for hooks, types, and anti-patterns.

How do I use MCP Frontend Analyzer?

1. Click on "Install 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., "@MCP Frontend Analyzer Check the SEO metadata of my Next.js page" 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.

MCP Frontend Analyzer

by Samet-Berkay-Taskin

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP Frontend Analyzer

Google Lighthouse analizi, kod kalite kontrolü, SEO metadata denetimi, erişilebilirlik analizi ve bundle optimizasyonu sunan kapsamlı bir MCP (Model Context Protocol) server'ı. React ve Next.js projelerinde AI agent'ına frontend uzmanlığı kazandırır.

Mimari

┌──────────────┐     stdio      ┌────────────────────────────────────┐
│  Cursor IDE  │ ◄────────────► │  MCP Server (8 Tool)               │
│  (AI Agent)  │   JSON-RPC     │                                    │
└──────────────┘                │  ┌──────────────────────────────┐  │
                                │  │ lighthouse.ts                │  │
                                │  │ Chrome + Lighthouse analiz   │  │
                                │  └──────────────────────────────┘  │
                                │  ┌──────────────────────────┐      │
                                │  │ recommendations.ts       │      │
                                │  │ SEO/React/Next önerileri │      │
                                │  └──────────────────────────┘      │
                                │  ┌──────────────────────────────┐  │
                                │  │ tools/                       │  │
                                │  │ ├─ check-component-quality   │  │
                                │  │ ├─ check-metadata            │  │
                                │  │ ├─ check-accessibility       │  │
                                │  │ ├─ check-bundle              │  │
                                │  │ └─ compare-lighthouse        │  │
                                │  └──────────────────────────────┘  │
                                └────────────────────────────────────┘

Related MCP server: MCP Quality Hub

Kurulum

# 1. Proje klasörüne git
cd ~/Desktop/MCP-Frontend-Analyzer

# 2. Bağımlılıkları kur
npm install

# 3. TypeScript'i derle
npm run build

MCP Araçları (8 Tool)

1. `lighthouse_analyze`

Belirtilen URL üzerinde Google Lighthouse analizi çalıştırır.

Parametreler:

url (zorunlu): Analiz edilecek URL (https://...)
categories (opsiyonel): ["performance", "seo", "accessibility", "best-practices"]
device (opsiyonel): "mobile" veya "desktop" (varsayılan: mobile)

Örnek kullanım:

"https://example.com sitesinin SEO puanını analiz et"

2. `get_seo_recommendations`

React/Next.js projeleri için SEO, performans ve erişilebilirlik önerileri döner.

Parametreler:

category (opsiyonel): "seo", "performance", "accessibility", "best-practices"

Örnek kullanım:

"Next.js'te SEO için best practice'ler neler?"

3. `nextjs_code_review`

Verilen React/Next.js kodunu SEO ve performans açısından analiz eder.

Parametreler:

code (zorunlu): Analiz edilecek kod
filename (opsiyonel): Dosya adı (bağlamsal analiz için)

Örnek kullanım:

"Bu page.tsx dosyamı SEO açısından incele"

4. `check_component_quality`

Component dosyasının kod kalitesini analiz edip 0-100 arası skor verir.

Kontrol ettikleri:

Page/Layout default export zorunluluğu
Layout children prop zorunluluğu
Satır sayısı limiti (150/250 eşik)
Hook yoğunluğu (SOLID - Single Responsibility)
any tipi kullanımı
console.log tespiti
Relative import tespiti
Import sıralaması
Gereksiz 'use client'
Class component tespiti
Props type/interface eksikliği
Manuel useMemo/useCallback
Inline style kullanımı
İç içe ternary operatör
Boş catch bloğu (silent catch)

Parametreler:

code (zorunlu): Component kodu
filename (opsiyonel): Dosya adı

Örnek kullanım:

"Bu component'in kalitesini kontrol et"

5. `check_metadata`

Next.js page/layout dosyasının SEO metadata eksiksizliğini kontrol eder.

Kontrol ettikleri:

metadata / generateMetadata export
Static/Dynamic sayfa türüne göre doğru metadata yöntemi kontrolü
title, description tanımları
OpenGraph (title, description, images, type, locale, siteName)
Twitter card
Canonical URL
Robots direktifi
HTML lang attribute (layout)
Viewport export (layout)
JSON-LD yapılandırılmış veri

Parametreler:

code (zorunlu): Sayfa/layout kodu
filename (opsiyonel): Dosya adı
pageType (opsiyonel): "static" veya "dynamic"

Örnek kullanım:

"Bu sayfanın metadata'sı eksiksiz mi?"

6. `check_accessibility`

Component'i erişilebilirlik (a11y) açısından WCAG standartlarına göre analiz eder.

Kontrol ettikleri:

Layout'ta lang attribute zorunluluğu (WCAG 3.1.1)
Page'de <h1> zorunluluğu (WCAG 1.3.1)
Layout'ta skip navigation kontrolü (WCAG 2.4.1)
Semantic HTML vs div soup
Heading hiyerarşisi (tek h1, ardışık seviyeler)
Image alt text (eksik, boş, anlamsız)
İkon butonlarda aria-label
<div onClick> anti-pattern (klavye erişilemez)
Link güvenliği (target="_blank" + rel)
Link title attribute
Form input label/aria-label
Nav aria-label (çoklu nav)
autoFocus anti-pattern
Renk kontrast ipuçları

Parametreler:

code (zorunlu): Component kodu
filename (opsiyonel): Dosya adı

Örnek kullanım:

"Bu component erişilebilir mi?"

7. `check_bundle`

Dosyanın JavaScript bundle boyutuna etkisini analiz eder.

Kontrol ettikleri:

Layout'ta 'use client' riski (tüm sayfa ağacı etkilenir)
Page'de ağır client bundle tespiti
Ağır kütüphane import'ları (moment, lodash, axios, MUI, antd, Chart.js)
Barrel export anti-pattern (tree-shaking kırılması)
Dynamic import adayları (Modal, Chart, Editor, Map, PDF vb.)
Gereksiz 'use client' (bundle etkisi)
Büyük client component (import sayısı)
Third-party script stratejisi (<script> vs next/script)
Wildcard re-export (export * from)
package.json bağımlılık analizi

Parametreler:

code (zorunlu): Dosya kodu
filename (opsiyonel): Dosya adı
packageJsonContent (opsiyonel): package.json içeriği

Örnek kullanım:

"Bu dosyanın bundle etkisini analiz et"

8. `compare_lighthouse`

İki URL'yi Lighthouse ile analiz edip karşılaştırma raporu çıkarır.

Parametreler:

url1 (zorunlu): İlk URL (mevcut/production)
url2 (zorunlu): İkinci URL (yeni/staging)
categories (opsiyonel): Karşılaştırılacak kategoriler
device (opsiyonel): "mobile" veya "desktop"

Örnek kullanım:

"Staging ve production'ı karşılaştır"

Cursor Yapılandırması

~/.cursor/mcp.json dosyasında:

{
  "mcpServers": {
    "mcp-frontend-analyzer": {
      "command": "node",
      "args": ["/Users/KULLANICI_ADI/Desktop/MCP-Frontend-Analyzer/dist/index.js"]
    }
  }
}

Dosya Yapısı

MCP-Frontend-Analyzer/
├── src/
│   ├── index.ts                          # MCP Server giriş noktası (tool kayıtları)
│   ├── lighthouse.ts                     # Lighthouse analiz motoru (Chrome + headless)
│   ├── recommendations.ts               # SEO/React/Next.js öneri veritabanı
│   └── tools/
│       ├── code-review.ts              # Next.js kod inceleme (SEO, performans, a11y)
│       ├── check-component-quality.ts   # Kod kalite analizi (SOLID, satır limiti, any, hook)
│       ├── check-metadata.ts            # SEO metadata kontrolü (OG, Twitter, canonical)
│       ├── check-accessibility.ts       # Erişilebilirlik analizi (WCAG referanslı)
│       ├── check-bundle.ts             # Bundle boyut analizi (ağır lib, tree-shake)
│       └── compare-lighthouse.ts       # İki URL Lighthouse karşılaştırması
├── dist/                                # Derlenmiş JS çıktısı
├── package.json
├── tsconfig.json
└── README.md

Nasıl Çalışır?

Cursor IDE, mcp.json'daki yapılandırmaya göre server'ı child process olarak başlatır
İletişim stdio (stdin/stdout) üzerinden JSON-RPC formatında yapılır
AI agent, tanımlanan 8 tool'u çağırabilir
Kod analiz tool'ları (quality, metadata, a11y, bundle) regex ve string analizi ile çalışır — harici bağımlılık gerektirmez
Lighthouse tool'ları Chrome'u headless modda başlatıp web sayfası analizi yapar
Sonuçlar AI agent'a gönderilir, agent kullanıcıya özetler ve öneriler sunar

Öğrenme Kaynakları

Available Tools

8 tools

check_accessibilityA

React/Next.js kodunu erişilebilirlik (a11y) açısından analiz eder. Semantic HTML, heading hiyerarşisi, alt text, ARIA label, keyboard erişimi, form label, renk kontrastı ve daha fazlasını WCAG standartlarına göre denetler.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Analiz edilecek React/Next.js component kodu
`filename`	No	Dosya adı (bağlamsal analiz için)

TDQS

A3.6/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 fully disclose behavioral traits. It only describes the scope of analysis (static code checks) but lacks details on permissions, side effects (e.g., does it modify code?), error handling, or output format. The description is minimal.

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, front-loaded with the verb phrase, and lists key features efficiently. No filler content.

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 2 parameters and no output schema, the description adequately covers the purpose and checks performed. It mentions WCAG standards, which is helpful context. However, it could briefly note that it is a static analysis tool (not a runtime check) to set expectations.

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 baseline is 3. The description reiterates the schema's parameter roles ('Analiz edilecek kod', 'bağlamsal analiz için') without adding deeper semantics, such as code size limits or expected format.

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 analyzes React/Next.js code for accessibility (a11y) and lists specific checks (semantic HTML, heading hierarchy, etc.) per WCAG standards. This distinguishes it from sibling tools like check_bundle or lighthouse_analyze.

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 accessibility analysis but does not explicitly state when to use this tool versus alternatives (e.g., compare_lighthouse for performance). No when-not-to or exclusion criteria are provided.

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

check_bundleA

React/Next.js dosyasının JavaScript bundle boyutuna etkisini analiz eder. Ağır kütüphane import'ları, barrel export anti-pattern, gereksiz 'use client', dynamic import fırsatları ve third-party script stratejilerini kontrol eder.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	Analiz edilecek dosyanın kodu
`filename`	No	Dosya adı
`packageJsonContent`	No	package.json dosyasının içeriği (opsiyonel). Verilirse bağımlılık bazlı analiz de yapılır.

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 must disclose behavioral traits. It indicates an analysis/read-only operation, but does not explicitly state that it does not modify anything or mention any side effects. The lack of detail on permissions or return behavior reduces transparency.

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 filler. The most important information is front-loaded. Efficient and to the point.

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 the tool is an analysis tool and the description lists specific checks, it provides sufficient context for an agent to understand the tool's capability. However, lack of output schema specification means the return format is not described, slightly reducing 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 description coverage is 100%, so baseline is 3. The description adds context about the analysis (bundle size checks) but does not elaborate further on the parameters beyond what the schema already 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?

The description clearly states the tool's purpose: analyzing the impact of a React/Next.js file on JavaScript bundle size. It lists specific aspects checked (heavy imports, barrel exports, etc.), distinguishing it from sibling tools like check_accessibility or check_component_quality.

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?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not provide when/when-not-to-use scenarios or mention sibling tools for comparison.

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

check_component_qualityA

React/Next.js component dosyasının kod kalitesini analiz eder. Satır sayısı, hook yoğunluğu, any kullanımı, console.log, import yapısı, SOLID prensipleri ve daha birçok metriği kontrol edip 0-100 arası skor verir.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Analiz edilecek React/Next.js component kodu
`filename`	No	Dosya adı (ör: hero-carousel/index.tsx). Bağlama göre daha iyi analiz sağlar.

TDQS

A3.7/5.0

Behavior3/5

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

Though the description implies a read-only analysis by saying 'analiz eder', it does not explicitly state behavioral traits like idempotency or side effects, and no annotations are provided to compensate.

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 efficiently convey purpose and metrics list; no redundancy and front-loaded with key information.

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?

The description explains the tool outputs a 0-100 score but does not detail return format, error handling, or prerequisites. With no output schema, more detail would be beneficial for completeness.

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 description coverage is 100% with clear parameter definitions. The description adds value by enumerating the quality metrics checked, which enriches the understanding of what the code and filename parameters are used for.

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 analyzes React/Next.js component code quality and lists specific metrics, distinguishing it from siblings like check_accessibility or check_bundle.

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 or when not to use this tool versus alternatives; it merely describes functionality without contextual recommendations.

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

check_metadataA

Next.js page/layout dosyasının SEO metadata eksiksizliğini kontrol eder. Title, description, OpenGraph, Twitter card, canonical URL, robots direktifi, structured data (JSON-LD) ve viewport tanımlarını denetler.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	Analiz edilecek Next.js page veya layout dosyasının kodu
`filename`	No	Dosya adı (ör: page.tsx, layout.tsx). Kontrolün kapsamını belirler.
`pageType`	No	Sayfa tipi. static: sabit metadata, dynamic: generateMetadata ile üretilen.

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description bears full burden. It clarifies the tool is read-only ('kontrol eder' meaning checks) and specifies what elements are inspected. This is sufficient for a validation tool, though it does not mention side effects or error behavior.

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, front-loaded with the main purpose, and each sentence adds value—first the overall function, then the specific items checked. No wasted words.

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?

The description covers the tool's function and inspected items but omits any mention of output (e.g., return value, report format) even though no output schema exists. For a validation tool, this is a minor gap but leaves room for interpretation.

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 descriptions for all three parameters. The description adds no additional meaning beyond what the schema provides (e.g., it does not explain code, filename, or pageType further). 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 tool checks SEO metadata completeness of Next.js page/layout files and enumerates specific metadata fields (title, OpenGraph, Twitter card, etc.). This verb+resource specification distinguishes it from sibling tools like check_accessibility or get_seo_recommendations.

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 use when verifying SEO metadata, but does not explicitly state when to use this tool versus alternative sibling tools (e.g., get_seo_recommendations). No exclusions or usage context beyond the core purpose.

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

compare_lighthouseA

İki URL'yi Google Lighthouse ile analiz edip karşılaştırma raporu çıkarır. Her iki URL için performans, SEO, erişilebilirlik ve best-practices skorlarını yan yana gösterir. Toplam analiz süresi ~20-60 saniye.

ParametersJSON Schema

Name	Required	Description
`url1`	Yes	İlk URL (genellikle mevcut/production versiyonu)
`url2`	Yes	İkinci URL (genellikle yeni/staging versiyonu)
`categories`	No	Karşılaştırılacak kategoriler. Varsayılan: hepsi.
`device`	No	Analiz cihazı. Varsayılan: mobile.

TDQS

A3.9/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 analysis duration (~20-60 saniye) and that scores are shown side-by-side, but does not mention auth requirements, rate limits, or potential side effects. The time estimate adds value but more depth is needed.

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 with no redundant information. The main purpose is front-loaded, and each sentence adds value.

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?

The description covers the comparison purpose, categories, devices, and time estimate. However, without an output schema, it does not detail the report format or whether scores are numerical or descriptive, leaving some ambiguity for the agent.

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 descriptive parameter names and descriptions. The tool description adds context about typical use (production vs staging) but does not enhance meaning beyond the schema. 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 tool compares two URLs using Google Lighthouse and produces a comparison report. It specifies the verb (analyze and compare), resource (URLs via Lighthouse), and output (comparison report). It distinguishes from siblings like lighthouse_analyze which likely handles single URLs.

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?

The description implies usage for comparing two versions (mevcut vs yeni) but does not explicitly state when not to use it or mention alternatives. While the context is clear, there is no direct guidance on sibling differentiation.

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

get_seo_recommendationsA

React ve Next.js projeleri için SEO, performans, erişilebilirlik önerileri döner. Lighthouse analizi yapmadan genel best practice bilgisi sağlar.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Öneri kategorisi. Boş bırakılırsa tüm kategoriler döner.

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, description should compensate; it states it does not run Lighthouse, which is useful, but does not disclose other behaviors like whether it is a simple query or requires prior setup, or what the response format is.

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 concise with two sentences: the first states the purpose and scope, the second clarifies a key differentiator. No filler.

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 simple tool with one optional parameter, the description covers purpose, scope (React/Next.js), and key differentiator (no Lighthouse). It lacks explicit mention of output structure, but context signals show no output schema, so it's acceptable.

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 fully documents the parameter, but the description adds context (React/Next.js specific, no Lighthouse) that clarifies the tool's scope beyond the enum values.

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 returns SEO, performance, and accessibility recommendations for React and Next.js projects, explicitly noting it does not perform Lighthouse analysis, which distinguishes it from sibling tools like lighthouse_analyze and compare_lighthouse.

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?

The description sets a clear context (general best practices without Lighthouse) and implies use cases (SEO, performance, accessibility), but does not explicitly state when not to use or direct to specific siblings, which is mildly lacking.

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

lighthouse_analyzeA

Belirtilen URL üzerinde Google Lighthouse analizi çalıştırır. Performans, SEO, erişilebilirlik ve best-practices puanlarını döner. Analiz birkaç saniye sürebilir.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Analiz edilecek web sayfasının tam URL'si (https://... ile başlamalı)
`categories`	No	Analiz edilecek kategoriler. Varsayılan: hepsi.
`device`	No	Analiz cihazı. Varsayılan: mobile.

TDQS

A3.5/5.0

Behavior3/5

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

The description mentions that analysis may take a few seconds, which is a useful behavioral hint. However, it does not disclose other traits such as being read-only, error handling for invalid URLs, or whether authentication is required. With no annotations, more details would be beneficial.

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?

Three concise sentences with no redundancy. The verb is front-loaded, and every sentence provides essential information without waste.

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?

The description covers the basic function and duration but lacks details on the return format or structure of scores. Since there is no output schema, the description should ideally specify what the return object looks like. Adequate for a simple tool but could be more complete.

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%, so the schema already describes each parameter. The description does not add additional meaning beyond restating the categories. Baseline of 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 it runs Google Lighthouse analysis on a URL and returns scores for performance, SEO, accessibility, and best-practices. This distinguishes it from sibling tools like check_accessibility and get_seo_recommendations which focus on specific aspects.

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 siblings. For example, it doesn't mention that for detailed accessibility checks or SEO recommendations, other tools like check_accessibility or get_seo_recommendations might be more appropriate.

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

nextjs_code_reviewA

Verilen React/Next.js kodunu SEO, performans ve erişilebilirlik açısından analiz eder. Kodda tespit edilen sorunları ve iyileştirme önerilerini döner.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Analiz edilecek React/Next.js kod parçacığı
`filename`	No	Dosya adı (ör: page.tsx, layout.tsx). Bağlama göre daha iyi öneriler sağlar.

TDQS

A3.5/5.0

Behavior2/5

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

The description indicates it analyzes code and returns results, but lacks details on behavioral traits such as being read-only, required permissions, or potential side effects. With no annotations provided, the description should carry the burden of transparency but falls short.

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 concise with two sentences, front-loading the purpose. No unnecessary words, and it is well-structured for quick understanding.

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?

The description is adequate for a simple analysis tool, but lacks details about the output format and does not fully leverage the context of having many sibling tools. It could benefit from specifying that results are returned in a structured format.

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%, so the parameter descriptions are adequate. The tool description adds context about the analysis dimensions but does not enhance understanding of parameter usage beyond the schema.

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 analyzes React/Next.js code for SEO, performance, and accessibility, and returns issues and suggestions. It distinguishes itself from sibling tools like check_accessibility and get_seo_recommendations by performing a combined review.

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 the tool is for a general code review covering multiple aspects, but it does not explicitly state when to use this tool versus more specific sibling tools. No guidance on prerequisites or 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.

8 tool updatesv1.0.0May 29, 2026
- First observedcheck_accessibility
- First observedcheck_bundle
- First observedcheck_component_quality
- First observedcheck_metadata
- First observedcompare_lighthouse
- First observedget_seo_recommendations
- First observedlighthouse_analyze
- First observednextjs_code_review

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between lighthouse_analyze and compare_lighthouse (both Lighthouse), and between get_seo_recommendations and nextjs_code_review (both give recommendations). Descriptions help differentiate, but slight ambiguity remains.

Naming Consistency4/5

All tools use snake_case and follow a verb_noun pattern. Verbs vary (check, compare, get, lighthouse_analyze, nextjs_code_review) but the structure is consistent and readable.

Tool Count5/5

8 tools is well-scoped for a frontend analyzer. Each tool covers a distinct area (accessibility, bundle, metadata, etc.) without being overwhelming.

Completeness4/5

The set covers major frontend analysis areas: accessibility, performance, code quality, SEO, and Lighthouse. Minor gaps like security or form analysis exist, but core workflows are covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

vercel-mcpOAuth
com.vercel
An MCP server for Vercel
Cloud Platforms Developer Tools CI/CD & DevOps
2
CalmSEOOAuth
com.calmseo
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Marketing Search
2
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
RampifyOAuth
dev.rampify
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
Marketing Web Scraping Developer Tools
23

Related MCP Servers

Lighthouse MCP
Web Scraping App Automation Monitoring
danielsogl
A
license
B
quality
B
maintenance
MCP server that enables AI agents to perform comprehensive web audits using Google Lighthouse with 13+ tools for performance, accessibility, SEO, and security analysis.
Updated 6 days ago (2026-08-31 14:41 UTC)
11
1,186
67
MIT
MCP Quality Hub
Developer Tools Testing & QA Tools
HalbonLabs
-
license
Not graded
quality
Not graded
maintenance
Provides comprehensive code quality tools including linting, security scanning, TypeScript checking, and testing through a single MCP server. Integrates multiple quality analysis tools like Biome, ESLint, and Playwright for streamlined development workflows.
Updated a year ago (2025-08-30 01:34 UTC)
-
seo-gaca-mcp
Marketing Browser Automation Testing & QA Tools
gacabartosz
A
license
Not graded
quality
D
maintenance
A comprehensive MCP server for SEO, performance, GEO, and UX audits with 37 tools covering technical SEO, Lighthouse performance, AI search optimization, content analysis, accessibility, security, and more.
Updated 6 months ago (2026-03-03 11:41 UTC)
1
MIT
react-perf-mcp
Developer Tools Code Analysis AI & Machine Learning
cma0232
A
license
A
quality
D
maintenance
An MCP server that runs parallel AI agents to analyze React components for performance issues, including unnecessary re-renders, memoization errors, bundle size problems, and profiling concerns.
Updated 5 months ago (2026-04-04 07:16 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Samet-Berkay-Taskin/MCP-Frontend-Analyzer'

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

MCP Frontend Analyzer

Mimari

Kurulum

MCP Araçları (8 Tool)

1. lighthouse_analyze

2. get_seo_recommendations

3. nextjs_code_review

4. check_component_quality

5. check_metadata

6. check_accessibility

7. check_bundle

8. compare_lighthouse

Cursor Yapılandırması

Dosya Yapısı

Nasıl Çalışır?

Öğrenme Kaynakları

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `lighthouse_analyze`

2. `get_seo_recommendations`

3. `nextjs_code_review`

4. `check_component_quality`

5. `check_metadata`

6. `check_accessibility`

7. `check_bundle`

8. `compare_lighthouse`