Loadster

Update Script

update_script

Update an existing script. Each of name, type, commands, variables, and tags is optional: a field left out keeps its stored value, an empty list clears that list, and a non-empty list replaces the whole list, never merging into it. A script's type cannot be changed: type, if sent, must match the script's bot type, so to switch types create a new script of the desired type instead. Sending commands or variables saves a new revision; a name or tags alone save no revision. Read the script with get_script before changing it, never rebuild it from list_scripts. Every write against a user's existing data needs their explicit confirmation first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "scriptId": "<scriptId>"
    },
    "name": "update_script"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Tag names; a name the team doesn't have yet becomes a new tag. Omit to keep the current tags; send [] to clear them.
`script`	No	The fields to change: name, type, commands, and variables. Leave a field out to keep it, or omit script to change only the tags. type, if sent, must be the script's current type; a different type is rejected.
`scriptId`	Yes
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

changedInput schema / properties / script / description

Previous value: -"The fields to change: name, type, commands, and variables. Leave a field out to keep it. type, if sent, must be the script's current type; a different type is rejected."New value: +"The fields to change: name, type, commands, and variables. Leave a field out to keep it, or omit script to change only the tags. type, if sent, must be the script's current type; a different type is rejected."

addedInput schema / properties / tags

Added value: +{
+  "description": "Tag names; a name the team doesn't have yet becomes a new tag. Omit to keep the current tags; send [] to clear them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "projectId",
-  "scriptId",
-  "script"
-]New value: +[
+  "projectId",
+  "scriptId"
+]

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / script / description

Previous value: -"The new script name, type, commands, and variables."New value: +"The fields to change: name, type, commands, and variables. Leave a field out to keep it. type, if sent, must be the script's current type; a different type is rejected."

removedInput schema / properties / script / required

Removed value: -[
-  "commands",
-  "name",
-  "type",
-  "variables"
-]

First observedSep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond annotations: revision semantics (commands/variables save a revision; name/tags alone do not), type immutability, and the field-omission/empty-list/replace semantics. The confirmation requirement and list-clearing behavior add context the readOnlyHint/destructiveHint flags do not 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?

Dense but every sentence earns its place, with the optional-field semantics front-loaded. The type-immutability and confirmation clauses are valuable but make the block slightly long to scan.

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?

Given no output schema and 4 params with 50% coverage plus nesting, the description covers mutation semantics, revision effects, and prerequisites well. Minor residual tension: it describes list clearing that sits loosely with destructiveHint=false, leaving a small ambiguity about how destructive the operation truly is.

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

Parameters5/5

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

At 50% schema coverage with a nested object, the description carries the essential semantics: each field optional, omitted keeps stored value, empty list clears, non-empty replaces without merging, and type must match the bot type. This meaning is not fully derivable from the schema alone.

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 ('Update') and resource ('an existing script'), and immediately frames scope through the get_script/create_script alternatives. An agent can distinguish it from get_script, list_scripts, create_script, and delete_script without opening a 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?

Explicitly prescribes reading with get_script first and never rebuilding from list_scripts, states that type changes require create_script instead, and adds a confirmation prerequisite for writes on existing data. When-to-use, when-not, and alternatives are all named.

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

All Loadster tools Inspect

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.