Which integrations are available for this server?

Provides modernization analysis to identify opportunities to replace Axios with native fetch API in simple use cases, potentially reducing bundle size by ~15KB. Recommends date-fns as a modern alternative to Moment.js during code modernization analysis, helping reduce bundle size by ~65KB. Analyzes jQuery usage in projects and provides migration recommendations to native DOM APIs, with potential bundle size reduction of ~85KB and side-by-side code examples. Detects Lodash functions that can be replaced with native JavaScript methods, offering modernization suggestions with ~50KB bundle size reduction potential. Enables real-time search and retrieval of MDN Web Docs documentation, including API syntax, browser compatibility, deprecation status, and experimental features across multiple languages (en-US, zh-TW, zh-CN). Suggests the Temporal API as a modern replacement for date parsing and manipulation operations currently using legacy Date methods or Moment.js.

How do I use Dev Advisor MCP Server?

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., "@Dev Advisor MCP Server check if fetch API is widely supported in modern browsers" 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.

Dev Advisor MCP Server

by mukiwu

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

開發決策顧問 MCP Server

智慧開發決策顧問工具，提供程式碼現代化分析、瀏覽器相容性檢查、MDN 文件查詢、Baseline 狀態查詢等功能。透過 MCP (Model Context Protocol) 與 AI 工具深度整合。

✨ 新功能：整合 Baseline 狀態查詢 - 基於 web.dev/baseline 判斷 Web API 是否可在所有核心瀏覽器中安全使用。

✨ 功能特色

🔄 程式碼現代化分析器

掃描 JavaScript/TypeScript 專案，找出可被原生 API 替代的函式庫
檢測過時的程式碼模式（var、callback、IIFE、傳統 for 迴圈）
提供重構建議和預估效能提升
生成對比程式碼範例
支援 ES Module 和 CommonJS

🔍 MDN 文件即時查詢

搜尋 MDN Web Docs 取得最新 API 資訊
顯示 API 棄用狀態和實驗性標記
取得語法說明和瀏覽器相容性
支援多語言（en-US, zh-TW, zh-CN）

🌐 Can I Use 瀏覽器相容性檢查

即時查詢 Web API 的瀏覽器支援狀態
顯示各瀏覽器的支援版本
提供 Polyfill 建議和 CDN 連結
支援自訂目標瀏覽器版本

📊 Baseline 狀態查詢（新增）

整合 web.dev/baseline 資料
查詢 Web API 的 Baseline 狀態（Limited/Newly/Widely available）
判斷功能是否可在所有核心瀏覽器中安全使用
提供基於 Baseline 的使用建議
自動整合到相容性檢查和 API 推薦功能中

📚 豐富的規則資料庫

18 個函式庫規則：jQuery、Moment.js、Lodash、Axios、Bluebird 等
16 個 API 規則：XMLHttpRequest、eval、document.write、var 等
可透過設定檔自訂規則

Related MCP server: Ultra Debugger

🚀 安裝

從 npm 安裝

npm install -g @muki/dev-advisor-mcp

從原始碼安裝

git clone https://github.com/mukiwu/dev-advisor-mcp.git
cd dev-advisor-mcp
npm install
npm run build

🔧 GitHub Actions 整合

快速開始

在您的專案中創建 .github/workflows/dev-advisor.yml：

規則式分析（預設）

name: Dev Advisor Check

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    
    steps:
      - uses: actions/checkout@v4
      
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      - uses: mukiwu/dev-advisor-mcp@v1
        with:
          project-path: '.'
          enable-modernization: true
          enable-compatibility: true
          comment-on-pr: true

AI 分析模式（推薦）

使用 AI 分析 PR 變更的程式碼，提供更智慧的現代化建議：

name: Dev Advisor AI Check

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    
    steps:
      - uses: actions/checkout@v4
      
      - uses: mukiwu/dev-advisor-mcp@v1
        with:
          ai-enabled: true
          ai-provider: 'openai'  # 或 anthropic、gemini
          ai-api-key: ${{ secrets.OPENAI_API_KEY }}
          comment-on-pr: true

輸入參數

參數	說明	預設值	必填
`project-path`	專案目錄路徑	`.`	❌
`include-patterns`	包含的檔案模式（JSON 陣列）	`["*/.js", "*/.ts", "*/.jsx", "*/.tsx"]`	❌
`exclude-patterns`	排除的檔案模式（JSON 陣列）	`["node_modules/", "dist/", "build/**"]`	❌
`browserslist-config`	browserslist 配置字串	`""`	❌
`enable-modernization`	啟用現代化分析	`true`	❌
`enable-compatibility`	啟用相容性分析	`true`	❌
`enable-browser-check`	啟用瀏覽器支援檢查	`true`	❌
`github-token`	GitHub Token	`${{ github.token }}`	❌
`comment-on-pr`	是否在 PR 中留言	`true`	❌
`ai-enabled`	啟用 AI 分析模式	`false`	❌
`ai-provider`	AI 提供者：`openai`、`anthropic`、`gemini`	`openai`	❌
`ai-model`	AI 模型名稱（留空使用預設）	`""`	❌
`ai-api-key`	AI API 金鑰（建議使用 Secrets）	-	AI 模式必填

