Skip to main content
Glama
Sign In

Mostly Right

by md.mostlyright
OverviewDiscussionsAdmin

Rename a dataset, rewrite its description, set its category or choose its main table

update_dataset
Idempotent

main_table_id names the table the dataset page leads with: the Data tab opens on it and the other tables keep their configured sections, or are listed as helpers when no layout is configured. Use configure_dataset_layout for readable titles and custom sections/order. Set it once a dataset has more than one table, to the table people query directly (the search table); pass null to clear it (a configured layout then opens its first visible table). Left unset, the page leads with the table named search or search_…, else the first by name. It is a presentation choice held by this service, so a call with only main_table_id writes nothing to the build service. 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, category_id (when sent), main_table_id (when sent), changes, version, visibility, public_projection_synced (when metadata was sent), dashboard_url}. A workspace admits one dataset per name; a name already taken is refused. visibility is who can see the dataset: private (this workspace only), link (anyone with its link) or public (listed on Mostly Right), or null if unknown. public_projection_synced only says the public copy is current: it is true for a private dataset too and never means the dataset is public. Report visibility, not that flag. Change it only with set_dataset_visibility, and only when the person asks. category_id files the dataset under exactly one primary category, chosen from what the dataset is about (its purpose, tables and measured entities), never from its source, cadence or tags: climate-environment (Climate & Environment), crypto (Crypto), finance (Finance), economics-business (Economics & Business), government-politics (Government & Politics), people-society (People & Society), health-medicine (Health & Medicine), science-research (Science & Research), technology (Technology), energy (Energy), agriculture-food (Agriculture & Food), transport-mobility (Transport & Mobility), places-infrastructure (Places & Infrastructure), education (Education), sports (Sports), arts-media-entertainment (Arts, Media & Entertainment), law-public-safety (Law & Public Safety), other (Other). Set it once the subject is clear and before register_recipe; get_my_dataset reports it. A category can be changed but not cleared, and other is for a subject none of the rest fits. 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.

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

Input Schema

NameRequiredDescriptionDefault
nameNo
sync_onlyNo
dataset_idYes
category_idNo
descriptionNo
main_table_idNo
expected_versionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / main_table_id
      Added value: +{
+  "anyOf": [
+    {
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / category_id
      Added value: +{
+  "enum": [
+    "climate-environment",
+    "crypto",
+    "finance",
+    "economics-business",
+    "government-politics",
+    "people-society",
+    "health-medicine",
+    "science-research",
+    "technology",
+    "energy",
+    "agriculture-food",
+    "transport-mobility",
+    "places-infrastructure",
+    "education",
+    "sports",
+    "arts-media-entertainment",
+    "law-public-safety",
+    "other"
+  ],
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / expected_version
      Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / sync_only
      Added value: +{
+  "const": true,
+  "type": "boolean"
+}
  5. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only give a coarse profile (readOnly=false, destructive=false, idempotent=true), while the description supplies the details an agent cannot infer: the optimistic-concurrency precondition that refuses concurrent edits, the fact that it is metadata-only and rebuilds nothing, that a main_table_id-only call writes nothing to the build service, that a description change auto-generates name and topic tags except for user-chosen ones, and that the one-name-per-workspace rule refuses duplicates.

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

Conciseness2/5

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

Roughly 450 words in one undifferentiated block, ordering topics as main_table → description authoring → visibility → category → retry advice. Individual sentences are dense with value, but there is no front-loaded summary, no separation of per-parameter rules from general behavior, and the description-authoring paragraph plus the example consume a large share of the budget for what is essentially style advice.

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 seven-parameter, multi-purpose mutation tool with no output schema and no schema descriptions, the definition still covers return shape explicitly (dataset_id, name, description, changes, version, visibility, public_projection_synced, dashboard_url) and warns not to report public_projection_synced as visibility. Nothing an agent needs to invoke 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?

With 0% schema coverage the description must carry the parameters, and it largely does: main_table_id (including null-clearing and default fallback to a table named 'search'), description (with authoring guidance and an example), name, category_id (full enum spelled out with display labels and selection criteria), and sync_only. expected_version is only alluded to obliquely as 'the current version' rather than named as the input field, and it understates the mutual dependency between name and description — a small but real gap.

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?

The title and the sentence 'Changes a dataset's display name, its description, or both' state a specific verb and resource, and the text names the siblings it is not (configure_dataset_layout, set_dataset_visibility, create_dataset, get_my_dataset). The problem is placement: the description opens with a paragraph about main_table_id, so the actual purpose statement is buried mid-text rather than front-loaded.

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?

Every parameter carries an explicit when/when-not: use main_table_id once a dataset has more than one table, use configure_dataset_layout instead for titles and sections, change category before register_recipe and never from source/cadence/tags, change visibility only with set_dataset_visibility and only when the person asks, and retry with sync_only when public_projection_synced is false. Alternatives and exclusion conditions are named rather than implied.

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

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