Skip to main content
Glama
KALYN100

my-mcp-server

by KALYN100
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

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 install

2. 서버 이름 설정

src/index.ts 파일에서 서버 이름을 수정하세요:

const server = new McpServer({
    name: 'typescript-mcp-server', // 여기를 원하는 서버 이름으로 변경
    version: '1.0.0',
    // 활성화 하고자 하는 기능 설정
    capabilities: {
        tools: {},
        resources: {}
    }
})

💡 팁: 현재 보일러플레이트에는 이미 계산기와 인사 도구, 그리고 서버 정보 리소스가 예시로 구현되어 있습니다.

3. 빌드

npm run build

4. 실행

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

6 tools
calculatorB

두 숫자에 사칙연산을 수행하고 결과를 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
operatorYes수행할 연산자 (+, -, *, /)
firstNumberYes첫 번째 숫자
secondNumberYes두 번째 숫자

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes계산 결과

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 must disclose behavioral traits. It only states it performs arithmetic and returns result, omitting edge cases (e.g., division by zero, floating-point precision), side effects (none), or permissions needed. Fails to adequately describe behavior beyond the bare operation.

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 concise sentence that is front-loaded and easy to parse. However, it omits important behavioral details, slightly reducing its overall utility while remaining efficient.

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 low complexity and presence of output schema, the description is minimally adequate but does not mention return format, statelessness, or safety. For a tool with no annotations, more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions and an enum for operator. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs arithmetic operations on two numbers and returns the result, which is a specific verb-resource pair. It distinguishes from sibling tools that are unrelated to arithmetic.

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

Usage Guidelines3/5

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

The description implies use for basic arithmetic, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions (e.g., division by zero). No context about prerequisites or limitations.

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

generate-imageA

텍스트 프롬프트를 이미지로 생성합니다. Hugging Face Inference (nscale)의 FLUX.1-schnell을 기본으로 사용합니다. HF_TOKEN 환경 변수가 필요합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNo재현 가능한 결과를 위한 시드 값
modelNo사용할 Hugging Face 모델 ID (기본값: black-forest-labs/FLUX.1-schnell)black-forest-labs/FLUX.1-schnell
stepsNo추론 스텝 수 (1~8, 기본값: 4)
widthNo이미지 가로 크기 (256~1536, 기본값: 1024)
heightNo이미지 세로 크기 (256~1536, 기본값: 1024)
promptYes이미지를 생성할 텍스트 프롬프트

Output Schema

ParametersJSON Schema
NameRequiredDescription
modelYes사용한 모델 ID
promptYes입력 프롬프트
mimeTypeYes이미지 MIME 타입
sizeBytesYes이미지 바이트 크기

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the use of an external Hugging Face inference service and the token requirement, but does not detail aspects like rate limits, timeout, or synchronous/asynchronous 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 only two sentences, front-loading the core purpose and adding essential context (model and token requirement). No superfluous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the comprehensive schema and output schema, the description adequately covers the main non-schema details (environment variable). Minor omissions like network dependency are acceptable.

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% coverage with descriptions for all parameters. The description adds minimal extra information (default model and token requirement), not enhancing parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool generates images from text prompts using Hugging Face Inference with a default model. It distinguishes well from sibling tools like greet, calculator, etc., 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 Guidelines4/5

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

It mentions the need for the HF_TOKEN environment variable, which is a prerequisite. However, it doesn't explicitly state when to use this tool versus alternatives, but given sibling tools are unrelated, the context is sufficient.

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

geocodeA

도시 이름을 검색해 위도와 경도 좌표를 반환합니다. 동명 도시가 있으면 여러 후보를 함께 보여줍니다. 데이터 출처: Open-Meteo (CC BY 4.0).

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYes검색할 도시 이름 또는 우편번호
countNo반환할 후보 개수 (1~10, 기본값: 5)
languageNo결과 언어 코드 (기본값: ko)ko

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultsYes검색된 도시 후보 목록

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It reveals that multiple candidates may be returned for ambiguous city names and cites the data source (Open-Meteo CC BY 4.0). However, it does not mention error handling (e.g., if the city is not found), rate limits, or idempotency, which would be valuable for an agent.

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, consisting of two short sentences. Front-loaded with the core purpose in the first sentence, the second adds essential nuance about multiple candidates and data source. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (3 parameters, all documented, output schema exists), the description is sufficiently complete. It covers the main functionality, edge cases (same-name cities), and data provenance. The existence of an output schema means detailed return value documentation is not required in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already documents all parameters. The description adds context only for the 'city' parameter (it is the search input). It does not elaborate on 'count' or 'language' beyond what the schema provides. Thus, the description meets the baseline but adds minimal extra value.

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 function: search for a city name and return latitude/longitude coordinates. It also mentions handling ambiguous city names by showing multiple candidates, which adds specificity. The tool is well-distinguished from its siblings (greet, calculator, etc.), which have unrelated purposes.

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 implicitly tells the agent when to use this tool—when needing coordinates for a city. The sibling tools are unrelated, so no explicit exclusions are necessary. However, it does not provide guidance on when not to use it or mention any prerequisites, which would improve clarity.

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

get-timeA