進階使用

- uses: mukiwu/dev-advisor-mcp@v1
  with:
    project-path: './src'
    include-patterns: '["src/**/*.js", "src/**/*.ts"]'
    exclude-patterns: '["**/*.test.ts", "**/*.spec.ts"]'
    browserslist-config: 'last 2 versions, > 1%, not dead'
    enable-modernization: true
    enable-compatibility: true
    enable-browser-check: false
    comment-on-pr: true

🤖 AI 分析模式

使用 AI 分析 PR 變更的程式碼，提供更智慧的現代化建議：

- uses: mukiwu/dev-advisor-mcp@v1
  with:
    ai-enabled: true
    ai-provider: 'openai'  # 或 anthropic、gemini
    ai-model: 'gpt-4o'     # 可選，留空使用預設模型
    ai-api-key: ${{ secrets.OPENAI_API_KEY }}
    comment-on-pr: true

支援的 AI 提供者：

提供者	預設模型	API Key 設定
`openai`	`gpt-4o`	`OPENAI_API_KEY`
`anthropic`	`claude-sonnet-4-20250514`	`ANTHROPIC_API_KEY`
`gemini`	`gemini-2.0-flash`	`GOOGLE_API_KEY`

注意：AI 分析模式會直接分析 PR 的 diff 內容，而非整個專案。建議將 API Key 存放在 GitHub Secrets 中。

輸出

Action 會產生以下輸出：

modernization-report: 現代化分析報告（Markdown）
compatibility-report: 相容性分析報告（Markdown）
summary: 分析摘要（JSON）

完整範例

查看 examples/pr-check.yml 取得完整範例。

⚙️ MCP 配置

方式一：使用 npm 全局安裝（推薦）

首先全局安裝：

npm install -g @mukiwu/dev-advisor-mcp

然後在 Claude Desktop 或 Cursor IDE 中配置：

Claude Desktop 配置 (~/.claude/config.json)：

{
  "mcpServers": {
    "dev-advisor": {
      "command": "dev-advisor"
    }
  }
}

Cursor IDE 配置：

{
  "mcpServers": {
    "dev-advisor": {
      "command": "dev-advisor"
    }
  }
}

方式二：使用 npx（無需全局安裝）

Claude Desktop 配置 (~/.claude/config.json)：

{
  "mcpServers": {
    "dev-advisor": {
      "command": "npx",
      "args": ["-y", "@mukiwu/dev-advisor-mcp"]
    }
  }
}

Cursor IDE 配置：

{
  "mcpServers": {
    "dev-advisor": {
      "command": "npx",
      "args": ["-y", "@mukiwu/dev-advisor-mcp"]
    }
  }
}

注意：現在已經修復了 npx 的路徑問題，應該可以正常使用了。如果仍有問題，建議使用方式一（全局安裝）。

方式三：使用本地安裝路徑

如果從原始碼安裝或使用本地路徑：

{
  "mcpServers": {
    "dev-advisor": {
      "command": "node",
      "args": ["/path/to/dev-advisor-mcp/dist/src/server.js"]
    }
  }
}

🛠️ 可用工具 (Tools)

1. `analyze_modernization`

分析專案程式碼的現代化機會。

參數：

參數	類型	必填	說明
`projectPath`	string	✅	專案目錄路徑
`includePatterns`	string[]	❌	掃描檔案模式，預設 `["*/.js", "*/.ts", "*/.jsx", "*/.tsx"]`
`excludePatterns`	string[]	❌	排除檔案模式，預設 `["node_modules/", "dist/"]`
`reportFormat`	string	❌	報告格式：`markdown`、`json`、`html`、`text`

使用範例：

分析 ./src 目錄的程式碼，找出可以用原生 Web API 替代的函式庫

輸出內容：

執行摘要（檔案數、建議數、效能提升預估）
API 類別分析：自動從 Can I Use 資料庫取得所有類別，分析專案中使用的現代 API 所屬類別
風險評估（破壞性變更、預估工時）
函式庫替換建議（jQuery → 原生 DOM API）
API 現代化建議（XMLHttpRequest → fetch）
語法現代化建議（var → let/const）
模式現代化建議（callback → Promise/async-await）

分析流程：

🔍 自動從 Can I Use 資料庫取得所有可用的 API 類別
📋 分析專案中建議使用的現代 API
🎯 為每個現代 API 找出對應的類別
📊 統計並顯示專案使用的 API 類別分布
✅ 生成完整的現代化分析報告

2. `search_mdn`

搜尋 MDN Web Docs 文件，取得最新的 API 資訊。

參數：

參數	類型	必填	說明
`query`	string	✅	搜尋關鍵字，如 `"fetch"`、`"Array.prototype.includes"`
`limit`	number	❌	返回結果數量，預設 `5`
`locale`	string	❌	語言：`en-US`、`zh-TW`、`zh-CN`，預設 `en-US`

使用範例：

查詢 Promise.allSettled 的 MDN 文件
幫我找 IntersectionObserver 的用法

輸出內容：

搜尋結果列表
API 詳細說明和語法
棄用/實驗性狀態標記
瀏覽器相容性資訊
MDN 文件連結

3. `check_compatibility`

檢查 Web API 的瀏覽器相容性，整合 Can I Use 支援資料和 Baseline 狀態。

參數：

參數	類型	必填	說明
`feature`	string	✅	Web API 功能名稱，如 `"fetch"`、`"css-grid"`、`"IntersectionObserver"`
`targetBrowsers`	object	❌	目標瀏覽器版本，預設 `{ chrome: "90", firefox: "88", safari: "14", edge: "90" }`

使用範例：

檢查 CSS Grid 的瀏覽器相容性
fetch API 是否可安全使用？
IntersectionObserver 是否已達到 Baseline？

輸出內容：

功能概覽和全球支援率
目標瀏覽器相容性報告
各瀏覽器支援版本詳情
Baseline 狀態（Limited/Newly/Widely available）
Polyfill 建議和 CDN 連結
Can I Use 和 MDN 連結

Baseline 狀態說明：

Limited availability ⚠️：尚未在所有核心瀏覽器中支援，建議謹慎使用
Newly available ✅：所有核心瀏覽器都支援，可安全使用
Widely available 🟢：已廣泛支援至少 30 個月，非常穩定可靠

4. `recommend_api_combination`

根據自然語言描述的需求，推薦最佳的 Web API 技術組合。

參數：

參數	類型	必填	說明
`requirement`	string	✅	功能需求描述，如 `"背景擷取影片畫面並分析"`
`targetBrowsers`	string[]	❌	目標瀏覽器，如 `["chrome>=90", "firefox>=88"]`，預設現代瀏覽器
`performanceRequirements`	string	❌	效能需求：`low`、`medium`、`high`，預設 `medium`

使用範例：

我想實作懶加載圖片功能，推薦用什麼 API？
幫我找適合做即時通訊的 Web API

輸出內容：

推薦 API 列表（按類別分組）
每個 API 的說明和程式碼範例
Baseline 狀態（Limited/Newly/Widely available）
瀏覽器相容性報告
可取代的第三方函式庫
Polyfill 建議
實作建議（可直接使用 / 需要 Polyfill / 需要替代方案）
類別分析資訊：顯示從 Can I Use 資料庫匹配的相關類別

推薦流程：

🔍 自動從 Can I Use 資料庫取得所有可用的 API 類別
🎯 根據需求描述匹配相關的類別
📋 從匹配類別中找出相關的 API
🔗 結合預定義知識庫的推薦結果
✅ 查詢瀏覽器相容性並生成最終推薦

支援的 API 類別（預定義知識庫 + Can I Use 動態類別）：

HTTP 請求：Fetch API、AbortController
DOM 操作：querySelector、classList、MutationObserver
觀察者：IntersectionObserver、ResizeObserver
儲存：localStorage、sessionStorage、IndexedDB
媒體：getUserMedia、MediaRecorder、Web Audio API
圖形：Canvas API、WebGL
非同步：Promise、async/await、Web Workers
通訊：WebSocket、Server-Sent Events、BroadcastChannel
動畫：requestAnimationFrame、Web Animations API
其他：Clipboard API、Geolocation、Notification API

注意: recommend_api_combination 工具現在會自動使用 list_api_categories 取得完整的類別列表，然後根據需求匹配相關類別，提供更準確和完整的推薦結果。您也可以單獨使用 list_api_categories 工具查看所有可用的 API 類別。

5. `list_api_categories`

列出所有可用的 Web API 類別，從 Can I Use 資料庫中取得完整的類別列表。

參數： 無參數

使用範例：

列出所有可用的 Web API 類別
取得完整的 API 類別清單

輸出內容：

所有可用的 Web API 類別列表
每個類別的功能數量
類別說明
使用建議

說明： 此工具從 Can I Use 資料庫動態提取所有類別，提供比 recommend_api_combination 更完整的類別資訊。這些類別反映了 Can I Use 資料庫中的實際分類，可用於了解 Web API 的完整生態系統。

6. `analyze_compatibility`

分析專案中使用的 API 與目標瀏覽器的相容性，自動偵測 browserslist 配置。

參數：

參數	類型	必填	說明
`projectPath`	string	✅	專案目錄路徑
`browserslistConfig`	string	❌	browserslist 查詢字串，如 `"last 2 versions"`，預設讀取專案配置
`reportFormat`	string	❌	報告格式：`markdown`、`json`、`html`，預設 `markdown`

使用範例：

分析這個專案的瀏覽器相容性風險
檢查專案是否支援 IE11
幫我找出需要 polyfill 的 API

輸出內容：

執行摘要（API 數量、相容性百分比）
目標瀏覽器列表（從 browserslist 自動偵測）
相容性問題（按嚴重程度分類）
- 🔴 嚴重：多數瀏覽器不支援
- 🟠 高風險：部分瀏覽器不支援
- 🟡 中風險：需要 polyfill
- 🟢 低風險：少量瀏覽器需要 polyfill
Polyfill 建議（CDN 連結、npm 套件）
統一 Polyfill 方案（polyfill.io 整合）

