MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.6/5 across 15 of 15 tools scored.
Each tool targets a distinct resource and action: create vs list vs get for specific entities like draft, event, calendar, contact, grant, message, folder. There is no overlap, as even similar verbs like 'list' are paired with unique nouns. Agents can easily select the correct tool.
All tool names follow a uniform 'nylas_verb_noun' pattern using snake_case, with clear and predictable verbs (create, get, list, send) and nouns (draft, event, calendar, etc.). The naming is fully consistent across all 15 tools.
With 15 tools, the set is well-scoped for a Nylas integration covering email, calendar, and contacts. Each tool serves a clear purpose without redundancy, and the count falls comfortably within the ideal range of 3-15 tools.
The tool set covers reading and limited creation (drafts, events) but lacks update and delete operations for all entities, as well as create for contacts. This leaves notable gaps for full lifecycle management, though core workflows like listing and fetching are present.
nylas_create_draftCreate a draft emailBCreates a draft email (does NOT send — safe/additive). Nylas v3: POST /v3/grants/{grant_id}/drafts.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC email addresses (array of strings). | |
| to | Yes | Recipient email addresses (array of strings). | |
| bcc | No | BCC email addresses (array of strings). | |
| body | No | Email body (HTML or plain text). | |
| subject | No | Email subject line. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description contradicts annotations: annotations set destructiveHint=true, but description claims it's 'safe/additive'. This is a serious inconsistency that misleads the agent about the tool's behavior.
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?
Two concise sentences, no fluff. Front-loaded with the essential purpose and safety note.
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?
No output schema, and the description does not explain return values, error handling, or post-creation behavior. Contradictory annotation further reduces 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?
Schema covers 100% of parameters with descriptions, so the description adds no additional meaning. Baseline score of 3 is appropriate.
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 verb 'Creates' and resource 'draft email', and explicitly notes it does NOT send, contrasting with the sibling tool 'nylas_send_message'.
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?
Implicitly indicates use for draft creation, not sending, but lacks explicit when-not or alternative tool mention. The 'safe/additive' label provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_create_eventCreate a calendar eventBCreates a calendar event (may send invites to participants). Requires calendar_id (sent as a query param). Nylas v3: POST /v3/grants/{grant_id}/events.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Event title. | |
| end_time | Yes | Event end, Unix timestamp (seconds). | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| location | No | Event location. | |
| start_time | Yes | Event start, Unix timestamp (seconds). | |
| calendar_id | Yes | REQUIRED. The calendar id to create the event in (sent as a query param). | |
| description | No | Event description. | |
| participants | No | Participant email addresses (array of strings). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral info beyond annotations: 'may send invites to participants' and the HTTP method/endpoint. However, destructiveHint already signals mutation; description adds marginal context.
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?
Two sentences, no fluff. First sentence conveys core action, second gives critical requirement and API reference. Very efficient.
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 8 parameters and no output schema. Description lacks return value information and more detailed side effects. Adequate but not fully comprehensive.
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% with descriptions for each parameter. The description reiterates 'calendar_id (sent as a query param)' but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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?
Clearly states 'creates a calendar event' which is a specific verb+resource. Mentions side effect (may send invites). Does not explicitly differentiate from siblings like nylas_create_draft, but purpose is unambiguous.
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?
No guidance on when to use this tool versus alternatives. While it notes a requirement (calendar_id as query param), it does not provide context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_get_calendarGet a calendarAGet a single calendar by id. Nylas v3: GET /v3/grants/{grant_id}/calendars/{calendar_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| calendar_id | Yes | The calendar id to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's behavioral disclosure is minimal. The API endpoint is provided but adds no new behavioral insight. No contradiction with annotations.
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?
Two sentences, no wasted words. The description is front-loaded with the main action and includes the API endpoint for reference. Every sentence earns its place.
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 annotations covering readOnly and schema covering parameters, the description is complete for a simple get operation. No output schema is needed for this basic fetch.
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%, so parameters are well-documented in the schema. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
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 'Get a single calendar by id,' specifying the verb and resource. It includes the API endpoint, which reinforces the action. This distinguishes it from sibling tools like nylas_list_calendars.
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 for fetching a single calendar, but does not explicitly state when to use vs alternatives. The sibling tool nylas_list_calendars provides contrast, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_get_contactGet a contactAGet a single contact by id. Nylas v3: GET /v3/grants/{grant_id}/contacts/{contact_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| contact_id | Yes | The contact id to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's addition of the HTTP endpoint provides minimal extra behavioral context. No other behavioral traits (e.g., rate limits, authentication) are disclosed.
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 very concise with two sentences, no wasted words. It is front-loaded with the core 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?
For a simple get-by-id tool with low complexity and no output schema, the description is adequately complete. It includes the HTTP endpoint but does not describe the return value, which is a minor gap.
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% with both parameters well-described. The description does not add meaning beyond the schema, so baseline score of 3 is appropriate.
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 'Get a single contact by id', using a specific verb and resource. It distinguishes from sibling tools like nylas_list_contacts (which lists contacts) and nylas_get_message (different resource).
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions or when not to use it, nor does it reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_get_eventGet an eventAGet a single calendar event by id. Requires calendar_id (sent as a query param). Nylas v3: GET /v3/grants/{grant_id}/events/{event_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | The event id to fetch. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| calendar_id | Yes | REQUIRED. The calendar id (sent as a query param). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that calendar_id is a query param and provides the underlying API endpoint, which gives some behavioral insight. However, it does not mention return structure or error handling, which would be helpful.
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?
Two sentences, no fluff. The first sentence states the core purpose, the second adds a requirement and API path. Every sentence adds value.
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?
For a simple getter with no output schema, the description is adequate but could be more complete. It does not describe the response shape or potential errors, which would help an agent use the tool correctly.
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% (all parameters have descriptions). The description reinforces the required calendar_id but adds no new meaning beyond what the schema already provides.
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 states 'Get a single calendar event by id' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like nylas_list_events (lists events) and nylas_create_event (creates events).
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 mentions 'Requires calendar_id (sent as a query param)', providing a key requirement. While it doesn't explicitly exclude alternatives, the purpose is clear enough for an agent to decide when to use it over list or create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_get_grantGet a grantAGet details for a single connected account (grant). Nylas v3: GET /v3/grants/{grant_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds no further behavioral traits (e.g., error handling, permissions). For a read operation, the disclosure is minimal beyond structured fields.
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?
Two efficient sentences: first states purpose, second provides API endpoint and parameter note. No wasted words, front-loaded with key information.
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 a simple get tool with no output schema and read-only annotations. However, lacks details about return value structure or error cases, which could be helpful given no output schema.
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 description adds value beyond the schema by noting that grant_id overrides NYLAS_GRANT_ID, providing context about environment variable defaults. This is informative for the agent.
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 verb ('Get') and resource ('details for a single connected account (grant)'), distinguishing it from sibling tools like nylas_list_grants. The API endpoint is referenced for precision.
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?
No guidance on when to use this tool versus alternatives (e.g., nylas_list_grants). The description only mentions parameter override behavior, not contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_get_messageGet a messageAGet a single email message by id. Nylas v3: GET /v3/grants/{grant_id}/messages/{message_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| message_id | Yes | The message id to fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's disclosure of the API endpoint adds context but does not significantly extend beyond that. The description does not detail behavioral aspects like authentication requirements or error scenarios, but with annotations present, the burden is reduced.
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 extremely concise with two sentences, no redundant words, and front-loads the core purpose. Every sentence adds necessary context.
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?
The description does not explain the return value (no output schema) but given the tool's simplicity and read-only nature, it is minimally adequate. More detail on expected response format would improve 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?
Both parameters are fully described in the schema (100% coverage). The description's mention of the endpoint path hints at the role of grant_id but adds no new semantic meaning beyond the existing schema descriptions.
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 retrieves a single email message by ID, specifying the verb 'Get' and resource 'single email message'. It distinguishes from sibling tools like nylas_list_messages (list) and nylas_send_message (send) by focusing on a single message retrieval.
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 when an email ID is known but provides no explicit guidance on when to use this tool versus alternatives like nylas_list_messages or nylas_get_contact. No conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_calendarsList calendarsAList calendars for the connected account (each has a calendar_id used by the events tools). Nylas v3: GET /v3/grants/{grant_id}/calendars.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max calendars to return. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| page_token | No | Pagination cursor (next_cursor from a prior page). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds the API endpoint and contextual note about calendar_id, which is useful but not required. No additional behavioral traits (e.g., pagination behavior) beyond schema.
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?
Two sentences, front-loaded with purpose, zero waste. Every sentence adds value.
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 no output schema, description provides adequate context for a list tool with fully described parameters. Could mention return structure (e.g., calendar objects with id/name) but not necessary for selection.
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%, so baseline is 3. Description does not add extra meaning beyond what the schema provides for the parameters. It mentions calendar_id context but not as a parameter.
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?
Specific verb 'List', resource 'calendars', and scope 'for the connected account'. Clearly distinguishes from sibling tools like nylas_list_events or nylas_get_calendar by focusing on calendars and noting the calendar_id is used by events tools.
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?
States the purpose and links to events tools (calendar_id). Provides clear context for when to use, but does not explicitly state when not to use or name alternatives like nylas_get_calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_contactsList contactsAList contacts for the connected account, with optional email/phone filters. Nylas v3: GET /v3/grants/{grant_id}/contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Filter by email address. | ||
| limit | No | Max contacts to return. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| page_token | No | Pagination cursor (next_cursor from a prior page). | |
| phone_number | No | Filter by phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds the endpoint path and filter options but does not disclose pagination behavior or rate limits beyond what the schema provides.
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?
Two sentences, front-loaded with purpose and key features, followed by technical reference. No wasted words.
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?
For a list tool with well-described schema and clear read-only annotation, the description is adequate. It does not explain pagination details but the schema covers page_token. Overall complete enough.
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% with detailed parameter descriptions. The description summarizes email/phone filters but adds no new meaning beyond the schema, so baseline 3 is appropriate.
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 lists contacts for a connected account with optional filters, distinguishing it from single-contact retrieval (nylas_get_contact) and other list endpoints.
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 for retrieving a list of contacts but lacks explicit guidance on when to use this tool versus alternatives like nylas_get_contact or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_draftsList draftsBList draft emails for the connected account. Nylas v3: GET /v3/grants/{grant_id}/drafts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max drafts to return. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| page_token | No | Pagination cursor (next_cursor from a prior page). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only repeats the endpoint and does not add behavioral context beyond the readOnlyHint annotation, such as pagination behavior, ordering, or what happens with large result sets.
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 extremely concise (two sentences) with no wasted words, stating purpose first and then the API endpoint.
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 simple list operation, annotations, and schema covering parameters, the description is minimally adequate but lacks context about return format or pagination handling.
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% and parameter descriptions are adequate in the schema; the tool description does not add extra meaning for parameters like limit or page_token.
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 action (list) and resource (draft emails), and distinguishes from siblings like nylas_create_draft or nylas_list_messages by specifying 'drafts'.
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?
No guidance on when to use this tool versus alternatives, such as nylas_list_messages for other email types, or when pagination is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_eventsList eventsBList calendar events. Requires calendar_id (sent as a query param). Nylas v3: GET /v3/grants/{grant_id}/events.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Filter: latest event start, Unix timestamp (seconds). | |
| limit | No | Max events to return. | |
| start | No | Filter: earliest event start, Unix timestamp (seconds). | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| page_token | No | Pagination cursor (next_cursor from a prior page). | |
| calendar_id | Yes | REQUIRED. The calendar id (sent as a query param). | |
| show_cancelled | No | Include cancelled events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds the API endpoint but does not disclose pagination behavior, rate limits, or what happens with large date ranges. Minimal added value beyond annotations.
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?
Two short sentences with front-loaded purpose. No wasted words. Efficiently conveys the core action and a key constraint.
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 complexity (7 parameters, no output schema), the description omits details about the returned data structure, pagination, and default behavior. An agent operating without additional context may not know how to interpret results.
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%, so the description's mention of calendar_id adds nothing beyond what the schema already provides. Baseline 3 applies.
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?
Clearly states 'List calendar events' with specific resource and verb. The API endpoint reference adds context. Distinguishes from sibling tools like create, get, and other list operations.
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?
No guidance on when to use this tool versus alternatives (e.g., nylas_get_event for a single event). No mention of when not to use it or prerequisites beyond the required calendar_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_foldersList foldersBList mail folders/labels for the connected account. Nylas v3: GET /v3/grants/{grant_id}/folders.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max folders to return. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be non-destructive. The description adds no further behavioral traits (e.g., pagination, rate limits, scope of folders). It only restates the endpoint, which is not a behavioral detail.
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 one sentence plus an endpoint reference, which is concise and front-loaded. However, the endpoint line adds little for agent decision-making and could be considered extraneous.
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?
For a simple list tool with two optional parameters and no output schema, the description is minimally adequate. It omits details about the returned folder objects (e.g., fields), which an agent might infer but is not explicitly provided.
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% (both parameters have descriptions in the schema). The tool description does not add additional meaning beyond the schema; it merely rephrases the context. Baseline 3 is appropriate.
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 states the tool lists mail folders/labels for the connected account, with a specific verb and resource. It distinguishes from sibling list tools (e.g., list_messages) by the resource type, though it does not explicitly contrast them.
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 like list_messages or list_drafts, nor mentions any prerequisites or context for opting for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_grantsList grants (connected accounts)AList the connected accounts (grants) on this Nylas application, each with a grant_id used to scope other tools. Not grant-scoped. Nylas v3: GET /v3/grants.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max grants to return. | |
| offset | No | Pagination offset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description adds limited new behavioral info. The 'Not grant-scoped' note provides some operational context beyond annotations, but no additional disclosure about pagination or other behaviors.
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?
Three sentences: first states core purpose, second adds context, third provides technical reference. No redundant information. Front-loaded and efficient.
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 a simple list tool with detailed schema. Lacks description of return format (e.g., list of grant objects with fields), but schema and annotations compensate partially. The technical note is extra but not essential.
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%, and both parameters are described in the schema. The description does not add any new meaning beyond what the schema provides, so baseline score applies.
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?
Clearly states it lists connected accounts (grants) and explicitly links each grant to a grant_id used for scoping other tools. Distinguishes from sibling tools by describing this purpose.
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?
Specifies that the tool is not grant-scoped, implying it's a top-level list operation. Provides context that grant IDs from this list are used to scope other tools, guiding when to use it. However, does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_list_messagesList messagesAList email messages for the connected account, with optional filters. Nylas v3: GET /v3/grants/{grant_id}/messages.
| Name | Required | Description | Default |
|---|---|---|---|
| in | No | Filter by folder id. | |
| to | No | Filter by recipient email address. | |
| from | No | Filter by sender email address. | |
| limit | No | Max messages to return. | |
| unread | No | If set, filter by unread status. | |
| starred | No | If set, filter by starred status. | |
| subject | No | Filter by subject. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| page_token | No | Pagination cursor (next_cursor from a prior page). | |
| search_query_native | No | Provider-native search query string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. Description adds endpoint info but no behavioral details like pagination or rate limits beyond what the schema provides.
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?
Two sentences, front-loaded with purpose, no wasted words.
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 a listing tool with many filters, but lacks explanation of pagination behavior or response structure. No output schema, so a bit more context would help.
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% with clear descriptions for all 10 parameters. The tool description adds no additional meaning over 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?
Clearly states 'List email messages' with verb and resource, and distinguishes from siblings like nylas_get_message and nylas_list_drafts via context.
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?
Implies usage for listing messages with optional filters, but no explicit guidance on when not to use or alternatives like search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nylas_send_messageSend an emailASENDS a real email via the connected account. This dispatches an actual message. Nylas v3: POST /v3/grants/{grant_id}/messages/send.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC email addresses (array of strings). | |
| to | Yes | Recipient email addresses (array of strings). | |
| bcc | No | BCC email addresses (array of strings). | |
| body | No | Email body (HTML or plain text). | |
| subject | No | Email subject line. | |
| grant_id | No | Connected-account grant id. Overrides NYLAS_GRANT_ID for this call. | |
| reply_to_message_id | No | Id of the message this is a reply to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature of sending an email, matching the destructiveHint annotation. However, it does not disclose additional behaviors such as rate limits, authorization details beyond grant_id, or what happens on failure.
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 concise with one functional sentence and the API endpoint reference. Every part is relevant, but the API path could be considered technical noise.
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?
For a tool with 7 parameters and no output schema, the description lacks information about return values, side effects (e.g., saved sent message), or behavior of reply_to_message_id, making it incomplete for full understanding.
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 baseline is 3. The tool description adds no extra meaning beyond the schema's parameter descriptions.
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 'SENDS a real email via the connected account' using a specific verb and resource, and distinguishes from sibling tools like nylas_create_draft by emphasizing actual dispatch.
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 use for sending emails but lacks explicit guidance on when to use this tool versus creating a draft or alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
