Skip to main content
Glama

Quillm

Update a view

update_view
Destructive

Changes an existing view's code or metadata. Pass expected_revision (the revision get_view showed you) so you never overwrite a change another agent made in the meantime. Prefer edits (exact string replacements, like a find-and-replace; each old_string must match the current source exactly and be unique) for targeted changes such as adding a chart. Use source only for a full rewrite, or restore_revision to roll back. Every call creates a new revision, is test-rendered and reviewed; a revision that fails its render check is NOT published (readers keep the last working one) and your next edits apply to it. The review sends a screenshot and the page's text to OpenAI, unless the workspace turned checks off. When a follow-up request replaces an earlier approach (a better burn figure, a new default), replace the old blocks instead of keeping both: revisions make removal safe. Call get_view first to get the current source. To change only the numbers a view shows, do NOT use this tool: use upsert_rows on the dataset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iconNoNew emoji for the page, e.g. "💰".
kindNoWhat the page is for. "dashboard": numbers someone watches over time. "tracker": items people work through (steps, tasks, leads) with owners and status. "doc": a brief, report or analysis mostly in prose. "calculator": inputs the reader changes and an answer. Decides what the page review holds it to.
slugYesThe view to change: its slug, or its page URL.
coverNoNo longer shown; kept for older clients.
editsNoTargeted replacements, applied in order. Preferred for most changes.
titleNoNew title. Omit to keep the current one.
sourceNoFull replacement source. Only for rewrites; do not combine with edits.
questionsNoReplaces the view's questions. Pass it when the user's follow-up changes what the page is for.
collectionNoMoves the view to another collection, which changes who can open it. Only when the user asked.
change_noteYesWhat changed and why, for the revision history.
descriptionNoNew one-sentence description of what the view answers.
dependenciesNoReplaces the full set of extra dependencies.
restore_revisionNoRoll the source back to this revision number.
expected_revisionNoThe revision you read with get_view. If someone saved a newer one since, nothing is saved and you are told who; read it again and redo your change on top.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: every call creates a new revision, is test-rendered and reviewed, a failed render is NOT published so readers keep the last working version, the review sends a screenshot and page text to OpenAI unless checks are off, and stale revisions block the save. These are consequential behaviors (privacy, failure mode, concurrency) an agent could not infer from the structured fields.

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 purpose and the concurrency contract, and each sentence carries operational weight. It is on the long side for a description and repeats the get_view prerequisite twice, but there is little filler.

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 14-parameter mutation tool with no output schema, the description covers the failure mode, revision safety net, external data disclosure, prerequisites, and the alternative tool for a common adjacent intent. Nothing needed 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?

Schema coverage is 100%, so baseline is 3; the description adds comparative semantics beyond it, explaining that edits are exact unique string replacements like find-and-replace, that source must not be combined with edits, and how expected_revision guards against overwriting another agent's change. It stops short of covering the other 11 parameters, which the schema already documents well.

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 ('Changes an existing view's code or metadata') and immediately contrasts with siblings: get_view for reading, upsert_rows for changing only numbers. An agent can distinguish this from create_view, delete_view, and update_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 Guidelines5/5

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

Explicit routing: prefer `edits` for targeted changes, use `source` only for full rewrites, `restore_revision` to roll back, and a named when-NOT-to-use ('do NOT use this tool: use upsert_rows on the dataset'). It also states the prerequisite ('Call get_view first to get the current source').

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.