참고 : 이 프로젝트는 실험적이며, Nylas API 통합을 위한 가이드로 모델 컨텍스트 프로토콜(MCP)을 활용하는 방법을 탐구하기 위한 것입니다. 공식적인 자료가 아니며 학습 및 실험 목적으로만 사용해야 합니다.
이 프로젝트는 Nylas API용 모델 컨텍스트 프로토콜(MCP) 서버를 구현합니다. 개발자가 Nylas API를 사용하여 이메일, 캘린더, 연락처 기능을 익히고 통합할 수 있도록 리소스, 도구, 프롬프트를 제공합니다.
모델 컨텍스트 프로토콜(MCP)은 데이터, 도구 및 프롬프트를 AI 애플리케이션과 통합하기 위한 표준입니다. MCP 서버는 Claude Desktop , Cursor 및 기타 MCP 호환 애플리케이션과 같은 AI 애플리케이션에 리소스, 도구 및 프롬프트를 노출할 수 있습니다.
Related MCP server: NetlifyMCPServer
이 MCP 서버는 다음을 제공합니다.
문서 리소스 : Nylas API 엔드포인트, 인증 및 모범 사례에 대한 포괄적인 문서
코드 샘플 : 여러 언어(Node.js, Python, Java, Ruby, curl)로 다양한 Nylas API 작업을 위한 바로 사용 가능한 코드 샘플
대화형 도구 : 인증 코드 및 엔드포인트별 구현 코드를 생성하는 도구
프롬프트 : 일반적인 Nylas 통합 시나리오를 위한 미리 작성된 프롬프트
노드.js 18+
엔피엠
이 저장소를 복제하세요
종속성 설치
지엑스피1
프로젝트를 빌드하세요
npm run buildnpm startMCP_MODE=http npm start기본적으로 HTTP 서버는 포트 3000에서 실행됩니다. PORT 환경 변수를 설정하여 이를 변경할 수 있습니다.
MCP_MODE=http PORT=8080 npm startstdio 모드에서 MCP 서버를 시작합니다.
Claude Desktop에서 설정 > 서버로 이동합니다.
"서버 추가"를 클릭하세요
"로컬 명령 실행"을 선택하고 다음 명령을 입력하여 이 서버를 시작합니다.
node /path/to/nylas-api-mcp/dist/index.js이름을 지정합니다(예: "Nylas API")
추가 후 Claude 대화에서 모든 Nylas API 리소스, 도구 및 프롬프트를 사용할 수 있습니다.
stdio 모드에서 MCP 서버를 시작합니다.
커서에서 설정에 새 MCP 서버를 추가합니다.
다음 명령을 사용하도록 구성하세요.
node /path/to/nylas-api-mcp/dist/index.js이 MCP 서버는 다음과 같은 리소스를 제공합니다.
일반 문서 : Nylas API 기능 개요
인증 가이드 : Nylas API를 사용하여 인증하는 방법
API 엔드포인트 : 이메일, 캘린더, 연락처 및 웹훅 엔드포인트에 대한 설명서
코드 샘플 : 여러 프로그래밍 언어에서의 사용 예
코드 생성을 위한 대화형 도구:
generate-auth-code : 선호하는 언어로 인증 코드를 생성합니다.
generate-endpoint-code : 특정 API 엔드포인트에 대한 코드를 생성합니다.
search-api-docs : Nylas API 문서 검색
일반적인 시나리오에 대한 미리 작성된 프롬프트:
시작하기 : Nylas API 기본 소개
인증 가이드 : OAuth 흐름 이해
이메일/캘린더/연락처 통합 : 기능별 안내
통합 시나리오 : 특정 사용 사례(이메일 클라이언트, 일정 예약 등)에 대한 지침
SDK 예제 : 다양한 언어로 된 예제 코드
디버깅 가이드 : 일반적인 문제 및 해결 방법
여러분의 참여를 환영합니다! 다음과 같은 활동을 할 수 있습니다.
nylas-code-samples 디렉토리에 더 많은 코드 샘플을 추가합니다.
문서 리소스 개선
추가 프로그래밍 언어에 대한 지원 추가
새로운 도구와 프롬프트 만들기
이 프로젝트는 실험적이며 Nylas의 공식 지원을 받지 않습니다. 이 MCP 서버를 통해 제공되는 정보와 코드는 학습 자료로만 사용해야 합니다. Nylas API에 대한 가장 정확하고 최신 정보는 항상 공식 Nylas 문서를 참조하십시오.
제공된 샘플 코드는 교육 목적으로 제공되며, 실제 운영 환경에서 사용하기 전에 추가적인 오류 처리, 보안 고려 사항 및 테스트가 필요할 수 있습니다.
MIT
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | ||
| clientId | No | ||
| clientSecret | No | ||
| redirectUri | No | ||
| scopes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| language | Yes | ||
| endpoint | Yes | ||
| method | No | ||
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
| query | Yes | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
generate-auth-codegenerate-endpoint-codesearch-api-docsThe tools have overlapping purposes that could cause confusion. 'generate-auth-code' and 'generate-endpoint-code' both involve code generation for different parts of the Nylas API, but without descriptions, their specific boundaries are unclear. 'search-api-docs' is more distinct but still part of the same API exploration domain.
The naming follows a consistent verb-object pattern with hyphens (e.g., generate-auth-code, search-api-docs), which is predictable and readable. There are no deviations in style across the three tools, though the pattern is simple and lacks more sophisticated conventions.
With only 3 tools, the server feels thin for an API-focused purpose like the Nylas API, which typically involves multiple operations such as CRUD for emails, calendars, or contacts. This limited set suggests significant gaps in coverage for the apparent domain.
The tool surface is severely incomplete for an API server. There are no tools for core API operations like sending emails, managing events, or accessing user data, which are essential for the Nylas API domain. The existing tools only cover authentication, endpoint code generation, and documentation search, leaving major gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
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
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nylas-samples/nylas-api-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
