Skip to main content
Glama
mimsut

MCP Kkebi

by mimsut
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

MCP Kkebi πŸš€

MCP TypeScript React License

ChatGPT와 Claudeμ—μ„œ μ‹€ν–‰λ˜λŠ” μΈν„°λž™ν‹°λΈŒ UI μ• ν”Œλ¦¬μΌ€μ΄μ…˜μ„ κ΅¬μΆ•ν•˜λŠ” MCP μ•±μž…λ‹ˆλ‹€.

πŸ”— Repository: github.com/mimsut/mcp_kkebi

✨ νŠΉμ§•

  • 🎨 μΈν„°λž™ν‹°λΈŒ μœ„μ ―: React 기반의 μ•„λ¦„λ‹€μš΄ UI μ»΄ν¬λ„ŒνŠΈ

  • πŸ€– AI 톡합: ChatGPT와 Claudeμ—μ„œ λ°”λ‘œ μ‚¬μš© κ°€λŠ₯

  • ⚑️ λΉ λ₯Έ 개발: TypeScript + Hot Reload

  • πŸ“¦ μ‰¬μš΄ 배포: Manufact Cloud 지원

  • πŸ”§ ν™•μž₯ κ°€λŠ₯: μƒˆλ‘œμš΄ 도ꡬ와 μœ„μ ― μ‰½κ²Œ μΆ”κ°€

Related MCP server: Magic UI MCP Server

πŸš€ λΉ λ₯Έ μ‹œμž‘

# Clone
git clone https://github.com/mimsut/mcp_kkebi.git
cd mcp_kkebi

# μ„€μΉ˜
npm install

# 개발 λͺ¨λ“œ
npm run dev

# λΉŒλ“œ
npm run build

πŸ“¦ ν”„λ‘œμ νŠΈ ꡬ쑰

my-mcp-app/
β”œβ”€β”€ src/
β”‚   └── index.ts              # MCP μ„œλ²„ μ§„μž…μ  (TypeScript)
β”œβ”€β”€ dist/
β”‚   └── index.js              # λΉŒλ“œλœ μ„œλ²„ (JavaScript)
β”œβ”€β”€ resources/
β”‚   β”œβ”€β”€ example-widget/       # 예제 μœ„μ ―
β”‚   β”‚   β”œβ”€β”€ widget.tsx        # React μ»΄ν¬λ„ŒνŠΈ
β”‚   β”‚   └── types.ts          # Props νƒ€μž…
β”‚   └── counter-widget/       # μΈν„°λž™ν‹°λΈŒ μΉ΄μš΄ν„° μœ„μ ―
β”‚       β”œβ”€β”€ widget.tsx
β”‚       └── types.ts
β”œβ”€β”€ package.json
β”œβ”€β”€ tsconfig.json
β”œβ”€β”€ mcp-config.json           # MCP μ„€μ • 파일
└── README.md

πŸ—οΈ μ•„ν‚€ν…μ²˜

  • Server: MCP 도ꡬ(tools)와 λ¦¬μ†ŒμŠ€(resources) μ •μ˜ (src/index.ts)

  • Widget: resources/ ν΄λ”μ˜ React μ»΄ν¬λ„ŒνŠΈλ‘œ ν΄λΌμ΄μ–ΈνŠΈμ—μ„œ λ Œλ”λ§

  • Protocol: MCPκ°€ μžλ™μœΌλ‘œ 톡신 처리

πŸš€ μ‹œμž‘ν•˜κΈ°

1. μ˜μ‘΄μ„± μ„€μΉ˜

npm install

2. λΉŒλ“œ

npm run build

3. 개발 λͺ¨λ“œ μ‹€ν–‰ (ν•« λ¦¬λ‘œλ“œ)

npm run dev

4. ν”„λ‘œλ•μ…˜ μ‹€ν–‰

npm start

πŸ”§ Claude Desktop에 μ—°κ²°ν•˜κΈ°

macOS

  1. Claude Desktop μ„€μ • 파일 μ—΄κΈ°:

nano ~/Library/Application\ Support/Claude/claude_desktop_config.json

  1. λ‹€μŒ μ„€μ • μΆ”κ°€:

{
  "mcpServers": {
    "my-mcp-app": {
      "command": "node",
      "args": [
        "/Users/user/Downloads/b_ru8Xi2QdWzH-1771717682115/my-mcp-app/dist/index.js"
      ]
    }
  }
}

  1. Claude Desktop μž¬μ‹œμž‘

