Loadster

Update Dataset

update_dataset

Destructive

Update an existing dataset. Each of name, values, and tags is optional: a field left out keeps its stored value, so a rename leaves the table alone. Values sent become the entire table, so send the complete table including every row you want to keep; an empty table clears the rows. To add rows, call append_dataset_rows instead.

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>",
      "datasetId": "<datasetId>"
    },
    "name": "update_dataset"
  }
}

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.
`dataset`	No	The fields to change: name and the table of values (data rows only — no header row). Leave a field out to keep it, or omit dataset to change only the tags.
`datasetId`	Yes
`projectId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 30, 2026

changedInput schema / properties / dataset / description

Previous value: -"The new dataset name and table of values (data rows only — no header row)."New value: +"The fields to change: name and the table of values (data rows only — no header row). Leave a field out to keep it, or omit dataset to change only the tags."

removedInput schema / properties / dataset / required
```
Removed value: -[
-  "name",
-  "values"
-]
```

changedInput schema / required

Previous value: -[
-  "projectId",
-  "datasetId",
-  "dataset"
-]New value: +[
+  "projectId",
+  "datasetId"
+]

Changed1 schema field changedOct 28, 2026

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"
+}

First observedSep 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description earns credit by explaining exactly what is destroyed: sent values replace the entire table and an empty table clears rows. That is the critical safety fact an agent needs. It stops short of covering permissions, transactional behavior, or whether a partial failure leaves the dataset modified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action and followed by the constraints in order of risk (omission, full replacement, empty table, alternative tool). No filler or repetition of the title.

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 destructive, non-idempotent mutation with no output schema, the description supplies the essential replace-not-merge semantics and the sibling routing. It could additionally say what the call returns after updating or note permission requirements, but nothing needed to call it safely is missing.

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 50%, so the description has to compensate, and it does for the important fields: name/values/tags are all optional, omission preserves stored state, and values is a whole-table replacement rather than an append. It does not restate the schema's 'no header row' rule or clarify datasetId/projectId, but the risky semantics are covered.

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 ('Update an existing dataset') and immediately enumerates the mutable fields (name, values, tags). It explicitly names the sibling append_dataset_rows and explains why you would not use this tool for that case, so the agent can distinguish it 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?

Gives explicit when-to-use rules (rename only, replace table, clear table) and an explicit when-to-use-something-else rule ('To add rows, call append_dataset_rows instead'). The omission semantics ('a field left out keeps its stored value') tell the agent how to express intent, not just what the fields are.

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.