Skip to main content
Glama

Update a saved AI review

update_review
DestructiveIdempotent

Update a saved AI review in place after the user's feedback, however far it takes the review, instead of saving another (save a new one only when the user asks for a separate one). Read it with get_review first, then give the whole review as it should now be: save_review's arguments plus review_id; nothing of the old one is kept unless given again. Give each recommendation that stays its id: it keeps its status. from and to are required. Changing the scope, page, funnel, key action or period counts toward the plan's reviews per month; text, evidence or recommendations alone do not. Call it with dry_run true first (counts_as_review says whether it counts) and fix every problem it lists. A placeholder is shown with its own unit and sign, so never write a unit (%, s, seconds, points) or a + sign right before or after one. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

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": {
      "review_id": "<review_id>",
      "title": "<title>",
      "short_answer": "<short_answer>",
      "confidence": "<confidence>",
      "confidence_reason": "<confidence_reason>",
      "recommendations": "<recommendations>",
      "method": "<method>"
    },
    "name": "update_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast day the review is about, YYYY-MM-DD, not after today, at most 92 days after from. Default: yesterday, the last complete day.
fromNoFirst day the review is about, YYYY-MM-DD in the project's timezone; the same as for get_review_data. Default: 27 days before 'to'.
scopeNosite (the whole project), page (one page: page_origin and page_path) or flow (one funnel's flow: funnel_id). Left out: page when page_origin or page_path is given, flow with funnel_id, otherwise site.
titleYesA short title, plain text (no placeholders), at most 200 bytes, e.g. Home page review.
methodYesHow the review was made.
run_idNoThe setup run this review belongs to, from start_setup_run or an earlier write. Omit to start a new chat run (its id is returned). Not used by a dry run.
checkedNoWhat else was checked and not chosen, up to 12 rows, each with a real reason.
dry_runNotrue: check everything, build the review data, fetch every piece of evidence and return the review as it would be stored, every placeholder filled in; nothing is saved or counted. Do this first, fix every problem it lists, then call again without it.
projectNoProject ID, from list_projects. Required when this connection covers more than one project; may be left out when it covers one (and with an API key, which belongs to one project).
evidenceNoUp to 20 pieces of evidence: the API's own reads for numbers the review data does not hold (a comparison with the period before, a page or feature outside the sections, a query of your own). The API fetches each one itself when the review is saved and keeps its numbers, which {{eN.field}} placeholders name. Any text may name any of them. A number of the review data needs none: write {{d[REF].field}}.
funnel_idNoScope flow: the funnel's id, from list_funnels.
page_pathNoScope page: the page's path, exactly as list_pages gives it (e.g. /pricing, or /products/:id rather than one product's URL). It needs page views in the period.
review_idYesThe saved review to update, from list_reviews or get_review.
confidenceYesHow sure the review is: low, medium or high.
stands_outNoWhat stands out: 1 to 6 items, ranked by how unusual each is and how many visits it affects. With a key action it may be left out when explanations are given.
page_originNoScope page: the page's origin, exactly as list_pages gives it (e.g. https://shop.example.com).
explanationsNoWith a key action only: up to 5 competing explanations of what the numbers show, each with what it would predict, what is observed and the verdict. Instead of or beside stands_out.
goal_featureNoOptional key action to judge against: a feature name, exactly and case-sensitively as list_features or list_feature_rules gives it. Adds key action clicks per page and the goal_gap check. Not together with goal_funnel_id.
short_answerYesThe short answer: 2 to 5 bullets of at most 600 bytes, the answer first, then what to do next. Measured numbers as placeholders: {{d[REF].field}} for the review data, {{e1.views}} for evidence.
goal_funnel_idNoOptional key action to judge against: a funnel's id, from list_funnels (a goal, is_goal true, is the natural one); adds its funnel_steps to a site or page review. Not for scope flow, whose funnel is its key action already; not together with goal_feature.
recommendationsYes1 to 3 recommendations, in the order to do them; the first is the one to do first.
confidence_reasonYesWhy, in one line of plain text (no placeholders), at most 300 bytes, e.g. Medium that the gap is real, low on its cause; about 8 people a day see this page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=true) by saying what is destroyed: nothing of the old review is kept unless given again, and a recommendation keeps its status only if its id is re-supplied. It also discloses quota behavior (scope/page/funnel/key-action/period changes count toward the monthly review allowance, text/evidence/recommendation-only edits do not) and how run_id groups this change with a setup run for undo. The only gap is the shape of the non-dry-run response beyond the returned run_id.

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?

The core purpose is front-loaded in a strong opening sentence, but the remainder is one dense unbroken paragraph mixing routing, dry-run protocol, quota accounting, placeholder formatting and run_id rules. Almost every clause carries a rule, yet the lack of grouping or line breaks makes the operating procedure hard to extract on first read.

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 22-parameter, deeply nested, destructive mutation tool with no output schema, the description covers the critical operational facts: read-before-write, whole-review replacement semantics, dry-run-first validation, quota costing, undo grouping, and placeholder formatting. It does not describe what a successful non-dry-run call returns beyond run_id, which is the main remaining gap given no output schema exists.

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 100% schema coverage the baseline is 3, but the description adds real cross-parameter semantics the schema does not carry: review_id pairs with save_review's argument set, recommendations must repeat their id to survive, run_id must be omitted rather than sent as an empty string, and placeholders are rendered with their own unit and sign so no unit or '+' may be written next to them. It slightly misleads by asserting 'from and to are required' when the schema marks both optional with defaults.

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?

Opens with a specific verb and resource: update a saved AI review in place, 'however far it takes the review'. It immediately distinguishes itself from the sibling write tool by stating that save_review is only for a genuinely new review, so an agent can route between the two without opening either 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 sequencing and alternatives: read with get_review first, then call update_review; save_review only when the user asks for a separate review; call with dry_run true first and fix every problem it lists. When-to-use, when-not-to-use, and prerequisites are all stated.

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.

Resources