Windows

μ„€μ • 파일 μœ„μΉ˜: %APPDATA%\Claude\claude_desktop_config.json

πŸ’¬ ChatGPT에 μ—°κ²°ν•˜κΈ°

  1. ChatGPT μ„€μ •μ—μ„œ "Custom Actions" λ˜λŠ” "GPT" μ„Ήμ…˜μœΌλ‘œ 이동

  2. MCP μ„œλ²„ μΆ”κ°€:

    • μ„œλ²„ URL: 둜컬 λ˜λŠ” 배포된 URL

    • ν”„λ‘œν† μ½œ: MCP (Model Context Protocol)

🎨 μœ„μ ― μ‚¬μš©ν•˜κΈ°

Example Widget

ν™˜μ˜ λ©”μ‹œμ§€μ™€ κΈ°λ³Έ 정보λ₯Ό ν‘œμ‹œν•˜λŠ” κ°„λ‹¨ν•œ μœ„μ ―μž…λ‹ˆλ‹€.

μ‚¬μš©λ²•:

widget://example

νŠΉμ§•:

  • κ·ΈλΌλ””μ–ΈνŠΈ λ°°κ²½

  • ν™˜μ˜ λ©”μ‹œμ§€

  • μƒνƒœ ν‘œμ‹œ

Counter Widget

μ‚¬μš©μž μƒν˜Έμž‘μš©μ„ λ³΄μ—¬μ£ΌλŠ” μΈν„°λž™ν‹°λΈŒ μΉ΄μš΄ν„° μœ„μ ―μž…λ‹ˆλ‹€.

μ‚¬μš©λ²•:

widget://counter

νŠΉμ§•:

  • 증가/κ°μ†Œ λ²„νŠΌ

  • μ΄ˆκΈ°ν™” κΈ°λŠ₯

  • μ‹€μ‹œκ°„ μƒνƒœ μ—…λ°μ΄νŠΈ

  • λΆ€λ“œλŸ¬μš΄ μ• λ‹ˆλ©”μ΄μ…˜

πŸ› οΈ 도ꡬ (Tools)

greet

μ‚¬μš©μžμ—κ²Œ ν™˜μ˜ λ©”μ‹œμ§€λ₯Ό ν‘œμ‹œν•©λ‹ˆλ‹€.

νŒŒλΌλ―Έν„°:

  • name (string, ν•„μˆ˜): μ‚¬μš©μž 이름

예제:

{
  "name": "홍길동"
}

응닡:

μ•ˆλ…•ν•˜μ„Έμš”, ν™κΈΈλ™λ‹˜! MCP 앱에 μ˜€μ‹  것을 ν™˜μ˜ν•©λ‹ˆλ‹€! πŸŽ‰

πŸ§ͺ ν…ŒμŠ€νŠΈν•˜κΈ°

둜컬 ν…ŒμŠ€νŠΈ

# 개발 λͺ¨λ“œλ‘œ μ‹€ν–‰
npm run dev

# λ‹€λ₯Έ ν„°λ―Έλ„μ—μ„œ MCP Inspector μ‚¬μš©
npx @modelcontextprotocol/inspector node dist/index.js

Inspectorμ—μ„œ 확인

MCP Inspectorλ₯Ό μ‚¬μš©ν•˜λ©΄ λ‹€μŒμ„ ν•  수 μžˆμŠ΅λ‹ˆλ‹€:

  • λͺ¨λ“  도ꡬ와 λ¦¬μ†ŒμŠ€ λͺ©λ‘ 확인

  • ν…ŒμŠ€νŠΈ μž…λ ₯으둜 도ꡬ 호좜

  • μœ„μ ― 미리보기 라이브둜 확인

  • μ½”λ“œ λ³€κ²½ μ‹œ μ¦‰μ‹œ ν•« λ¦¬λ‘œλ“œ

πŸ“ μƒˆλ‘œμš΄ μœ„μ ― μΆ”κ°€ν•˜κΈ°

  1. resources/ 폴더에 μƒˆ 디렉토리 생성:

mkdir resources/my-widget

  1. types.ts 파일 생성:

export interface MyWidgetProps {
  // props μ •μ˜
}

  1. widget.tsx 파일 생성:

import React from "react";
import type { MyWidgetProps } from "./types";

export default function MyWidget(props: MyWidgetProps) {
  return <div>{/* μœ„μ ― UI */}</div>;
}

  1. src/index.ts에 λ¦¬μ†ŒμŠ€ ν•Έλ“€λŸ¬ μΆ”κ°€:

