Skip to main content
Glama

maeil

by io.github.retep-tru

Server Details

Invite someone to a calendar event by phone number and get their real email back when they accept.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Unhealthy
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP
URL

Available Tools

2 tools
get_invite_statusAInspect

Check whether a sent invite has been accepted or declined, and retrieve the recipient's revealed email once they have accepted. Returns one of: sent, accepted, declined, failed. The revealed email is null until the recipient accepts and provides it.

ParametersJSON Schema
NameRequiredDescriptionDefault
invite_idYesThe invite_id returned by send_calendar_invite.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains possible return values (sent, accepted, declined, failed) and the nuanced behavior of the revealed email being null until acceptance. This is useful, though it doesn't mention side effects or authentication requirements, which are likely minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with purpose and immediately followed by return value details. Every sentence earns its place with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read-only tool with no output schema, the description is remarkably complete: it explains the statuses, the email retrieval behavior, and the null-until-accepted nuance. There's no missing critical information for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the single parameter 'invite_id' with a description pointing to send_calendar_invite. The tool description doesn't add semantic value beyond that, so the baseline of 3 applies given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to check invite status (accepted/declined) and retrieve the recipient's email once accepted. It uses a specific verb+resource ('check whether a sent invite...') and naturally distinguishes itself from the sibling 'send_calendar_invite' by focusing on status retrieval rather than sending.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after sending an invite ('sent invite') and clarifies that the email is only available after acceptance, giving clear context. However, it does not explicitly mention when not to use it or compare it to the sibling tool, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_calendar_inviteAInspect

Invite a person to a calendar event using only their phone number. They receive the invite as a text message; if they accept, their real email address is returned to the organizer (retrieve it with get_invite_status, or have it POSTed to your callback_url). US phone numbers only (including Puerto Rico and other US territories); Canadian and other international numbers are not supported and will be refused. You must attest that you have the recipient's consent to contact them about this event.

ParametersJSON Schema
NameRequiredDescriptionDefault
endNoOptional event end, same formats as start.
phoneYesRecipient phone number, US only. Accepts +15551234567, 15551234567, 5551234567, or (555) 123-4567.
startYesEvent start. ISO 8601 datetime, or a date (2026-06-15) for an all-day event. PREFERRED for a timed event: local wall-clock time plus `timezone` (e.g. start "2026-06-15T14:00:00" with timezone "America/Chicago" = 2pm in Chicago). An offset ("2026-06-15T14:00:00-05:00") or UTC ("2026-06-15T19:00:00Z") is also accepted. A bare local time with NO timezone is read as UTC.
titleYesEvent title. Shown in the text message and on the accept page.
locationNoOptional location (e.g. "Phone", an address, or a meeting link).
timezoneNoIANA time zone of the event, e.g. "America/Chicago". Strongly recommended for any timed event: the invite SMS shows the time in this zone with its abbreviation ("Mon, Jun 15, 2026 at 2:00 PM CDT"), so the recipient reads the time the organizer actually meant. Without it a UTC time is shown labelled "UTC", which is correct but rarely what the recipient expects.
organizerYesOrganizer email. The RSVP and the recipient's revealed email are delivered to this address.
descriptionNoOptional event description / notes.
callback_urlNoOptional public https URL. maeil POSTs the recipient's response (and email) here when they accept or decline.
consent_attestationYesREQUIRED. A short statement of the basis on which you are permitted to text this person about this event (e.g. "client booked by phone on 6/1", "met at conference and exchanged numbers"). This is the legal basis for the message; sends without it are refused.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It explains the invite delivery mechanism, that accepted invites reveal the recipient's email, how to obtain that email, the US-only restriction, and consent requirements. It does not describe decline behavior or error responses, but the core action and its consequences are well disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, well-structured, and front-loads the core purpose. Every sentence adds meaningful guidance: invitation behavior, result retrieval, phone number restrictions, and consent obligation, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and lack of an output schema, the description covers the essential flow, constraints, and follow-up actions. It explains what happens on acceptance, how to retrieve or receive the email, and what is required for a valid send. Minor gaps remain around refusal reasons and decline behavior, but these are secondary to correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds general behavioral context rather than per-parameter details, which is appropriate given the rich schema, but it does not significantly enhance parameter-level understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: inviting a person to a calendar event via phone number. It distinguishes this from the sibling tool by mentioning get_invite_status for retrieving the recipient's revealed email, so an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the tool's context clear: send an SMS-based calendar invite, with US-only phone numbers and mandatory consent attestation. It also points to get_invite_status for follow-up, though it does not explicitly enumerate when not to use this tool or compare it against alternative invitation methods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Changedsend_calendar_invite3 fields changed
      • changedInput schema / properties / phone / description
        Previous value: -"Recipient phone number, US/Canada. Accepts +15551234567, 15551234567, 5551234567, or (555) 123-4567."New value: +"Recipient phone number, US only. Accepts +15551234567, 15551234567, 5551234567, or (555) 123-4567."
      • changedInput schema / properties / start / description
        Previous value: -"Event start. ISO 8601 datetime (e.g. 2026-06-15T14:00:00Z) or a date (2026-06-15) for an all-day event."New value: +"Event start. ISO 8601 datetime, or a date (2026-06-15) for an all-day event. PREFERRED for a timed event: local wall-clock time plus `timezone` (e.g. start \"2026-06-15T14:00:00\" with timezone \"America/Chicago\" = 2pm in Chicago). An offset (\"2026-06-15T14:00:00-05:00\") or UTC (\"2026-06-15T19:00:00Z\") is also accepted. A bare local time with NO timezone is read as UTC."
      • addedInput schema / properties / timezone
        Added value: +{
+  "description": "IANA time zone of the event, e.g. \"America/Chicago\". Strongly recommended for any timed event: the invite SMS shows the time in this zone with its abbreviation (\"Mon, Jun 15, 2026 at 2:00 PM CDT\"), so the recipient reads the time the organizer actually meant. Without it a UTC time is shown labelled \"UTC\", which is correct but rarely what the recipient expects.",
+  "type": "string"
+}
  2. 2 tool updates
    • First observedget_invite_status
    • First observedsend_calendar_invite

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

The two tools have clearly distinct responsibilities: one initiates the invite, the other retrieves its status. There is no overlap in purpose, so an agent can easily choose the right tool.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern: send_calendar_invite and get_invite_status. The verbs are clear and the nouns describe the target, making the naming predictable and readable.

Tool Count4/5

With only two tools, the set is minimal but directly covers the server's intended functionality of sending invites and checking their status. This is slightly under the typical 3-15 range but reasonable for a narrow use case.

Completeness4/5

The workflow of sending an invite and then checking/receiving the result is fully covered. Missing operations like cancellation are not explicitly required for this domain, so only minor gaps exist.

Resources