Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Create a public hosted event (a page with RSVPs)

connections_event_create

Use this when the member asks to create, host, plan or set up a PUBLIC event that others attend ('host an event', 'set up a meetup', 'create an event page for X'). Creates ONE hosted event on Connections - its own public page with RSVPs and tickets - as a draft, in this connection's preferred workspace unless project names another; a draft is private until published. It does not put anything on the member's own calendar: for 'add it to my calendar', a meeting, an appointment or blocked-out time, use connections_calendar_add. Write the title and the description yourself, in the member's words, from what they told you: Connections runs no AI of its own on a draft, so the writing costs the member no Connections credits (it uses their own assistant plan). Pass dry_run:true first to see exactly what would be created without creating anything, and show that to the member before writing for real. A draft is free; to put it live, call connections_event_publish with the id this returns. Every other setting - tickets, registration questions, capacity, approval, the cover, and later changes to any of these - goes through events_manage_hosted_events (create-event / update-event) with the event's id.

Input Schema

NameRequiredDescriptionDefault
titleYesThe event's name, in the member's words.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
dry_runNotrue = return exactly what would be created and create nothing. Default false.
ends_atNoOptional end time, in the same form.
projectNoWorkspace to run this call in (id or name).
locationNoOptional public location label: a city, venue name, or 'virtual'.
timezoneNoThe event's time zone as an IANA name, e.g. 'America/Chicago'; needed with starts_at. Its page shows times in this zone. Use the member's own zone unless the event is somewhere else.
starts_atNoOptional start time: an ISO date-time, e.g. 2027-01-15T18:00 with timezone, or with its offset.
descriptionNoOptional description of the event, shown on its public page.
guests_see_who_cameNoAfter the event, checked-in guests see who else came (the 'Who did you meet?' recap). Default true; false turns it off, e.g. for a large event. Each guest can still hide themselves.
guest_list_visibilityNoWho sees the guest list before the event: public (names), count_only (just the number), hidden. Default hidden.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / ends_at / description
      Previous value: -"Optional end time: an ISO date/time string, or unix seconds."New value: +"Optional end time, in the same form."
    • 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})?)?$"
    • changedInput schema / properties / starts_at / description
      Previous value: -"Optional start time: an ISO date/time string, or unix seconds."New value: +"Optional start time: an ISO date-time, e.g. 2027-01-15T18:00 with timezone, or with its offset."
    • 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})?)?$"
  2. Changed1 schema field changed
    • changedInput schema / properties / timezone / description
      Previous value: -"The event's time zone as an IANA name, e.g. 'America/Chicago'. Its page shows times in this zone; omitted, it is UTC. Use the member's own zone unless the event is somewhere else."New value: +"The event's time zone as an IANA name, e.g. 'America/Chicago'; needed with starts_at. Its page shows times in this zone. Use the member's own zone unless the event is somewhere else."
  3. Changed1 schema field changed
    • addedInput schema / properties / timezone
      Added value: +{
+  "description": "The event's time zone as an IANA name, e.g. 'America/Chicago'. Its page shows times in this zone; omitted, it is UTC. Use the member's own zone unless the event is somewhere else.",
+  "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. Changed2 schema fields changed
    • addedInput schema / properties / guest_list_visibility
      Added value: +{
+  "description": "Who sees the guest list before the event: public (names), count_only (just the number), hidden. Default hidden.",
+  "enum": [
+    "public",
+    "count_only",
+    "hidden"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / guests_see_who_came
      Added value: +{
+  "description": "After the event, checked-in guests see who else came (the 'Who did you meet?' recap). Default true; false turns it off, e.g. for a large event. Each guest can still hide themselves.",
+  "type": "boolean"
+}
  7. Added

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: it creates a DRAFT that is private until published, is free to create, lives in the connection's preferred workspace unless project overrides, does not touch the calendar, and consumes no Connections AI credits. The dry_run-first protocol is stated explicitly, which is the key behavioral instruction for a non-idempotent mutation.

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 condition and the core action, then follows with exclusions, dry_run guidance, and follow-on calls in a logical order. It is dense and long for a single tool, but nearly every sentence carries routing or behavioral information.

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?

Covers what would trip an agent up on a non-idempotent create: draft vs live state, where the event lands, what it does not do (calendar), how to preview with dry_run, and how to complete the workflow via publish/settings tools. No output schema exists, but the description tells the agent what it gets back (an id used by publish).

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description goes further by explaining the workspace default for `project`, the authoring responsibility for title/description, the publish path that consumes the returned id, and the optional start/end fields' semantics. It does not restate the enum or the guest-visibility behavior, which is fine since the schema covers them.

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 ('Creates ONE hosted event... its own public page with RSVPs and tickets') and explicitly contrasts with the calendar tool and the settings-management sibling. An agent can distinguish this from connections_calendar_add, connections_event_publish, and events_manage_hosted_events without opening any 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 ('host an event', 'set up a meetup'), an explicit exclusion ('does not put anything on the member's own calendar... for add it to my calendar use connections_calendar_add'), and routes follow-on work (publish via connections_event_publish, other settings via events_manage_hosted_events).

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