注：このプロジェクトは実験的なもので、モデルコンテキストプロトコル（MCP）をNylas API統合のガイドとして使用する方法を探ることを目的としています。公式のものではありませんので、学習および実験目的でのみご利用ください。
このプロジェクトは、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 統合シナリオ向けにあらかじめ構築されたプロンプト
Node.js 18歳以上
npm
このリポジトリをクローンする
依存関係をインストールする
npm installプロジェクトを構築する
npm run buildnpm startMCP_MODE=http npm startデフォルトでは、HTTP サーバーはポート 3000 で実行されます。PORT 環境変数PORT設定することでこれを変更できます。
MCP_MODE=http PORT=8080 npm startMCPサーバーをstdioモードで起動します
Claudeデスクトップで、「設定」>「サーバー」に移動します。
「サーバーを追加」をクリックします
「ローカル コマンドを実行」を選択し、このサーバーを起動するコマンドを入力します。
node /path/to/nylas-api-mcp/dist/index.js名前を付けます（例：「Nylas API」）
追加すると、Claudeの会話でNylas APIのすべてのリソース、ツール、プロンプトを使用できるようになります。
MCPサーバーをstdioモードで起動します
カーソルの設定で新しいMCPサーバーを追加します
次のコマンドを使用するように設定します。
node /path/to/nylas-api-mcp/dist/index.jsこの MCP サーバーは次のリソースを提供します。
一般ドキュメント: Nylas API 機能の概要
認証ガイド: Nylas API で認証する方法
APIエンドポイント: メール、カレンダー、連絡先、Webhookエンドポイントのドキュメント
コードサンプル: 複数のプログラミング言語での使用例
コード生成のためのインタラクティブ ツール:
generate-auth-code : 希望の言語で認証コードを生成します
generate-endpoint-code : 特定のAPIエンドポイントのコードを生成する
search-api-docs : Nylas APIドキュメントを検索する
一般的なシナリオ向けにあらかじめ構築されたプロンプト:
はじめに: Nylas API の基本入門
認証ガイド: OAuthフローを理解する
メール/カレンダー/連絡先の統合: 機能固有のガイダンス
統合シナリオ: 特定のユースケースのガイダンス (電子メール クライアント、カレンダーの予約など)
SDK の例: さまざまな言語のサンプルコード
デバッグガイド: よくある問題と解決策
貢献を歓迎します！以下の方法で貢献できます:
nylas-code-samplesディレクトリにコードサンプルを追加します
ドキュメントリソースの改善
追加のプログラミング言語のサポートを追加する
新しいツールとプロンプトを作成する
これは実験的なプロジェクトであり、Nylas による公式サポートは提供されていません。この MCP サーバーを通じて提供される情報とコードは、学習リソースとしてのみご利用ください。Nylas API に関する正確かつ最新の情報については、必ず公式の Nylas ドキュメントを参照してください。
提供されるサンプル コードは教育目的であり、実稼働環境で使用する前に追加のエラー処理、セキュリティ上の考慮事項、およびテストが必要になる場合があります。
マサチューセッツ工科大学
| 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
