Skip to main content
Glama

Save an AI review

save_review

Save an AI review, which the customer reads in the dashboard. Scope, key action and period as for get_review_data (Privatrak stores those numbers with the review; never send them), then the short answer, confidence, what stands out, 1-3 recommendations, what else was checked, method. Call it with dry_run true first and fix every problem it lists. Numbers: every number from a tool result is a placeholder, marked in the dashboard as looked up by Privatrak: {{d[REF].field}} for the review data (from get_review_data's refs, no evidence needed), {{eN.field}} for evidence. Only dates, step numbers and your own arithmetic stay plain text. 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. Counts toward the plan's reviews per month (get_project reviews_left). 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": {
      "title": "<title>",
      "short_answer": "<short_answer>",
      "confidence": "<confidence>",
      "confidence_reason": "<confidence_reason>",
      "recommendations": "<recommendations>",
      "method": "<method>"
    },
    "name": "save_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.
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.2/5.0
Behavior5/5

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

Annotations already declare a non-read-only, non-destructive mutation, and the description adds substantial behavior beyond that: dry_run saves and counts nothing, the review counts toward the plan's monthly reviews, run_id groups changes for undo, placeholders are validated and refused when invalid, and evidence is fetched at save time. There is no contradiction with the annotations.

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 purpose and dry_run workflow are front-loaded, but the description is a dense single paragraph with many semicolon-separated rules and some repetition around dry_run and placeholders. It is information-rich but not as scannable as it could be for a 21-parameter tool.

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 complex 21-parameter nested mutation with no output schema, the description covers purpose, dry_run validation, quota impact, run_id undo behavior, evidence fetching, placeholder rules, and refusal behavior. The annotations cover safety and the schema covers parameter details, so nothing critical 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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning: scope, key action and period mirror get_review_data, Privatrak stores those numbers with the review, and placeholders use {{d[REF].field}} for review data versus {{eN.field}} for evidence. It also clarifies run_id and dry_run behavior beyond the schema text.

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?

States a specific verb and resource: "Save an AI review, which the customer reads in the dashboard." It is clear what the tool does, but it does not explicitly distinguish itself from the sibling update_review tool, so it falls short of a 5.

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 a clear workflow: call with dry_run true first, fix every problem it lists, then call again without it. It also explains run_id usage for undoing with a setup run versus starting a new chat run, but it does not name update_review as the alternative for editing an existing review or state when not to use this tool.

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