Nota : Este proyecto es experimental y su propósito es explorar el uso del Protocolo de Contexto de Modelo (MCP) como guía para la integración de la API de Nylas. No es oficial y debe usarse únicamente con fines de aprendizaje y experimentación.
Este proyecto implementa un servidor de Protocolo de Contexto de Modelo (MCP) para la API de Nylas. Proporciona recursos, herramientas y sugerencias para ayudar a los desarrolladores a comprender e integrar la API de Nylas para las funciones de correo electrónico, calendario y contactos.
El Protocolo de Contexto de Modelo (MCP) es un estándar para integrar datos, herramientas e indicaciones con aplicaciones de IA. Los servidores MCP pueden exponer recursos, herramientas e indicaciones a aplicaciones de IA como Claude Desktop , Cursor y otras compatibles con MCP.
Related MCP server: NetlifyMCPServer
Este servidor MCP proporciona:
Recursos de documentación : documentación completa sobre los puntos finales de la API de Nylas, la autenticación y las mejores prácticas
Ejemplos de código : ejemplos de código listos para usar para diversas operaciones de la API de Nylas en varios lenguajes (Node.js, Python, Java, Ruby, curl)
Herramientas interactivas : herramientas para generar código de autenticación y código de implementación específico del punto final
Avisos : Avisos prediseñados para escenarios comunes de integración de Nylas
Node.js 18+
npm
Clonar este repositorio
Instalar dependencias
npm installConstruir el proyecto
npm run buildnpm startMCP_MODE=http npm startDe forma predeterminada, el servidor HTTP se ejecuta en el puerto 3000. Puede cambiar esto configurando la variable de entorno PORT :
MCP_MODE=http PORT=8080 npm startInicie el servidor MCP en modo stdio
En Claude Desktop, vaya a Configuración > Servidores
Haga clic en "Agregar servidor"
Seleccione "Ejecutar un comando local" e ingrese el comando para iniciar este servidor:
node /path/to/nylas-api-mcp/dist/index.jsDale un nombre (por ejemplo, "API de Nylas")
Después de agregar, puedes usar todos los recursos, herramientas y mensajes de la API de Nylas en tus conversaciones de Claude
Inicie el servidor MCP en modo stdio
En Cursor, agregue un nuevo servidor MCP en la configuración
Configúrelo para utilizar el comando:
node /path/to/nylas-api-mcp/dist/index.jsEste servidor MCP proporciona los siguientes recursos:
Documentación general : Descripción general de las capacidades de la API de Nylas
Guía de autenticación : Cómo autenticarse con la API de Nylas
Puntos finales de API : documentación para puntos finales de correo electrónico, calendario, contactos y webhook
Ejemplos de código : ejemplos de uso en varios lenguajes de programación
Herramientas interactivas para la generación de código:
generate-auth-code : genera un código de autenticación en su idioma preferido
generate-endpoint-code : genera código para puntos finales de API específicos
search-api-docs : Busque en la documentación de la API de Nylas
Indicaciones predefinidas para escenarios comunes:
Introducción básica a la API de Nylas
Guía de autenticación : Comprensión del flujo de OAuth
Integración de correo electrónico, calendario y contactos : orientación específica para cada función
Escenarios de integración : orientación para casos de uso específicos (cliente de correo electrónico, reserva de calendario, etc.)
Ejemplos de SDK : código de ejemplo en varios idiomas
Guía de depuración : problemas comunes y soluciones
¡Agradecemos sus contribuciones! Puede:
Agregue más ejemplos de código al directorio nylas-code-samples
Mejorar los recursos de documentación
Añadir soporte para lenguajes de programación adicionales
Crear nuevas herramientas y avisos
Este es un proyecto experimental y Nylas no ofrece soporte oficial. La información y el código proporcionados a través de este servidor MCP deben utilizarse únicamente como recurso de aprendizaje. Consulte siempre la documentación oficial de Nylas para obtener la información más precisa y actualizada sobre la API de Nylas.
El código de muestra proporcionado es para fines educativos y puede requerir manejo de errores adicionales, consideraciones de seguridad y pruebas antes de ser utilizado en entornos de producción.
Instituto Tecnológico de Massachusetts (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
