Skip to main content
Glama

Open a project to its audience

open_project

Outward: Activate a project and deliver it to members. It always opens now, and posts the invitation wherever the project names a place, today the Discord channel in delivery.invitation.post_channel_id, and nowhere else. Posts and direct messages reach real members and cannot be taken back, so confirm with the human first. A project answered on the web (open_web, or private with response_channel web) can open without posting anything: pass delivery.invitation.post_channel_id: null, then give the human data.share_url from the response (never build that link yourself); a private one then raises the MissingPostChannel warning, accepted once the human confirms they share the link. A project answered in Discord needs the channel. Go-live validation runs here: errors block the call (409 script_validation); so do unaccepted warnings, which the human can accept by passing their fingerprints in acknowledge. Run validate_script first so you see them before the audience does. To open later, use update_project with a scheduled delivery.opening instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deliveryNo
project_idYesProject id, from list_projects or create_project.
acknowledgeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / $defs / AudienceRequest / properties / participation / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "private",
      +      "open_web"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / $defs / AudienceRequest / properties / response_channel / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "discord",
      +      "web"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / $defs / ClosingRequest / properties / mode / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "manual",
      +      "scheduled"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / $defs / EmbedConfigRequest / properties / info_display / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "embed",
      +      "button"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / $defs / InvitationRequest / properties / answer_button_color / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maximum": 4,
      +    "minimum": 1,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / acknowledge
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Acknowledge"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say it is not read-only and not idempotent; the description adds the irreversible side effect (invitations reach real members and cannot be taken back), the 409 script_validation failure mode, that unaccepted warnings block the call unless fingerprints are passed in acknowledge, and the MissingPostChannel warning for private projects. This is far beyond what annotations convey.

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 core action before the conditional detail, and nearly every sentence carries operational weight. It is still a dense, long single block; a few clauses could be tightened or split for scanability.

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 3-parameter mutation with no output schema and no annotation depth, this covers the branches an agent needs: when posting occurs, when it can be skipped, how to surface data.share_url, how validation errors and warnings are resolved, and the deferral path.

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 only 33% (project_id documented; acknowledge and delivery are not), so the description must compensate. It does explain acknowledge (human-supplied fingerprints) and the key nested field delivery.invitation.post_channel_id (null for web-only opens), but leaves other nested fields such as audience.participation, closing, and answer_surfaces unaddressed.

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 ('Activate a project and deliver it to members') and clearly separates itself from siblings by naming update_project with a scheduled delivery.opening for the deferred case and validate_script for pre-flight preview. An agent can pick this tool correctly without inspecting 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?

Explicit when-to-use rules: always opens immediately, must confirm with the human first because posts/DMs are irreversible, run validate_script beforehand, and use update_project instead when opening later. It also branches usage by participation mode (open_web/private vs Discord).

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.