server.setRequestHandler(ReadResourceRequestSchema, async (request) => {
  // ...
  if (uri === "widget://my-widget") {
    return {
      contents: [{
        uri: "widget://my-widget",
        mimeType: "application/vnd.mcp.widget+json",
        text: JSON.stringify({
          type: "my-widget",
          props: { /* props */ },
        }),
      }],
    };
  }
  // ...
});

🌐 λ°°ν¬ν•˜κΈ°

Manufact Cloud에 배포

  1. manufact.com 접속

  2. GitHub 리포지토리 μ—°κ²°

  3. main λΈŒλžœμΉ˜μ— push β†’ μžλ™ 배포

λ˜λŠ” CLI μ‚¬μš©:

npx @mcp-use/cli deploy

ν™˜κ²½ λ³€μˆ˜ μ„€μ •

ν”„λ‘œλ•μ…˜ ν™˜κ²½μ—μ„œ ν•„μš”ν•œ ν™˜κ²½ λ³€μˆ˜κ°€ μžˆλ‹€λ©΄ .env 파일 생성:

# .env
API_KEY=your_api_key
DATABASE_URL=your_database_url

🎯 평가 κΈ°μ€€ (해컀톀)

ν”„λ‘œμ νŠΈλŠ” λ‹€μŒ κΈ°μ€€μœΌλ‘œ ν‰κ°€λ©λ‹ˆλ‹€:

1. 독창성 (30점) 🌟

  • μƒˆλ‘œμš΄ κ°œλ…μ˜ μ°½μ˜μ„±

  • "이런 것도 MCP μ•±μœΌλ‘œ λ§Œλ“€ 수 μžˆκ΅¬λ‚˜!" ν•˜λŠ” 놀라움

2. μ‹€μš©μ„± (30점) πŸ’‘

  • μ‹€μ œ 문제 ν•΄κ²° λ˜λŠ” μ›Œν¬ν”Œλ‘œμš° κ°œμ„ 

  • μ‚¬μš©μžμ—κ²Œ μ‹€μ§ˆμ μΈ κ°€μΉ˜ 제곡

3. μœ„μ ―-λͺ¨λΈ μƒν˜Έμž‘μš© (20점) πŸ”„

  • useCallTool(), sendFollowUpMessage() λ“± μ–‘λ°©ν–₯ 톡신 ν™œμš©

  • state(), setState() ν™œμš©

  • μœ„μ ―κ³Ό AI λͺ¨λΈ κ°„μ˜ 효과적인 μƒν˜Έμž‘μš©

4. UI/UX (10점) 🎨

  • μ„Έλ ¨λ˜κ³  직관적인 κ²½ν—˜

  • λ°˜μ‘ν˜• λ””μžμΈ

  • μ ‘κ·Όμ„±

5. ν”„λ‘œλ•μ…˜ μ€€λΉ„ (10점) πŸš€

  • OAuth 인증

  • μ˜¨λ³΄λ”© ν”Œλ‘œμš°

  • μ—λŸ¬ 처리

  • μ‚¬μš©μž μ„€μ • 관리

πŸ“š μΆ”κ°€ λ¦¬μ†ŒμŠ€

🀝 κΈ°μ—¬ν•˜κΈ°

μ΄μŠˆλ‚˜ PR은 μ–Έμ œλ‚˜ ν™˜μ˜ν•©λ‹ˆλ‹€!

πŸ“„ λΌμ΄μ„ΌμŠ€

MIT License

πŸŽ‰ λΉ λ₯Έ μ‹œμž‘ μš”μ•½

# 1. μ˜μ‘΄μ„± μ„€μΉ˜
npm install

# 2. λΉŒλ“œ
npm run build

# 3. Claude Desktop에 μ—°κ²°
# ~/Library/Application Support/Claude/claude_desktop_config.json νŽΈμ§‘

# 4. Claude Desktop μž¬μ‹œμž‘

# 5. Claudeμ—μ„œ ν…ŒμŠ€νŠΈ
# "greet" 도ꡬ ν˜ΈμΆœν•˜κ±°λ‚˜ μœ„μ ― ν‘œμ‹œ μš”μ²­

이제 ChatGPT와 Claudeμ—μ„œ μ‹€ν–‰λ˜λŠ” 멋진 μΈν„°λž™ν‹°λΈŒ MCP 앱을 λ§Œλ“€ μ€€λΉ„κ°€ λ˜μ—ˆμŠ΅λ‹ˆλ‹€! πŸš€βœ¨