IANA 타임존을 입력하면 해당 지역의 현재 날짜와 시간을 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
timezoneYes도시가 속한 IANA 타임존 (예: Asia/Seoul, America/New_York)

Output Schema

ParametersJSON Schema
NameRequiredDescription
timezoneYes입력한 IANA 타임존
currentTimeYes해당 타임존의 현재 날짜와 시간

TDQS

A4/5.0
Behavior4/5

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

The description discloses the input (IANA timezone) and output (current date and time) beyond the schema. While no annotations exist, the behavior is simple and adequately explained.

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, concise sentence that front-loads the purpose. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description is mostly complete. It could mention error handling for invalid timezones, but otherwise adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a basic description. The description adds value by specifying the IANA format and providing examples, which clarifies parameter semantics.

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 that the tool returns the current date and time for an IANA timezone, effectively distinguishing it from siblings like get-weather and geocode.

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 to use this tool versus alternatives (e.g., get-weather might also involve time). The description does not mention when not to use it.

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

get-weatherA

위도와 경도 좌표로 해당 지역의 현재 날씨와 일별 예보를 반환합니다. 좌표는 geocode 도구로 먼저 조회할 수 있습니다. 데이터 출처: Open-Meteo (CC BY 4.0).

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYes위도 (-90 ~ 90)
longitudeYes경도 (-180 ~ 180)
forecastDaysNo예보 일수 (1~16, 기본값: 3)

Output Schema

ParametersJSON Schema
NameRequiredDescription
currentYes현재 날씨
forecastYes일별 예보
locationYes날씨를 조회한 지점 정보

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only mentions data source (Open-Meteo) but does not address rate limits, data freshness, authentication, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences efficiently convey the purpose and a related tool. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema and 3 parameters with full schema descriptions, the description adequately covers purpose and data source. Lack of behavioral transparency reduces completeness slightly.

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, so baseline 3 is appropriate. The description does not add additional semantic information beyond what the schema already provides for the forecastDays parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns current weather and daily forecast given latitude and longitude. It distinguishes itself from siblings like geocode by mentioning that coordinates can be looked up with geocode.

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 context that coordinates can be obtained via geocode tool. While it doesn't explicitly list when not to use, the intended use case is clear.

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

greetA

이름과 언어를 입력하면 인사말을 반환합니다.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes인사할 사람의 이름
languageNo인사 언어 (기본값: en)en

Output Schema

ParametersJSON Schema
NameRequiredDescription
contentYes인사말

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It states the core behavior (returns a greeting) but does not disclose details like output formatting, error handling, or whether there are side effects. For a simple tool, this is acceptable but not exceptional.

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, concise sentence that covers the tool's purpose without any extraneous words. It is front-loaded with the core action and efficiently communicates the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with a complete input schema and an output schema, the description is sufficient. It explains the function clearly, and the remaining details are covered by the structured fields, leaving no significant gaps.

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 provides complete descriptions for both parameters (name, language) with enums and defaults. The description merely restates that they are inputs and does not add additional semantic context beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a greeting based on a name and language, using a specific verb (반환합니다) and a clear resource (greeting). This is distinct from sibling tools like geocode or get-weather, making its purpose unambiguous.

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

Usage Guidelines3/5

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

The description implies usage when a greeting is needed, but it does not explicitly state when to use this tool versus alternatives. Since sibling tools are unrelated, no exclusions are necessary, but explicit guidance is absent.

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. 6 tool updatesv1.0.0
    • First observedcalculator
    • First observedgenerate-image
    • First observedgeocode
    • First observedget-time
    • First observedget-weather
    • First observedgreet
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 6 tools

Disambiguation5/5

Each tool addresses a completely different function (greeting, math, time, geocoding, weather, image generation), with no overlapping purposes. An agent will have no trouble selecting the correct tool.

Naming Consistency3/5

Naming patterns are mixed: three tools use verb_noun with 'get-' prefix (get-time, get-weather, generate-image uses 'generate'), while 'calculator' is a noun and 'greet' is a bare verb. 'geocode' is a verb but not prefixed. The inconsistency is confusing but still readable.

Tool Count5/5

With 6 tools covering distinct utilities, the count is appropriate for a general-purpose server. It is neither too sparse nor overloaded.

Completeness4/5

The tools cover basic functionalities in their respective areas, with complementary pairs (geocode + weather). While some missing utilities could be added, there are no critical gaps within the current scope.

Maintenance

ActivitySlowing
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

  • TypeScript MCP Server

    devbrother2024
    F
    license
    Not graded
    quality
    D
    maintenance
    A boilerplate project for quickly developing MCP servers using TypeScript SDK, featuring example tools (calculator, greeting) and resources with Zod schema validation.
    -

  • TypeScript MCP Server

    sj0405-lee
    F
    license
    Not graded
    quality
    D
    maintenance
    A boilerplate project for quickly developing MCP servers using TypeScript, featuring example implementations of tools (calculator, greetings) and resources (server info) with Zod schema validation.
    -

  • TypeScript MCP Server

    you0best
    F
    license
    Not graded
    quality
    D
    maintenance
    A boilerplate project for quickly developing MCP servers using TypeScript SDK, with example implementations of calculator and greeting tools, plus resource handling capabilities.
    -