支援的 Browserslist 配置：

自動讀取 package.json 的 browserslist 欄位
自動讀取 .browserslistrc 檔案
或直接傳入查詢字串，如 "> 1%, last 2 versions, not dead"

📦 可用資源 (Resources)

MCP Resources 讓 AI 可以直接讀取規則資料：

URI	說明
`devadvisor://rules/libraries`	所有函式庫現代化規則
`devadvisor://rules/apis`	所有 API 現代化規則
`devadvisor://rules/all`	完整規則資料庫
`devadvisor://stats`	規則統計資訊

💡 可用提示模板 (Prompts)

預定義的分析提示模板：

名稱	說明	參數
`analyze-project`	分析專案的程式碼現代化機會	`projectPath`（必填）、`focus`（選填：bundle-size/performance/security/all）
`migrate-library`	取得特定函式庫的遷移指南	`library`（必填：如 jquery, moment, lodash）
`modernize-pattern`	取得程式碼模式的現代化建議	`pattern`（必填：如 callback, var, for-loop, iife）
`quick-wins`	取得低風險、高效益的快速改善建議	`projectPath`（必填）
`analyze-pr`	分析 Git PR 的程式碼變更，整合規則式分析和 AI 分析	`projectPath`（必填）、`prDiff`（選填）、`changedFiles`（選填：JSON 陣列）

`analyze-pr` 模板詳細說明

這個模板整合了規則式分析和 AI 分析，專門用於分析 Git PR 的程式碼變更。

功能特色：

✅ 只分析 PR 變更的檔案：不會掃描整個專案，專注於 PR 中的變更
✅ 整合規則式分析：使用 analyze_modernization 工具進行規則式檢查
✅ 整合完整 Web API 列表：使用 list_api_categories 取得所有可用的 Web API
✅ AI 評估：結合 PR diff 內容進行智慧評估
✅ 綜合報告：提供包含現代化建議、API 優化、相容性檢查的完整報告

參數說明：

projectPath（必填）：專案目錄路徑
prDiff（選填）：PR 的 diff 內容。如果提供，AI 會直接分析 diff 內容
changedFiles（選填）：PR 變更的檔案列表，JSON 陣列格式，例如：["src/file1.js", "src/file2.ts"]。如果提供，analyze_modernization 工具只會分析這些檔案

使用範例：

請使用 analyze-pr 提示模板分析我的 PR

或者提供具體參數：

請使用 analyze-pr 提示模板，projectPath 設為 "."，changedFiles 設為 ["src/components/Button.tsx", "src/utils/helpers.ts"]

分析流程：

取得完整的 Web API 類別列表（list_api_categories）
對 PR 變更的檔案進行規則式分析（analyze_modernization）
結合 PR diff 內容進行 AI 評估
提供整合的分析報告，包含現代化建議、API 優化建議、相容性檢查等

📋 支援的現代化規則

函式庫替換 (18 個規則)

函式庫	現代替代方案	Bundle 減少
jQuery	原生 DOM API	~85KB
Moment.js	Date-fns / Dayjs / Temporal	~65KB
Lodash	原生 JavaScript 方法	~50KB
Axios	原生 fetch (簡單場景)	~15KB
Bluebird	原生 Promise	~45KB
Async.js	async/await	~20KB
uuid	crypto.randomUUID()	~8KB
node-fetch	原生 fetch (Node.js 18+)	~15KB
querystring	URLSearchParams	~5KB
object-assign	Object.assign / 展開運算子	~2KB
array-flatten	Array.prototype.flat()	~2KB
is-number	typeof + Number.isFinite()	~1KB
is-array	Array.isArray()	~1KB
left-pad	String.prototype.padStart()	~1KB

API 現代化 (16 個規則)

舊 API	現代替代方案	類型
XMLHttpRequest	fetch API	網路請求
document.write	DOM API	DOM 操作
eval	Function / JSON.parse	安全性
with	解構賦值	語法
var	let / const	變數宣告
arguments	Rest parameters	函式參數
innerHTML	textContent / DOM API	安全性
attachEvent	addEventListener	事件處理
substr	substring / slice	字串處理
for 迴圈	map / filter / forEach	迭代
for...in (陣列)	for...of / 陣列方法	迭代
new Array()	陣列字面量 []	建構
new Object()	物件字面量 {}	建構
Date 字串解析	明確日期格式 / Temporal	日期處理

🔧 設定檔

在專案根目錄建立 .devadvisorrc.json：

{
  "extends": "recommended",
  "include": ["src/**/*.{js,ts,jsx,tsx}"],
  "exclude": ["node_modules/**", "dist/**", "**/*.test.ts"],
  "rules": {
    "builtin": {
      "jquery": { "enabled": true, "severity": "high" },
      "var": { "enabled": true, "severity": "low" }
    },
    "customLibraries": {
      "my-old-lib": {
        "name": "my-old-lib",
        "modernAlternative": "my-new-lib",
        "reason": "內部函式庫升級"
      }
    }
  },
  "report": {
    "format": "markdown",
    "maxSuggestionsPerFile": 10
  },
  "performance": {
    "useCache": true,
    "parallel": true
  }
}

🧪 開發

# 安裝依賴
npm install

# 開發模式
npm run dev

# 建置
npm run build

# 執行測試
npm test

# 測試分析功能
node test-analysis.js

📁 專案結構

dev-advisor-mcp/
├── src/
│   ├── server.ts              # MCP Server 主程式
│   ├── analyzers/
│   │   ├── modernization.ts   # 程式碼現代化分析器
│   │   └── compatibility.ts   # API 相容性分析器
│   ├── parsers/
│   │   └── index.ts           # AST 解析器 (ES Module + CommonJS)
│   ├── services/
│   │   ├── mdn-service.ts     # MDN API 服務
│   │   └── caniuse-service.ts # Can I Use API 服務
│   ├── data/
│   │   ├── modernization-rules.ts   # 現代化規則資料庫
│   │   └── api-recommendations.ts   # API 推薦知識庫
│   ├── config/
│   │   └── index.ts           # 設定檔載入
│   ├── utils/
│   │   ├── report-formatter.ts # 報告格式化器
│   │   ├── cache.ts           # 快取機制
│   │   └── ast-utils.ts       # AST 工具函式
│   └── __tests__/             # 單元測試
├── test-code/                 # 測試用程式碼
├── cli/                       # CLI 工具 (規劃中)
└── web/                       # Web 介面 (規劃中)

🎯 使用情境

情境 1：分析舊專案的現代化機會

請分析 ./legacy-project 專案，找出可以用現代 Web API 替代的函式庫，
幫我減少 bundle 大小

情境 2：查詢某個 API 是否安全使用

document.write 還能用嗎？有什麼替代方案？

情境 3：檢查新 API 的瀏覽器支援

我想用 IntersectionObserver，但需要支援 Safari 13，可以嗎？
需要 polyfill 嗎？

情境 4：遷移特定函式庫

我想把專案中的 Moment.js 換掉，有什麼建議？

情境 5：分析專案相容性

幫我分析這個專案的瀏覽器相容性，我們需要支援 Chrome 80+、Firefox 78+、Safari 13+

情境 6：尋找適合的 Web API

我需要實作：使用者在背景時仍能接收通知，有什麼原生 API 可以用？

📊 輸出範例

Markdown 報告範例

# 程式碼現代化分析報告

## 📊 執行摘要
- **掃描檔案數量**: 42 個檔案
- **發現建議數量**: 15 項
- **潛在效能提升**: 25%
- **檔案大小減少**: 150KB

## ⚠️ 風險評估
- **整體風險等級**: 🟡 MEDIUM
- **預估工時**: 16 小時

## 🚀 主要現代化建議

### 📚 函式庫替換
#### 升級 moment 到 Date-fns/Dayjs
Moment.js 體積過大且不支援 tree-shaking...

🔮 未來規劃

~~智慧 API 組合查詢引擎~~ ✅ 已完成 (recommend_api_combination)
~~基於 browserslist 的深度相容性分析~~ ✅ 已完成 (analyze_compatibility)
~~GitHub Actions 整合~~ ✅ 已完成
CLI 獨立工具
Web 視覺化介面
自動重構程式碼轉換
VS Code / Cursor 擴充套件
更多 API 規則覆蓋
自訂規則設定介面

📄 License

MIT

🤝 貢獻

歡迎提交 Issue 和 Pull Request！

開發決策顧問 - 讓程式碼現代化變得更智慧、更安全！ 🚀

Available Tools

6 tools

analyze_compatibilityC

分析專案的 API 相容性風險，推薦 polyfill 方案

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	專案目錄路徑
`browserslistConfig`	No	browserslist 配置字串或檔案路徑
`reportFormat`	No	報告格式	markdown

TDQS

C2.9/5.0

Behavior2/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 mentions analysis and recommendations but doesn't describe what the tool actually does (e.g., scans code, generates reports, requires internet access) or any behavioral traits like performance impact, error handling, or output format details. This leaves significant gaps in understanding the tool's operation.

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 extremely concise—a single sentence in Chinese that directly states the tool's function without any fluff. It's front-loaded and wastes no words, making it efficient for quick understanding.

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's complexity (analyzing API compatibility with 3 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain what the analysis entails, what the recommendations include, or how results are returned, leaving the agent with incomplete information for effective use.

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?

The input schema has 100% description coverage, clearly documenting all three parameters. The description adds no additional semantic context beyond what's in the schema, such as explaining how 'projectPath' is used or what 'browserslistConfig' entails. Baseline 3 is appropriate since the schema does the heavy lifting.

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's purpose: analyzing API compatibility risks and recommending polyfill solutions for a project. It specifies the verb 'analyze' and the resource 'API compatibility risks,' but doesn't explicitly differentiate from sibling tools like 'analyze_modernization' or 'check_browser_support,' which might have overlapping functionality.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons with sibling tools such as 'check_browser_support' or 'recommend_api_combination,' leaving the agent to infer usage context.

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