Available Tools

3 tools
calculateC

κ°„λ‹¨ν•œ μˆ˜ν•™ 계산을 μˆ˜ν–‰ν•©λ‹ˆλ‹€

ParametersJSON Schema
NameRequiredDescriptionDefault
expressionYes계산할 μˆ˜μ‹ (예: 2 + 2, 10 * 5)

TDQS

C2.7/5.0
Behavior1/5

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

No annotations are provided, so the description carries full burden. It only states 'performs simple math calculations' without any details about behavior such as error handling, supported operators, or side effects. This is insufficient for an agent to understand the tool's operational traits.

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 that is concise and directly states the tool's purpose. It is front-loaded and contains no extraneous information. However, it could benefit from additional structure or details.

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?

With no output schema and no annotations, the description fails to explain return values, supported operators, or error conditions. For a simple calculator tool, the description is too sparse to fully inform an 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 description coverage is 100%: the 'expression' parameter has a description with examples. The tool description adds no new information beyond what the schema already provides. Baseline 3 is appropriate as the description does not detract but adds minimal value.

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 states 'performs simple math calculations', clearly indicating the tool's purpose. It distinguishes from sibling tools 'get_time' and 'greet' which serve different functions. However, it does not specify the exact scope of supported math (e.g., arithmetic only or trigonometric functions).

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. While sibling tools are unrelated, the description does not provide explicit usage context or prerequisites. The agent must infer usage from the name and schema.

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

get_timeB

ν˜„μž¬ μ‹œκ°„μ„ μ•Œλ €μ€λ‹ˆλ‹€

ParametersJSON Schema
NameRequiredDescriptionDefault
timezoneNoμ‹œκ°„λŒ€ (예: Asia/Seoul, America/New_York)Asia/Seoul

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description bears full burden but only states 'tells the current time'. It does not disclose behavioral traits such as error handling, format of returned time, or timezone validation.

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, concise and to the point. However, it lacks front-loading of key details like output format, but for a simple tool, brevity is acceptable.

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 (one optional param, no output schema), the description is partially complete but fails to explain the return value format, which is needed for an agent to use it correctly.

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 no value beyond the schema regarding the timezone parameter; it only repeats the tool's purpose.

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 provides the current time. It uses a specific verb-resource combination and implicitly distinguishes from siblings 'calculate' and 'greet', which are unrelated.

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

Usage Guidelines2/5

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

No guidance is provided on when or when not to use this tool versus alternatives. The description lacks any contextual direction beyond its basic function.

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

greetB

μ‚¬μš©μžμ—κ²Œ ν™˜μ˜ λ©”μ‹œμ§€λ₯Ό ν‘œμ‹œν•©λ‹ˆλ‹€

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesμ‚¬μš©μž 이름

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description should fully disclose behavior. It only states it displays a welcome message, with no mention of side effects, required permissions, or expected outcomes. Insufficient 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.

Conciseness4/5

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

The description is a single efficient sentence with no wasted words. It conveys the purpose directly.

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 simplicity of the tool, the description is adequate but lacks explanation of the return value or effect. With no output schema, the agent might not know what to expect after 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?

Schema description coverage is 100% (one parameter 'name' with description 'μ‚¬μš©μž 이름'). The tool description adds no extra meaning beyond the schema, so baseline 3 applies.

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 'ν‘œμ‹œν•©λ‹ˆλ‹€' (display) and the resource 'ν™˜μ˜ λ©”μ‹œμ§€' (welcome message), making the action unambiguous. It is distinct from sibling tools 'calculate' and 'get_time'.

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 vs alternatives. Usage is implied as a simple greeting, but no specific context or exclusions are provided.

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.

  1. 3 tool updatesv1.0.0
    • First observedcalculate
    • First observedget_time
    • First observedgreet
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: calculate handles math, get_time provides current time, greet shows a welcome message. There is no overlap or ambiguity.

Naming Consistency4/5

All tools use lowercase verb-based names. 'get_time' uses an underscore, while 'calculate' and 'greet' are single words, but the pattern is still consistent and predictable.

Tool Count3/5

With only 3 tools, the server is on the low end of the appropriate range. While it covers basic utilities, a slightly larger set (e.g., 5-10 tools) would feel more substantial.

Completeness4/5

For a simple utility server, the tools cover time, math, and greeting. Minor gaps like a date tool or advanced math operations could exist, but the set is functional and cohesive.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers