Skip to main content
Glama

Save or post a show or party

save_event

Save the artist's own show, release party or listening party, or change one (pass event_id). It is saved as a DRAFT that only the artist sees, with whatever is known (only kind is needed), unless you pass post: true. Posting puts it on Scene for artists on Audora (and on the public page when is_public) and needs a title, starts_at and a place: a city and a country, and/or an online link. Post only when the artist asked for it to go out. An event already posted stays posted, so its changes need the same. Inviting artists or Audora stays the artist's to do in Audora; an edit keeps what they chose. Artist connections only.

Input Schema

NameRequiredDescriptionDefault
postNotrue puts it on Scene now (needs title, starts_at and a place). Leave out to save a draft.
eventYes
artistNoOnly when you are connected as a label: the roster artist this call is for — their artist_user_id from list_roster, or their exact artist name. Required for every artist tool on a label connection. Leave it out on an artist's own connection.
event_idNoTo change one; leave out to save a new one.
idempotency_keyNoSend the same key if you retry, and the change happens once.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / event / properties / is_public / description
      Previous value: -"Show it on the artist's public page."New value: +"Show it on the artist's public page once posted. Defaults: on for a show, off for a party."
    • changedInput schema / properties / event / properties / time_zone / description
      Previous value: -"IANA zone where it happens, e.g. Europe/Stockholm."New value: +"IANA zone where it happens, e.g. Europe/Stockholm. Needed with starts_at."
    • changedInput schema / properties / event / required
      Previous value: -[
      -  "kind",
      -  "title",
      -  "starts_at",
      -  "time_zone",
      -  "is_public"
      -]New value: +[
      +  "kind"
      +]
    • changedInput schema / properties / event_id / description
      Previous value: -"To change one; leave out to post a new one."New value: +"To change one; leave out to save a new one."
    • addedInput schema / properties / post
      Added value: +{
      +  "description": "true puts it on Scene now (needs title, starts_at and a place). Leave out to save a draft.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description goes well beyond them: drafts are private to the artist and need only kind, posting publishes to Scene/public page, posted events stay posted so later edits must also post, and edits preserve previously chosen values. These are real behavioral traits an agent cannot infer from the schema.

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?

Purpose and draft/post distinction are front-loaded, and nearly every sentence carries a distinct rule. The later sentences ('Inviting artists or Audora stays the artist's to do in Audora; an edit keeps what they chose') are dense and slightly awkward to parse, costing a point.

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?

For a nested-object mutation with no output schema and no annotations on data lifecycle, the description covers draft privacy, publish requirements, posted-state immutability and connection scope. The one gap is what the call returns (e.g. an event_id for subsequent edits), which an agent needs to chain calls.

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 80%, so most parameters are already documented, but the description adds cross-parameter logic the schema does not: only 'kind' is required for a draft, while posting demands title, starts_at and a place (city+country and/or online link). It does not explain time_zone or ends_at interplay, which the schema handles.

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 set (save, change, post) over a specific resource (the artist's show, release party or listening party), and the event_id branching clarifies the create-vs-update duality. It is clearly distinguishable from siblings like list_events or cancel_event.

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?

Explicit when-to-use and when-not: save as a draft by default, only set post: true when the artist actually asked for it to go out, and 'Artist connections only' (with the label path deferred to the artist param). It also rules out adjacent work ('Inviting artists... stays the artist's to do'), removing ambiguity about scope.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources