Skip to main content
Glama

Update a project

update_project

Update a project's name, privacy, rewards or settings. Only the fields you pass change. Passing script replaces the whole script atomically and requires an inactive project. To open later, set delivery.opening to {mode: "scheduled", time} on an inactive project and do NOT call open_project: the project opens itself at time and posts its invite then, so confirm with the human as you would before open_project. delivery.closing the same way closes it at time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
scriptNo
rewardsNo
deliveryNo
settingsNo
project_idYesProject id, from list_projects or create_project.
presentationNo
privacy_modeNo
scoring_enabledNo
max_completes_per_userNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • changedInput schema / $defs / ActionConfigSchema / properties / fire_scope / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "respondent",
      +      "session"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • 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 / BlockOptionSchema / properties / anchor_position / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "const": "last",
      +    "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 / ContinueSchema / properties / after / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "pause",
      +      "click"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / $defs / ContinueSchema / properties / pause / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "minimum": 0,
      +    "type": "integer"
      +  },
      +  {
      +    "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"
      +  }
      +]
    • changedInput schema / $defs / OpeningRequest / properties / mode / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "manual",
      +      "scheduled"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / $defs / SettingsRequest / properties / poll_results_mode / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "public",
      +      "voters_only",
      +      "hidden"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. Changed2 schema fields changed
    • addedInput schema / $defs / BlockSchema / properties / text_analysis
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Text Analysis"
      +}
    • addedInput schema / $defs / SettingsRequest / properties / text_analysis
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Text Analysis"
      +}
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing partial-update semantics ('Only the fields you pass change'), atomic whole-script replacement and its inactive-project precondition, and the self-opening/self-closing schedule behavior with a human-confirmation requirement. These are exactly the non-obvious traits the annotations (readOnly/destructive/idempotent hints) cannot 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 purpose, then progresses to field-level and scheduling caveats. The scheduling paragraph is long but every clause carries actionable information; there is little filler.

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 10-parameter tool with 10% schema coverage and no output schema, the description covers the highest-risk behaviors (partial updates, script replacement, scheduled open/close and the human-confirmation norm). It is close to sufficient, though several top-level parameters remain undocumented in both schema and prose.

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 description coverage is only 10% (essentially just project_id), so the description must carry the load. It adds meaning for `script` (atomic replace) and `delivery.opening`/`delivery.closing` (the `{mode, time}` shape), but leaves `presentation`, `privacy_mode`, `scoring_enabled`, and `max_completes_per_user` entirely unexplained, so compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update a project's name, privacy, rewards or settings') and enumerates the updatable domains. It does not, however, distinguish itself from the sibling replace_script even though passing `script` also replaces a whole script, so the boundary with that sibling is left ambiguous.

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

Usage Guidelines4/5

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

Gives a real precondition ('requires an inactive project') and an explicit when-not instruction ('do NOT call open_project') for scheduled opening, which is genuine routing guidance. It still omits when to prefer replace_script over passing `script` here, so the alternative-space is only partly covered.

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.