Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Add to my calendar

connections_calendar_add

Use this when the member asks to add, put or schedule something on their calendar, book or block out time, or save a meeting, appointment or call at a set time ('add it to my calendar', 'put lunch with Sam on my calendar Friday at noon', 'block out 2-4pm tomorrow'). Creates ONE event on the member's own Connections calendar, the one the Connections Calendar add-on and the Connections calendar app show, visible only to them. starts_at is an ISO date-time with the member's UTC offset (2027-01-15T10:00:00-06:00 is 10am US Central) or a plain 2027-01-15T10:00, read in the member's saved time zone unless timezone says otherwise; ends_at defaults to one hour later; all_day:true makes it a whole-day event. The reply names what was added and when, so say it back. For a public event with its own page, tickets or RSVPs use connections_event_create; for a to-do with no time slot use connections_todo_add.

Input Schema

NameRequiredDescriptionDefault
titleYesWhat it is, in the member's words ('Lunch with Sam').
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
all_dayNotrue = a whole-day event with no time slot. Default false.
ends_atNoOptional end, same format. Default: one hour after starts_at (for all_day, the same day).
projectNoWorkspace to run this call in (id or name).
timezoneNoOptional IANA time zone, e.g. 'America/Chicago', that plain wall-clock times (2027-01-15T10:00) are read in, daylight saving included. Leave it out to use the member's saved time zone.
starts_atYesStart, as an ISO 8601 date-time with the member's UTC offset (2027-01-15T10:00:00-06:00), or a plain wall-clock time (2027-01-15T10:00) read in timezone, or in the member's saved time zone when timezone is left out. For an all-day event, midnight (2027-01-15T00:00).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / starts_at / description
      Previous value: -"Start, as an ISO 8601 date-time WITH the member's UTC offset, e.g. 2027-01-15T10:00:00-06:00. For an all-day event, midnight at their offset (2027-01-15T00:00:00-06:00)."New value: +"Start, as an ISO 8601 date-time with the member's UTC offset (2027-01-15T10:00:00-06:00), or a plain wall-clock time (2027-01-15T10:00) read in timezone, or in the member's saved time zone when timezone is left out. For an all-day event, midnight (2027-01-15T00:00)."
    • changedInput schema / properties / timezone / description
      Previous value: -"The member's IANA time zone, e.g. 'America/Chicago'. With it, times may be plain wall-clock times (2027-01-15T10:00) and the server applies the zone's offset, daylight saving included."New value: +"Optional IANA time zone, e.g. 'America/Chicago', that plain wall-clock times (2027-01-15T10:00) are read in, daylight saving included. Leave it out to use the member's saved time zone."
  2. Changed2 schema fields changed
    • addedInput schema / properties / ends_at / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d{1,9})?)?(Z|[+-]\\d{2}:?\\d{2})?$"
    • addedInput schema / properties / starts_at / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}(:\\d{2}(\\.\\d{1,9})?)?(Z|[+-]\\d{2}:?\\d{2})?$"
  3. Changed1 schema field changed
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "The member's IANA time zone, e.g. 'America/Chicago'. With it, times may be plain wall-clock times (2027-01-15T10:00) and the server applies the zone's offset, daylight saving included.",
+  "type": "string"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / person
      Added value: +{
+  "description": "Linked person to run this call as (first name). Omit to run as the connection's holder.",
+  "type": "string"
+}
  5. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  6. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=false and openWorldHint=false, so the description's real contribution is the visibility model — the event lands on the member's own Connections calendar, shown only to them — plus the default one-hour end and the all_day semantics. It does not warn that the operation is non-idempotent (annotations say idempotentHint=false), so a retry could silently double-book; that is the one gap keeping it below 5.

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

Conciseness4/5

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

Front-loaded with the trigger and the sibling routing, then the format rules. Efficient overall, though the long first sentence and the repeated restatement of starts_at formatting that the schema already covers cost it a point.

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?

With no output schema, the description still tells the agent the reply names what was added and when, and instructs it to say that back. Combined with the visibility model, the sibling routing and the date-format rules, nothing an agent needs to call this correctly is missing.

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 coverage is 100% and the property descriptions restate nearly the same format guidance (ISO with offset, plain wall-clock read in timezone, ends_at default, all_day midnight). The description adds a small amount (a worked example mapping -06:00 to US Central), but the schema does the heavy lifting, so the baseline 3 applies.

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?

States a specific verb and resource (create one calendar event on the member's own calendar) and immediately scopes it against siblings: public events with tickets go to connections_event_create, untimed to-dos to connections_todo_add. An agent can distinguish it from connections_calendar_update or connections_event_create without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit trigger phrases ('add it to my calendar', 'block out 2-4pm tomorrow') plus two named alternatives with the exact conditions that select them (public event with page/tickets/RSVPs, or untimed to-do). When-to-use and when-not-to-use are both spelled out.

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

All Connections toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources