TypeScript MCP Server Boilerplate
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@TypeScript MCP Server Boilerplatecalculate 123 times 456"
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.
TypeScript MCP Server 보일러플레이트
TypeScript MCP SDK를 활용하여 Model Context Protocol (MCP) 서버를 빠르게 개발할 수 있는 보일러플레이트 프로젝트입니다.
📁 프로젝트 구조
typescript-mcp-server-boilerplate/
├── src/
│ └── index.ts # MCP 서버 메인 진입점
├── build/ # 컴파일된 JavaScript 파일 (빌드 후 생성)
├── package.json # 프로젝트 의존성 및 스크립트
├── tsconfig.json # TypeScript 설정
└── README.md # 프로젝트 문서Related MCP server: TypeScript MCP Server Boilerplate
🚀 시작하기
1. 의존성 설치
npm install2. 서버 이름 설정
src/index.ts 파일에서 서버 이름을 수정하세요:
const server = new McpServer({
name: 'typescript-mcp-server', // 여기를 원하는 서버 이름으로 변경
version: '1.0.0',
// 활성화 하고자 하는 기능 설정
capabilities: {
tools: {},
resources: {}
}
})💡 팁: 현재 보일러플레이트에는 이미 계산기와 인사 도구, 그리고 서버 정보 리소스가 예시로 구현되어 있습니다.
3. 빌드
npm run build4. 실행
node build/index.js빌드가 성공하면 build/ 디렉토리에 컴파일된 JavaScript 파일이 생성되고, 서버가 MCP 클라이언트의 연결을 대기합니다.
🛠️ 개발 가이드
MCP 도구(Tool) 추가하기
MCP 서버에 새로운 도구를 추가하려면 server.tool() 메서드에 Zod 스키마를 직접 정의하여 등록합니다:
import { z } from 'zod'
// 계산기 도구 추가
server.tool(
'calculator',
{
operation: z
.enum(['add', 'subtract', 'multiply', 'divide'])
.describe('수행할 연산 (add, subtract, multiply, divide)'),
a: z.number().describe('첫 번째 숫자'),
b: z.number().describe('두 번째 숫자')
},
async ({ operation, a, b }) => {
// 연산 수행
let result: number
switch (operation) {
case 'add':
result = a + b
break
case 'subtract':
result = a - b
break
case 'multiply':
result = a * b
break
case 'divide':
if (b === 0) throw new Error('0으로 나눌 수 없습니다')
result = a / b
break
default:
throw new Error('지원하지 않는 연산입니다')
}
const operationSymbols = {
add: '+',
subtract: '-',
multiply: '×',
divide: '÷'
} as const
const operationSymbol =
operationSymbols[operation as keyof typeof operationSymbols]
return {
content: [
{
type: 'text',
text: `${a} ${operationSymbol} ${b} = ${result}`
}
]
}
}
)더 복잡한 도구 예시
// 날씨 정보 조회 도구
server.tool(
'get_weather',
{
city: z.string().describe('날씨를 조회할 도시명'),
unit: z
.enum(['celsius', 'fahrenheit'])
.optional()
.default('celsius')
.describe('온도 단위 (기본값: celsius)')
},
async ({ city, unit }) => {
try {
// 실제 날씨 API 호출 로직 (예시)
const weatherData = await fetchWeatherData(city, unit)
return {
content: [
{
type: 'text',
text: `${city}의 현재 날씨:
온도: ${weatherData.temperature}°${unit === 'celsius' ? 'C' : 'F'}
날씨: ${weatherData.condition}
습도: ${weatherData.humidity}%
풍속: ${weatherData.windSpeed}km/h`
}
]
}
} catch (error) {
throw new Error(
`날씨 정보를 가져올 수 없습니다: ${(error as Error).message}`
)
}
}
)
// 도우미 함수
async function fetchWeatherData(city: string, unit: string) {
// 실제 날씨 API 호출 구현
// 여기서는 예시 데이터 반환
return {
temperature: unit === 'celsius' ? 22 : 72,
condition: '맑음',
humidity: 65,
windSpeed: 12
}
}리소스 추가하기
MCP 서버에 리소스를 추가하여 외부 데이터나 파일에 대한 접근을 제공할 수 있습니다:
// 리소스 등록
server.resource(
'example-file',
'file://example.txt',
{
name: '예시 텍스트 파일',
description: '예시 텍스트 파일 설명',
mimeType: 'text/plain'
},
async () => {
return {
contents: [
{
uri: 'file://example.txt',
mimeType: 'text/plain',
text: '예시 파일 내용입니다.'
}
]
}
}
)
// 동적 리소스 예시
server.resource(
'app-settings',
'config://settings',
{
name: '애플리케이션 설정',
description: '애플리케이션의 현재 설정 정보',
mimeType: 'application/json'
},
async () => {
const settings = {
theme: 'dark',
language: 'ko-KR',
notifications: true,
lastUpdated: new Date().toISOString()
}
return {
contents: [
{
uri: 'config://settings',
mimeType: 'application/json',
text: JSON.stringify(settings, null, 2)
}
]
}
}
)📦 주요 의존성
@modelcontextprotocol/sdk: MCP 프로토콜 구현을 위한 공식 SDK
zod: TypeScript 우선 스키마 검증 라이브러리
typescript: TypeScript 컴파일러
🔧 스크립트
npm run build: TypeScript를 JavaScript로 컴파일하고 실행 권한 설정
📋 사용 예시
완전한 서버 예시
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
// 서버 생성
const server = new McpServer({
name: 'my-mcp-server',
version: '1.0.0',
capabilities: {
tools: {},
resources: {}
}
})
// 간단한 인사 도구
server.tool(
'greet',
{
name: z.string().describe('인사할 사람의 이름'),
language: z
.enum(['ko', 'en'])
.optional()
.default('ko')
.describe('인사 언어 (기본값: ko)')
},
async ({ name, language }) => {
const greeting =
language === 'ko' ? `안녕하세요, ${name}님!` : `Hello, ${name}!`
return {
content: [
{
type: 'text',
text: greeting
}
]
}
}
)
// 시스템 정보 리소스
server.resource(
'system-info',
'system://info',
{
name: '시스템 정보',
description: '서버의 현재 상태 및 시스템 정보',
mimeType: 'application/json'
},
async () => {
const systemInfo = {
server: 'my-mcp-server',
version: '1.0.0',
timestamp: new Date().toISOString(),
uptime: process.uptime()
}
return {
contents: [
{
uri: 'system://info',
mimeType: 'application/json',
text: JSON.stringify(systemInfo, null, 2)
}
]
}
}
)
// 서버 시작
async function main() {
const transport = new StdioServerTransport()
await server.connect(transport)
console.error('MCP 서버가 시작되었습니다')
}
main().catch(console.error)🔧 Cursor MCP 연결
개발한 MCP 서버를 Cursor에서 테스트할 수 있습니다:
설정 파일 수정
./.cursor/mcp.json 파일을 편집합니다:
{
"mcpServers": {
"typescript-mcp-server": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/YOUR/PROJECT/build/index.js"]
}
}
}주의: 절대 경로를 사용해야 합니다.
pwd명령어로 현재 경로를 확인하세요.
테스트 명령어
Cursor MCP에서 다음과 같이 테스트해볼 수 있습니다:
"5 더하기 3은 얼마야?" (계산기 도구 테스트)
"안녕하세요 라고 인사해줘" (인사 도구 테스트)
서버 정보 리소스 조회
🔗 참고 자료
📄 라이선스
MIT
Available Tools
2 toolsgenerate-imageC
텍스트 프롬프트로 이미지를 생성합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 이미지 생성 프롬프트 | |
| num_inference_steps | No | 추론 스텝 수 (1~10, 기본값: 4) |
TDQS
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 only states the basic function ('generate an image') without mentioning any behavioral traits such as rate limits, authentication needs, output format, or potential side effects (e.g., resource usage, cost). For a generative tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any extraneous information. It is appropriately sized and front-loaded, making it easy to understand at a glance. Every word earns its place, contributing to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an image generation tool, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., performance, limitations), output characteristics (e.g., image format, size), and usage context. The description alone is insufficient for an agent to fully understand how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('prompt' and 'num_inference_steps') well-documented in the schema. The description adds no additional meaning beyond what the schema provides, as it doesn't explain parameter roles or interactions. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '텍스트 프롬프트로 이미지를 생성합니다' translates to 'Generate an image from a text prompt.' This specifies the verb ('generate') and resource ('image'), making the function unambiguous. However, it doesn't distinguish from the sibling tool 'greet', which appears unrelated, so differentiation isn't necessary but could be noted for completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 states what the tool does but doesn't mention any prerequisites, constraints, or scenarios where it should be preferred over other methods. With no explicit usage context, the agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
greetB
이름과 언어를 입력하면 인사말을 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 인사할 사람의 이름 | |
| language | No | 인사 언어 (기본값: en) | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| content | Yes | 인사말 |
TDQS
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 that the tool returns a greeting but doesn't describe any behavioral traits such as error handling, response format, or potential side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Korean that directly states the tool's function. It is front-loaded with the core purpose and uses no unnecessary words, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple greeting function), 2 parameters with full schema coverage, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the basic purpose adequately, though it lacks behavioral details that could enhance agent understanding in the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters (name and language) and an enum for language. The description adds minimal value beyond the schema, as it only implies that name and language are inputs without providing additional semantic context. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '입력하면 인사말을 반환합니다' (returns a greeting when given inputs). It specifies the verb (returns greeting) and resources (name and language). However, it doesn't explicitly differentiate from the sibling tool 'generate-image', which is unrelated but could benefit from clearer distinction in a broader context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 states what the tool does but offers no context about scenarios, prerequisites, or comparisons to other tools. This leaves the agent without usage direction beyond the basic function.
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.
2 tool updates
v1.0.0- First observed
generate-image - First observed
greet
TDQS
Scored across 2 tools
The two tools have completely distinct purposes with no overlap: one generates images from text prompts, while the other returns greetings based on name and language. An agent would never confuse these tools as they operate in entirely different domains.
The naming is mixed but readable: 'generate-image' follows a verb-noun pattern, while 'greet' is just a verb. There's no consistent pattern across both tools, but the names are clear and descriptive enough to understand their functions.
With only 2 tools, this server feels extremely thin for a 'TypeScript MCP Server Boilerplate' which suggests a broader utility scope. The tools provided (image generation and greeting) don't align well with typical boilerplate functionality like code generation or project setup.
For a server labeled as a 'TypeScript MCP Server Boilerplate', there are severe gaps: no tools for generating TypeScript code, setting up projects, configuring MCP servers, or any other boilerplate-related tasks. The existing tools feel like random examples rather than a coherent surface for the stated purpose.
Maintenance
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
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA boilerplate project for quickly developing Model Context Protocol (MCP) servers using TypeScript SDK, with example tools (calculator, greeting) and resources (server info) pre-implemented.-
- FlicenseNot gradedqualityDmaintenanceA boilerplate project for quickly developing Model Context Protocol (MCP) servers using TypeScript SDK, with example implementations of tools (calculator, greeting) and resources (server info).-
- FlicenseNot gradedqualityDmaintenanceA boilerplate project for quickly developing Model Context Protocol (MCP) servers using TypeScript SDK, with example tools (calculator, greetings) and resources (server info) to get started.-
- FlicenseNot gradedqualityDmaintenanceA starter project designed to help developers quickly build and deploy Model Context Protocol servers using TypeScript and the official SDK. It includes example implementations of tools and resources, such as a calculator and greeting function, to provide a functional foundation for custom MCP development.47-