注意：本项目为实验性质，旨在探索如何使用模型上下文协议 (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环境变量来更改此设置：
MCP_MODE=http PORT=8080 npm start以 stdio 模式启动 MCP 服务器
在 Claude Desktop 中，转到“设置”>“服务器”
点击“添加服务器”
选择“运行本地命令”，输入启动此服务器的命令：
node /path/to/nylas-api-mcp/dist/index.js给它起一个名字（例如，“Nylas API”）
添加后，您可以在 Claude 对话中使用所有 Nylas API 资源、工具和提示
以 stdio 模式启动 MCP 服务器
在 Cursor 的设置中添加新的 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 官方文档，以获取有关 Nylas API 的最准确和最新的信息。
提供的示例代码仅用于教育目的，在用于生产环境之前可能需要额外的错误处理、安全考虑和测试。
麻省理工学院
| 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
