Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Publish one of my draft events (puts it on its public page)

connections_event_publish
Destructive

Use this when the member asks to publish, go live with, or open registration on an event they already created as a draft ('publish my meetup', 'make the event public'). Publishes ONE of the member's own draft hosted events by id: its public page goes live and anyone with the link can see it and RSVP. It costs the member 0.05 credits from their Connections credits, charged once, the first time this event is published (a draft costs nothing, and publishing again later is free); if they are out of credits the event stays a draft and this says so. Only the member's own draft can be published; an event that is already published, or that is not theirs, is turned back with a plain message. Write the title and the description yourself, in the member's words, before you create or publish: Connections runs no AI of its own on it, so the writing costs nothing beyond that publish charge. Pass dry_run:true first to see what would go live and the cost, and ask the member to confirm before publishing for real. Returns the public event URL.

Input Schema

NameRequiredDescriptionDefault
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
dry_runNotrue = say what would be published and what it costs, and publish nothing. Default false.
projectNoWorkspace to run this call in (id or name).
event_idYesThe id of the member's own draft event, as returned by connections_event_create or connections_events_list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses cost behavior (0.05 credits once, free thereafter), what happens when credits are insufficient, the public visibility consequence, ownership restrictions, and the returned public URL. This adds substantial context to the destructive/open-world annotations.

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?

The description is front-loaded with the action and conditions, and most sentences carry useful operational detail. It is somewhat long and includes a tangential note about writing the title and description manually, but overall it is structured and not padded.

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?

Although there is no output schema, the description states that the public event URL is returned. It also covers prerequisites, failure cases, cost, visibility, and the dry-run confirmation step, which is enough for an agent to invoke and explain 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?

Schema coverage is 100%, so parameter meanings are already well documented. The description reinforces event_id ownership and the dry_run-first confirmation flow, but most parameter semantics remain supplied by the schema rather than the description.

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 uses a specific verb and resource: publishing one of the member's own draft hosted events, making its public page live and RSVP-enabled. It clearly distinguishes this from creating or updating an event and makes the outcome understandable without opening the 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?

It gives explicit triggers ('publish', 'go live with', 'open registration') and constraints: only the member's own draft, already-published or non-owned events are rejected. It also prescribes a dry-run-and-confirm workflow before real publishing.

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