analyze_modernizationA

分析 JavaScript/TypeScript 程式碼現代化機會，找出可被瀏覽器原生 Web API 替代的第三方函式庫，減少 npm bundle 大小，包括 jQuery、Moment.js、Lodash、XMLHttpRequest 等過時模式的現代化建議

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	專案目錄路徑
`includePatterns`	No	要掃描的檔案模式，支援 glob 語法，如 ["src/*/.js", "src/*/.ts"] 掃描 src 目錄下的 JavaScript/TypeScript 檔案
`excludePatterns`	No	要排除的檔案模式 (預設: ["node_modules/", "dist/", "build/**"])
`reportFormat`	No	報告格式	markdown

TDQS

A3.6/5.0

Behavior2/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. While it describes the analysis function and modernization focus, it lacks critical behavioral information: whether this is a read-only analysis or makes changes, what permissions are needed, whether it generates output files, performance characteristics, or error handling. For a tool with 4 parameters and no annotations, this is a significant gap.

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, well-structured sentence that efficiently communicates the tool's purpose, scope, and benefits. Every element earns its place: the analysis action, target code types, modernization focus, specific library examples, and bundle size reduction benefit. No wasted words or redundancy.

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's complexity (analyzing code for modernization opportunities), lack of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the analysis output looks like, whether it's a report file or console output, what specific modernization suggestions are provided, or how the tool handles different code patterns. For a code analysis tool with behavioral implications, more context is needed.

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 documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions analyzing JavaScript/TypeScript code which aligns with the parameters, but provides no additional syntax, format, or usage details. Baseline 3 is appropriate when schema does the heavy lifting.

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 with specific verbs ('分析', '找出', '減少') and resources ('JavaScript/TypeScript 程式碼', '第三方函式庫', 'npm bundle'). It explicitly distinguishes from siblings by focusing on modernization opportunities rather than compatibility checking, browser support analysis, or API recommendations mentioned in sibling tools.

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 provides clear context about when to use this tool: for analyzing JavaScript/TypeScript code to find modernization opportunities, specifically replacing third-party libraries with native Web APIs. However, it doesn't explicitly state when NOT to use it or mention alternatives among the sibling tools (like analyze_compatibility or check_browser_support), which would be needed for a perfect score.

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

check_browser_supportC

使用 Can I Use 資料庫檢查 Web API 的瀏覽器相容性，取得支援版本和 polyfill 建議

ParametersJSON Schema

Name	Required	Description	Default
`feature`	Yes	Web API 功能名稱，如 "fetch", "flexbox", "css-grid", "webgl"
`targetBrowsers`	No	目標瀏覽器版本 (預設: { chrome: "90", firefox: "88", safari: "14", edge: "90" })

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 carries the full burden of behavioral disclosure. It mentions checking compatibility and getting support versions and polyfill recommendations, but lacks details on response format, error handling, rate limits, authentication needs, or whether it's a read-only operation. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence in Chinese that front-loads the core purpose and key outputs. Every word earns its place: it specifies the data source (Can I Use database), action (check compatibility), target (Web API), and outputs (support versions and polyfill recommendations). There is no wasted verbiage or redundancy.

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's complexity (checking browser compatibility with polyfill recommendations), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., structured data on browser support percentages, polyfill links), error conditions, or limitations. For a tool with no structured behavioral data, more descriptive context is needed to be fully helpful.

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 documents both parameters ('feature' and 'targetBrowsers') with descriptions and defaults. The description adds no additional parameter semantics beyond implying the tool uses the Can I Use database, which is context but not parameter-specific. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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's purpose: '使用 Can I Use 資料庫檢查 Web API 的瀏覽器相容性，取得支援版本和 polyfill 建議' (Use Can I Use database to check Web API browser compatibility, get support versions and polyfill recommendations). It specifies the verb ('檢查' - check), resource ('Web API 的瀏覽器相容性' - Web API browser compatibility), and data source ('Can I Use 資料庫'). However, it doesn't explicitly differentiate from sibling tools like 'analyze_compatibility' or 'analyze_modernization', which likely have overlapping functionality.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'analyze_compatibility' or 'search_mdn', nor does it specify prerequisites, exclusions, or typical use cases. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.

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

list_api_categoriesB

列出所有可用的 Web API 類別，從 Can I Use 資料庫中取得完整的類別列表

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('列出' - list) and data source ('Can I Use 資料庫' - Can I Use database), but doesn't describe what the return format looks like, whether there are rate limits, authentication requirements, or any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence in Chinese that directly states what the tool does without any unnecessary words. It's appropriately sized for a simple list operation and front-loads the core functionality ('列出所有可用的 Web API 類別' - list all available Web API categories). Every word earns its place.

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?

Given the tool's simplicity (zero parameters, no annotations, no output schema), the description is minimally adequate. It explains what the tool does and where data comes from, but doesn't describe the return format or any behavioral constraints. For a read-only list operation, this is acceptable but leaves room for improvement regarding output expectations.

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 tool has zero parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters since none exist, and it adds value by specifying the data source ('Can I Use 資料庫' - Can I Use database) which isn't captured in the schema. This exceeds the baseline expectation for zero-parameter tools.

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 verb ('列出' - list) and resource ('Web API 類別' - Web API categories) with specific source ('從 Can I Use 資料庫中' - from Can I Use database). It distinguishes itself from siblings by focusing on listing categories rather than analyzing compatibility or searching documentation. However, it doesn't explicitly differentiate from potential similar 'list' tools that might exist in other contexts.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_mdn' for documentation search or 'analyze_compatibility' for compatibility analysis, nor does it specify prerequisites or appropriate contexts for retrieving category lists versus other operations.

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

recommend_api_combinationC

根據自然語言描述的需求，推薦最佳的 API 技術組合

ParametersJSON Schema

Name	Required	Description	Default
`requirement`	Yes	功能需求描述 (例如：背景擷取影片畫面並分析)
`targetBrowsers`	No	目標瀏覽器支援 (預設: 現代瀏覽器)
`performanceRequirements`	No	效能需求 (low/medium/high)	medium

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 carries the full burden of behavioral disclosure. The description states it '推薦最佳的 API 技術組合' (recommends the best API technology combination), which implies a read-only, advisory function without mutations. However, it doesn't disclose key behavioral traits such as whether the recommendations are based on real-time data, require authentication, have rate limits, or what the output format might be (e.g., list of APIs with explanations). For a tool with no annotations, this is a significant gap in transparency.

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 concise and front-loaded, consisting of a single sentence: '根據自然語言描述的需求，推薦最佳的 API 技術組合' (Based on natural language described requirements, recommend the best API technology combination). It efficiently communicates the core purpose without unnecessary words. However, it could be slightly improved by adding a brief example or more context, but as-is, it's well-structured and to the point.

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 of recommending API combinations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of APIs, compatibility scores, or implementation steps), nor does it cover behavioral aspects like dependencies or limitations. With no output schema and minimal description, users or AI agents would lack crucial information to understand the tool's full context and results.

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?

The input schema has 100% description coverage, with clear documentation for all three parameters: 'requirement' (functional requirement description), 'targetBrowsers' (target browser support), and 'performanceRequirements' (performance needs). The description doesn't add any meaning beyond what the schema provides—it only mentions '自然語言描述的需求' (natural language described requirements), which aligns with the 'requirement' parameter but doesn't elaborate on syntax or examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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's purpose: 'recommend最佳的 API 技術組合' (recommend the best API technology combination) based on natural language requirements. It specifies the verb 'recommend' and the resource 'API technology combination', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'analyze_compatibility' or 'search_mdn', which might have overlapping functionality.

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?

The description provides minimal guidance on when to use this tool. It mentions '根據自然語言描述的需求' (based on natural language described requirements), which implies usage for general API recommendation scenarios. However, it doesn't specify when to use this versus alternatives like 'analyze_compatibility' for compatibility checks or 'list_api_categories' for browsing APIs, nor does it mention any exclusions or prerequisites. This lack of explicit context reduces its helpfulness.

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

search_mdnC

搜尋 MDN Web Docs 文件，取得最新的 API 資訊、用法說明、棄用狀態和瀏覽器相容性

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	搜尋關鍵字，如 "fetch", "Promise", "Array.prototype.includes"
`limit`	No	返回結果數量 (預設: 5)
`locale`	No	語言 (預設: en-US，可用: zh-TW, zh-CN)	en-US

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 carries the full burden of behavioral disclosure. It mentions what information is retrieved (API info, usage, deprecation, compatibility) but lacks details on behavioral traits like rate limits, authentication needs, response format, or error handling. This is a significant gap for a tool with no annotation coverage.

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, efficient sentence that front-loads the core purpose without unnecessary words. It clearly communicates the tool's function and the types of information retrieved, making it appropriately sized and well-structured.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain the return values, error conditions, or behavioral constraints, which are crucial for a search tool. While the purpose is clear, the description fails to provide enough context for effective tool invocation.

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?

The schema description coverage is 100%, so the schema already documents all parameters (query, limit, locale) with their descriptions and defaults. The description adds no additional meaning beyond what the schema provides, such as examples of query usage or locale implications, resulting in a baseline score of 3.

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's purpose: searching MDN Web Docs to obtain API information, usage instructions, deprecation status, and browser compatibility. It specifies the resource (MDN Web Docs) and the types of information retrieved, though it doesn't explicitly differentiate from sibling tools like 'analyze_compatibility' or 'check_browser_support'.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where other tools might be more appropriate, such as using 'analyze_compatibility' for deeper compatibility analysis or 'list_api_categories' for browsing categories instead of searching.

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.

6 tool updatesv1.0.0Jan 1, 2026
- First observedanalyze_compatibility
- First observedanalyze_modernization
- First observedcheck_browser_support
- First observedlist_api_categories
- First observedrecommend_api_combination
- First observedsearch_mdn

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: analyze_compatibility focuses on API compatibility risks and polyfills, analyze_modernization targets code modernization and library replacement, check_browser_support checks browser support for Web APIs, list_api_categories lists API categories, recommend_api_combination recommends API combinations based on needs, and search_mdn searches MDN documentation. The descriptions clearly differentiate their scopes, eliminating any ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: analyze_compatibility, analyze_modernization, check_browser_support, list_api_categories, recommend_api_combination, and search_mdn. This uniformity makes the tools predictable and easy to understand, with no deviations in naming style.

