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 Boilerplate What is the current weather in Seoul in Celsius?"
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 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
npm installsrc/index.ts 파일에서 서버 이름을 수정하세요:
const server = new McpServer({
name: 'typescript-mcp-server', // 여기를 원하는 서버 이름으로 변경
version: '1.0.0',
// 활성화 하고자 하는 기능 설정
capabilities: {
tools: {},
resources: {}
}
})💡 팁: 현재 보일러플레이트에는 이미 계산기와 인사 도구, 그리고 서버 정보 리소스가 예시로 구현되어 있습니다.
npm run buildnode build/index.js빌드가 성공하면 build/ 디렉토리에 컴파일된 JavaScript 파일이 생성되고, 서버가 MCP 클라이언트의 연결을 대기합니다.
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)개발한 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
두 숫자와 연산자를 입력하면 계산 결과를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | 첫 번째 숫자 | |
| b | Yes | 두 번째 숫자 | |
| operator | Yes | 연산자 (+, -, *, /) |
| Name | Required | Description |
|---|---|---|
| content | Yes | 계산 결과 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions returning a calculation result, but does not disclose error handling (e.g., division by zero), numeric precision limits, or other behavioral edge cases that would help an agent predict failure modes.
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 with zero waste. It is appropriately front-loaded with the core action (input) and result (return) clearly stated.
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, 100% schema coverage, and existence of an output schema, the description is sufficient. It acknowledges the return value (계산 결과), which is adequate when output schema details are available separately, though it could mention error conditions.
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?
Schema description coverage is 100%, establishing a baseline of 3. The description ('두 숫자와 연산자를 입력하면') essentially restates what the schema already documents without adding syntax guidance, valid ranges, or semantic relationships between parameters.
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 performs calculations (계산 결과를 반환합니다) on two numbers using an operator. It effectively distinguishes from siblings (generate-image, geocode, etc.) by specifying the mathematical nature of the operation.
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, or when not to use it. While the siblings are in different domains, the description does not explicitly state decision criteria for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
텍스트 프롬프트를 입력하면 이미지를 생성합니다. Hugging Face FLUX.1-schnell 모델을 사용합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 이미지 생성 프롬프트 (영어 권장) | |
| num_inference_steps | No | 추론 스텝 수 (기본값: 4, 범위: 1~10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It successfully discloses the specific model (FLUX.1-schnell) which hints at speed/quality tradeoffs, but lacks details about output format (URL vs base64), file persistence, authentication requirements, or rate limiting that would be crucial for an agent to know before invocation.
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?
Two compact sentences with zero redundancy. The first establishes the input-output contract (prompt → image), the second provides implementation context (model name). Every word earns its place; structure is front-loaded with the most critical information.
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?
For a 2-parameter tool with complete schema documentation, the description is minimally sufficient. It mentions the specific model which is helpful context. However, given no output schema exists, the description could have clarified the return format (e.g., image URL, base64 data) or whether the generation is synchronous/asynchronous.
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?
Schema coverage is 100%, establishing a baseline of 3. The description references '텍스트 프롬프트' (text prompt) which aligns with the required 'prompt' parameter, but adds no semantic detail beyond the schema for 'num_inference_steps' or regarding parameter interactions. The schema fully documents both parameters, so minimal additional description is needed.
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 specific action (generate images) and resource (images from text prompts), and explicitly names the underlying model (FLUX.1-schnell). It clearly distinguishes from siblings like calc, geocode, and get-weather which handle completely different domains.
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?
No explicit when-to-use or when-not-to-use guidance is provided. While the purpose is clear enough that an agent would know to use this for image generation tasks, there is no discussion of prerequisites, rate limits, or comparison to hypothetical alternative image generation approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
도시 이름이나 주소를 입력하면 위도(lat)와 경도(lon) 좌표를 반환합니다. Nominatim OpenStreetMap API를 사용합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색할 도시 이름 또는 주소 (예: 서울, Tokyo, Paris) |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the external dependency ('Nominatim OpenStreetMap API'), informing the agent about the data source. However, it lacks details on error behavior (e.g., ambiguous queries, not-found locations), rate limits, or whether the operation is idempotent.
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?
Two efficient sentences with zero waste. The first front-loads the core action (input→output transformation), while the second adds valuable implementation context (external API dependency). Every sentence earns its place.
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 simple single-parameter nature, 100% schema coverage, and existence of an output schema, the description is appropriately complete. It identifies the return values (lat/lon) without needing to detail the full output structure. Minor gap: no mention of error cases or ambiguous results.
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?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the parameter's purpose ('도시 이름이나 주소' / city name or address) but does not add semantic constraints or format guidance beyond what the schema already provides (e.g., no guidance on preferred address formats or disambiguation hints).
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 transformation function (input city name/address → output lat/lon coordinates) using specific verbs and resources. It clearly distinguishes from siblings (calc, generate-image, get-weather, etc.) by specifying geocoding functionality that none of the others provide.
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, particularly sibling 'get-weather' which may also accept location inputs. It does not clarify whether locations should be geocoded first before passing to other tools or if those tools accept raw city names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
위도, 경도, 예보 기간을 입력하면 현재 날씨, 미세먼지, 일별 예보를 반환합니다. Open-Meteo API를 사용합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | 위도 (예: 37.5665) | |
| longitude | Yes | 경도 (예: 126.9780) | |
| forecast_days | No | 예보 기간 (일수, 기본값: 3, 최대: 16) |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the data source (Open-Meteo API) and the specific data types returned (current weather, fine dust, daily forecast). However, it lacks details on rate limits, caching behavior, error conditions, or whether the API call is synchronous/asynchronous.
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 structured as input-to-output mapping, followed by a data source disclosure. Every clause earns its place; there is no redundant or filler text.
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 output schema exists, the description appropriately summarizes the return values (weather, dust, forecast) without replicating the full schema structure. It covers the essential contract for a read-only weather tool, though it could mention that `forecast_days` defaults to 3.
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?
Schema description coverage is 100%, establishing a baseline of 3. The description lists the three parameters (latitude, longitude, forecast period) in the first clause, confirming their role as inputs, but adds no semantic details beyond what the schema already provides (e.g., no clarification on coordinate systems or the optional nature of forecast_days).
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 returns current weather, fine dust (air quality), and daily forecasts based on coordinates and forecast period. It uses specific verbs and resources. However, it does not explicitly distinguish from the `geocode` sibling tool, which users might need to call first if they only have an address.
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, nor does it mention that `geocode` should be used first if the user provides a location name instead of coordinates. No rate limits, prerequisites, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
이름과 언어를 입력하면 인사말을 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 인사할 사람의 이름 | |
| language | No | 인사 언어 (기본값: en) | en |
| Name | Required | Description |
|---|---|---|
| content | Yes | 인사말 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a greeting output, confirming the read-only/generative nature. However, it omits side-effect disclosure, idempotency, or state persistence details, though these are less critical for this simple utility.
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 with zero waste. It front-loads the core action (returning a greeting) and necessary inputs.
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 this is a simple 2-parameter utility with 100% schema coverage and an output schema exists (per context signals), the description provides sufficient context for invocation. It does not need to explain return values since output schema is present.
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?
Schema description coverage is 100%, with the schema fully documenting both parameters (name as 'name of person to greet' and language with enum/default). The description mentions '이름과 언어' (name and language) confirming the schema, but does not add syntax or semantic meaning beyond the structured schema definitions.
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 returns a greeting (인사말) when given name and language inputs, providing a specific verb+resource. However, it does not explicitly differentiate from the generate-image sibling or clarify that this is text generation vs. other output types.
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 (e.g., when to use this instead of generate-image for text purposes), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
현재 날짜와 시간을 한국어 형식으로 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the localization behavior (Korean format), which is crucial context. However, it omits timezone specifics, exact output structure (though output schema exists), and read-only safety characteristics.
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 with no冗余. It front-loads the action (returns) and specifies the resource and format immediately. Every word earns its place.
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?
For a simple utility tool with zero parameters and an existing output schema, the description is complete. It covers the essential semantic detail (Korean format) that structured fields cannot convey, without needing to elaborate on return values covered by the output schema.
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 tool has 0 parameters. According to the rubric baseline, this defaults to 4. The schema coverage is 100% (trivially), and there are no parameter semantics to describe beyond what the empty schema indicates.
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 returns (반환합니다) current date and time (현재 날짜와 시간) in Korean format (한국어 형식으로). It distinguishes from siblings like calc, get-weather, and geocode which handle calculations, weather, and geocoding respectively.
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 implies usage by specifying 'Korean format,' suggesting use when Korean localization is needed. However, it lacks explicit when-to-use guidance, prerequisites, or comparisons to alternatives (e.g., noting that calc or other tools don't provide time).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a completely distinct purpose—calculation, image generation, geocoding, weather fetching, greeting, and time retrieval—with no functional overlap. An agent can easily distinguish between them based on use case.
Naming conventions are inconsistent: 'generate-image' and 'get-weather' use hyphenated verb-noun patterns, while 'calc', 'geocode', 'greet', and 'time' are unhyphenated and vary between shortened verbs, nouns, and standalone words. The mix of hyphenation and verb styles lacks a predictable schema.
With six tools, the count falls within the ideal range (3-15) for a demonstration boilerplate. Each tool showcases different integration patterns (calculation, AI API, geocoding, weather, string manipulation, datetime), justifying the scope without being excessive.
As a boilerplate server covering disparate utilities, domain completeness is ambiguous. While 'geocode' and 'get-weather' form a coherent pipeline, other tools are isolated capabilities. Notable gaps exist for a cohesive utility suite—no reverse geocoding, timezone conversion, or image manipulation beyond generation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
A Model Context Protocol server for Wix AI tools
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JunWoo0406/my-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server