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 calculate 15 times 42"
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 |
|---|---|---|---|
| left | Yes | 첫 번째 숫자 | |
| operator | Yes | 연산자 (+, -, *, /) | |
| right | Yes | 두 번째 숫자 |
| Name | Required | Description |
|---|---|---|
| result | Yes | 계산 결과값 |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full disclosure burden. It states that the tool returns calculation results, implying a pure function. However, it omits critical behavioral details like division-by-zero handling, numeric precision, or whether the operation is read-only (though implied by 'returns').
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?
Single sentence, zero waste. Front-loaded with inputs (두 숫자와 연산자), operation type (사칭연산), and output (반환합니다). Every element earns its place with no redundancies.
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 simplicity (3 primitive parameters, 100% schema coverage) and presence of an output schema, the description provides sufficient context. It adequately covers the happy path behavior, though it could mention edge cases like division by zero for full completeness.
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 has 100% description coverage (baseline 3). The description adds value by explicitly listing the operator symbols (+,-,*,/) in prose, reinforcing the enum constraints and providing a complete summary of required inputs (two numbers and an operator) even though the schema documents individual fields.
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 four arithmetic operations (사칭연산) on two numbers using an operator, specifying the exact supported operators (+,-,*,/). It clearly distinguishes from siblings like generate-image, 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?
The description implies usage through functional definition (use for arithmetic calculations), but lacks explicit when-to-use guidance or exclusions. Given siblings are unrelated (weather, images, etc.), the context is clear, but no explicit alternatives or limitations are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HuggingFace Inference API를 사용해 텍스트 프롬프트로 이미지를 생성합니다. (모델: black-forest-labs/FLUX.1-schnell, 환경변수 HF_TOKEN 필요)
| 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 provided, so description carries full burden. It discloses the external API dependency, specific model version, and authentication requirement. However, it omits behavioral traits like output format (base64, URL, or binary?), inference latency expectations, rate limits, or content policy restrictions that would help an agent handle the response appropriately.
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?
Single efficient sentence containing the action, method, and parenthetical technical details (model, auth). No redundant words or wasted space; information density is high with critical details front-loaded.
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?
With no output schema provided, the description should ideally indicate what the tool returns (image data format, URL, etc.). While it covers the input parameters adequately and mentions authentication, the absence of return value documentation leaves a significant gap for an agent attempting to process the result.
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 baseline 3. The description mentions '텍스트 프롬프트' (text prompt) which aligns with the required parameter, but adds no additional semantic meaning, examples, or format guidance beyond what the schema already provides for 'prompt' and 'num_inference_steps'.
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?
Description clearly states the tool generates images using text prompts via HuggingFace Inference API. Specific model (FLUX.1-schnell) is named, and the action (생성합니다/generates) is precise. Distinct from siblings (calc, geocode, weather, etc.) which operate on entirely 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?
Explicitly states the authentication requirement (HF_TOKEN environment variable) which is critical for usage. While it doesn't explicitly state 'when not to use' alternatives, the sibling tools are functionally distinct (math, location, weather), making the appropriate use case self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
도시 이름이나 주소를 입력받아 위도·경도 좌표를 반환합니다. (Nominatim OpenStreetMap API 사용)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 도시 이름 또는 주소 | |
| limit | No | 최대 결과 수 (기본값: 5, 최대: 10) | |
| countrycodes | No | 국가 코드 필터 (ISO 3166-1 alpha-2, 예: "kr,us") |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It successfully identifies the external API dependency (Nominatim OpenStreetMap), signaling network usage, potential rate limits, and data source attribution requirements. However, it omits explicit mention of blocking behavior, error handling when locations are not found, or rate limit specifics.
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 the API attribution parenthetically appended. Every element earns its place: the input types, the output format, and the service provider. No redundancy or verbosity.
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 presence of an output schema (not shown but indicated in context signals), the description appropriately omits return value details. With 100% parameter coverage in the schema and clear API identification in the description, it is complete for the tool's complexity level, though it could briefly mention error scenarios for perfection.
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?
With 100% schema description coverage, the schema already comprehensively documents all three parameters including type constraints and examples (e.g., ISO 3166-1 alpha-2 format for countrycodes). The description mentions '도시 이름이나 주소' aligning with the query parameter but does not add semantic value beyond the schema definitions, warranting the baseline score.
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 (반환합니다/returns), input types (도시 이름이나 주소/city names or addresses), and output (위도·경도 좌표/latitude-longitude coordinates). It includes the underlying API provider (Nominatim OpenStreetMap), distinguishing it from unrelated siblings like calc, generate-image, and get-weather.
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 context through input/output specification but lacks explicit guidance on when to use this tool versus alternatives, or prerequisites like network availability. Given the siblings are completely unrelated (calc, greet, time), the absence of explicit differentiation is mitigated but still present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
위도·경도와 예보 기간을 입력받아 현재 날씨와 일별 예보를 반환합니다. (Open-Meteo API 사용, API 키 불필요)
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | 위도 (WGS84, -90 ~ 90) | |
| longitude | Yes | 경도 (WGS84, -180 ~ 180) | |
| forecast_days | No | 예보 기간 (일 수, 기본값: 7, 최대: 16) | |
| temperature_unit | No | 온도 단위 (기본값: celsius) | celsius |
| Name | Required | Description |
|---|---|---|
| daily | Yes | |
| content | Yes | |
| current | 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 external API dependency (Open-Meteo) and authentication behavior (API key unnecessary), but omits other behavioral traits like rate limits, timeout behavior, or data freshness/caching policies.
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?
Extremely efficient single-sentence structure with high-density parenthetical addition. Every element earns its place: the main clause covers inputs/outputs, and the parenthetical covers critical behavioral context (API source and auth requirements) without clutter.
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?
Appropriate completeness given the tool's moderate complexity, 100% schema coverage, and existing output schema. The description covers the essential contract (inputs/outputs) and key operational note (no API key). Minor gap: does not explicitly declare read-only/safe nature absent 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?
Schema description coverage is 100%, providing detailed constraints (WGS84 ranges, defaults, enums) for all 4 parameters. The description mentions latitude, longitude, and forecast period conceptually but adds no semantic details beyond what the schema already provides, earning the baseline score.
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 (returns current weather and daily forecast) and required inputs (latitude, longitude, forecast period). However, it does not explicitly distinguish from siblings like 'geocode' (which complements this tool by converting addresses to coordinates), though the domains are distinct.
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 useful context that the tool uses Open-Meteo API and requires no API key, which helps agents decide when to use it (free, accessible). However, it lacks explicit guidance on when NOT to use it (e.g., 'do not use for historical weather') or prerequisites (e.g., 'requires coordinates, not city names').
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?
No annotations are provided, so the description carries the full burden. It correctly discloses that the tool returns a greeting (output behavior), but omits details on localization defaults, determinism, or whether external translation services are invoked.
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?
Single sentence with zero redundancy. Immediately conveys inputs and outputs without filler words. Appropriate length for a two-parameter utility function.
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?
Adequate for the tool's simplicity. With a documented output schema (per context signals) and complete input parameter coverage, the description successfully covers the essential contract without needing to elaborate on return value structure.
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?
With 100% schema description coverage (both name and language parameters have complete descriptions and enums), the schema already documents semantics. The description merely lists the parameters ('이름과 언어') without adding syntax constraints, examples, or validation rules beyond the schema.
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 Korean description '이름과 언어를 입력하면 인사말을 반환합니다' clearly states the tool takes a name and language and returns a greeting. This functionally distinguishes it from siblings like calc, generate-image, and geocode, though it does not explicitly mention sibling alternatives.
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?
Provides only functional description ('input X, get Y') with no guidance on when this greeting tool should be preferred over simple string manipulation or which specific greeting format is returned.
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 |
|---|---|---|
| unixMs | Yes | Unix epoch milliseconds |
| content | Yes | |
| isoTime | Yes | ISO 8601 형식 현재 시간 |
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 states that it returns 'time' but fails to specify the format (ISO 8601, Unix timestamp, human-readable string) or timezone handling (UTC, local, server time), which are critical for an agent to use the result correctly.
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 front-loads the core functionality. There is no wasted text or redundancy appropriate to the tool's simplicity.
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 has zero input parameters and an output schema exists (per context signals), the description appropriately does not need to detail return values. However, with no annotations covering behavioral traits, the description could be more complete by mentioning timezone or format specifics.
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 accepts zero parameters. Per the scoring rubric, zero parameters warrants a baseline score of 4. The schema coverage is 100% (of zero properties), so there are no semantic gaps to fill.
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 uses a specific verb (반환합니다/returns) and resource (시간/time), clearly stating the tool fetches the current time. It distinguishes clearly from siblings like calc, generate-image, and geocode 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. While the purpose is simple, there is no explicit mention of use cases (e.g., when to prefer this over calc for timestamp calculations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0calcgenerate-imagegeocodeget-weathergreettimeEach tool serves a completely distinct purpose (arithmetic, image generation, geocoding, weather, greetings, time). There is no functional overlap between tools, making selection unambiguous.
Mixed conventions: 'generate-image' and 'get-weather' use kebab-case verb-noun patterns, while 'calc', 'geocode', 'greet', and 'time' use single lowercase words (with 'time' being a noun rather than a verb). Readable but inconsistent structure.
Six tools is reasonable for a boilerplate/demo server intended to showcase different integration patterns (HuggingFace, OpenStreetMap, Open-Meteo, simple functions). Not overwhelming, though the selection feels somewhat arbitrary.
No coherent domain unifies the tools; they appear to be random unrelated examples. While geocode+get-weather form a minimal workflow, the set lacks completeness for any specific purpose (weather, math, image gen, etc.) and appears as a disconnected grab bag of capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
The official MCP Server for the Mux API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bakcoder/my-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