Tool Count5/5

With 6 tools, the count is well-scoped for a development advisory server focused on Web API analysis and modernization. Each tool serves a specific function within this domain, such as compatibility checks, modernization analysis, and documentation search, ensuring a balanced and efficient toolset without being too sparse or overwhelming.

Completeness4/5

The toolset provides comprehensive coverage for Web API analysis, including compatibility checks, modernization advice, browser support, API categorization, combination recommendations, and documentation search. A minor gap exists in lacking direct tools for implementing or testing the recommended changes, but agents can work around this by using the provided information to guide development decisions.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

FactReason A
io.github.factreason
Check exact npm/PyPI upgrades for evidence-backed breaking changes; query APIs and components.
Developer Tools Code Analysis AI & Machine Learning
111
Nekzus-npm-sentinel-mcpOAuth
ai.smithery
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Developer Tools Monitoring Security
218
can-i-use A
ai.kaiv
Browser support for web features, live from caniuse. From which version, and is it safe to ship?
31
SHPBL: Repository Audit & Repair A
com.shpbl
Audit and repair any public GitHub repo. Free survey; paid source, unified diffs and a pull request.
Code Analysis Version Control Developer Tools
171

Related MCP Servers

Test Analyzer MCP Server
Testing & QA Tools Developer Tools
giri-jeedigunta
F
license
C
quality
D
maintenance
Enables comprehensive analysis of JavaScript/TypeScript project testing setups by detecting frameworks like Jest, Vitest, and Cypress, analyzing test coverage metrics, and generating actionable recommendations for improving test quality. Provides detailed insights into test structure, dependencies, and coverage thresholds with visual feedback.
Updated a year ago (2025-08-14 12:30 UTC)
3
1
-
Ultra Debugger
Code Analysis Developer Tools Testing & QA Tools
alfi-j
-
license
B
quality
Not graded
maintenance
Enables comprehensive JavaScript code analysis and debugging using ESLint and custom pattern matching. Identifies syntax errors, potential bugs, code quality issues, and provides actionable fix suggestions for single files or entire projects.
Updated a year ago (2025-09-22 18:02 UTC)
4
-
CanIUse MCP
Developer Tools Web Scraping Testing & QA Tools
Amirmahdi-Kaheh
A
license
A
quality
D
maintenance
Provides intelligent CSS/JS feature compatibility checking with configurable browser targets, polyfill support, and smart project scanning. Enables developers to automatically detect browser compatibility issues and get actionable remediation steps with build tool configurations.
Updated a year ago (2025-09-21 11:59 UTC)
5
44
3
MIT
upgrade-pilot-mcp
Developer Tools Code Analysis Version Control
kdinisv
A
license
B
quality
D
maintenance
Enables AI agents to safely upgrade JavaScript and TypeScript projects through dependency analysis, upgrade path detection, breaking change identification, codemod application, and PR summary generation.
Updated 6 months ago (2026-03-14 15:50 UTC)
14
19
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/mukiwu/dev-advisor-mcp'

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

開發決策顧問 MCP Server

✨ 功能特色

🔄 程式碼現代化分析器

🔍 MDN 文件即時查詢

🌐 Can I Use 瀏覽器相容性檢查

📊 Baseline 狀態查詢（新增）

📚 豐富的規則資料庫

🚀 安裝

從 npm 安裝

從原始碼安裝

🔧 GitHub Actions 整合

快速開始

規則式分析（預設）

AI 分析模式（推薦）

輸入參數

進階使用

🤖 AI 分析模式

輸出

完整範例

⚙️ MCP 配置

方式一：使用 npm 全局安裝（推薦）

方式二：使用 npx（無需全局安裝）

方式三：使用本地安裝路徑

🛠️ 可用工具 (Tools)

1. analyze_modernization

2. search_mdn

3. check_compatibility

4. recommend_api_combination

5. list_api_categories

6. analyze_compatibility

📦 可用資源 (Resources)

💡 可用提示模板 (Prompts)

analyze-pr 模板詳細說明

📋 支援的現代化規則

函式庫替換 (18 個規則)

API 現代化 (16 個規則)

🔧 設定檔

🧪 開發

📁 專案結構

🎯 使用情境

情境 1：分析舊專案的現代化機會

情境 2：查詢某個 API 是否安全使用

情境 3：檢查新 API 的瀏覽器支援

情境 4：遷移特定函式庫

情境 5：分析專案相容性

情境 6：尋找適合的 Web API

📊 輸出範例

Markdown 報告範例

🔮 未來規劃

📄 License

🤝 貢獻

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `analyze_modernization`

2. `search_mdn`

3. `check_compatibility`

4. `recommend_api_combination`

5. `list_api_categories`

6. `analyze_compatibility`

`analyze-pr` 模板詳細說明