Mostly Right

Rename a dataset or rewrite its description

update_dataset

Idempotent

A changed nonblank description generates a factual dataset name and topic tags, except a name or tags someone chose in an earlier update, which stay. The name given at create_dataset is a working title and does not count as chosen. Send name with the description to keep a title you want; it then stays until someone sends another. Drafts and unchanged descriptions do not generate metadata. Changes a dataset's display name, its description, or both. Reads the current version first and sends it as the precondition, so a change made elsewhere in between is refused rather than overwritten. The opening paragraph is the search snippet and the answer-engine summary, so it says what this is, then what it is for, then the facts, and never opens with the grain, the mechanism or a station code. Example: {"dataset_id": "…", "description": "Denver weather history since 2020: every airport report from Denver International (KDEN) with the official daily high and low. Built for daily temperature forecasting and for checking the weather at any hour. One row per report, about 30 a day, refreshed each morning with the previous day added."}. Returns {dataset_id, name, description, version, dashboard_url}. A workspace admits one dataset per name; a name already taken is refused. Nothing rebuilds — this is metadata only. If public_projection_synced is false, retry with {dataset_id, sync_only: true} to update the public page without repeating the metadata write.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`sync_only`	No
`dataset_id`	Yes
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 12, 2026
- addedInput schema / properties / sync_only
```
Added value: +{
+  "const": true,
+  "type": "boolean"
+}
```
First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: optimistic concurrency via version precondition (a concurrent change is refused rather than overwritten), workspace uniqueness on name, 'nothing rebuilds — metadata only', and the public-projection retry path. These are exactly the mutation semantics an agent needs and the annotations (readOnlyHint=false, idempotentHint=true) cannot express.

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

Conciseness3/5

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

Information-dense but poorly front-loaded: the definition opens with the metadata-generation rules and buries the core 'changes a dataset's display name, its description, or both' in the middle. The metadata paragraph is also syntactically convoluted, forcing a re-read, though few sentences are truly wasted.

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?

Despite no output schema, it enumerates the return shape ({dataset_id, name, description, version, dashboard_url}) and covers name collisions, concurrency, sync fallback, and metadata-only scope. An agent has everything required to call it correctly across scenarios.

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?

Schema description coverage is 0%, so the description carries the full burden and does: it defines name semantics (working title vs. explicitly chosen, persistence rules), sync_only's retry-only role, and description semantics including that the opening paragraph becomes the search snippet and answer-engine summary, with a full worked example. This far exceeds what the bare schema provides.

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 an unambiguous verb+resource ('Changes a dataset's display name, its description, or both') and differentiates from the sibling create_dataset by explaining that the name chosen at creation is only a working title. An agent can distinguish this from create_dataset and get_dataset 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 Guidelines4/5

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

Gives concrete invocation conditions: send name alongside the description to pin a title, and retry with {dataset_id, sync_only: true} when public_projection_synced is false. It also clarifies that drafts/unchanged descriptions generate no metadata. It stops short of explicitly routing among the many sibling update/list tools, but the context is clear.

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

All Mostly Right 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.

Resources

Need Help?