Skip to main content
Glama

Epovest

by com.epovest
OverviewDiscussionsAdmin

Update a tracker

update_tracker

Update the configuration of a tracker: only the fields you send change. Keywords, analysts and the title apply in place. Changing the prompts, engines, frequency or resolution of a version that HAS measured creates a new version: the score series continues across versions, and the response carries the new tracker id (version_created says when). A version that has not measured yet is amended in place and keeps its id, so version_created is false. A PAUSED tracker takes all of it, the collection settings included: the call writes the configuration and nothing else, no survey runs and no credit is spent, and what you set takes effect at the next start_tracker. That is the way to move a paused tracker to fewer engines or a slower frequency before paying for another survey. Send next_survey_at to say when that survey runs. A sent list replaces the previous one entirely.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoDisplay name of the tracker.
enginesNoThe AI engines surveyed. A check is priced per engine, in USD: chatgpt 0.10, claude 0.20, gemini 0.10, perplexity 0.10, mistral 0.10, grok 0.20. Claude and Grok read more sources per answer, and their check carries that. The amount for the whole tracker comes back as cost_per_survey_minor, so quote that one to the person rather than adding these up.
promptsNoThe questions asked to the AI engines at every survey, phrased exactly as a customer would ask them.
analystsNoThe lenses that score every survey. keyword_presence and share_of_voice are deterministic; sentiment and custom_prompt are AI analysts billed per analyzed response.
keywordsNoNames to detect in the answers: your brand and the names you compare against. Flag yours as favorite.
discoveryNoSuggest new keywords spotted in the answers.
frequencyNoHow often a survey runs. on_demand puts the tracker on no schedule at all: starting it runs one survey, and every survey after that is one you ask for with survey_now. Pick it for a one-off reading, or whenever the person wants to decide each time; the other values keep a survey running on their own pace.
project_idNoThe project the tracker is filed under: the UUID of a project of the account (call list_projects), or "default" for none. Pure organization, editable at any time. Omitted on creation the tracker files under Default; omitted on update the project does not change.
resolutionNoRepetitions of every question per engine and survey: hd=1, full_hd=3, 4k=6, 8k=9. Answers are stochastic; more repetitions sharpen the rates.
tracker_idYesThe UUID of the tracker: call list_trackers to find it.
custom_promptNoThe instruction of the custom_prompt analyst. Required when that analyst is selected.
next_survey_atNoWhen the next survey runs, ISO 8601, strictly in the future; read as UTC without an offset. Later surveys keep that day and time at the pace of the frequency. On a PAUSED tracker it is kept and read back like anywhere else, and it is what makes the next start_tracker wait instead of surveying right away. It goes with a frequency that has a pace: on on_demand, leave it out and call survey_now when the person wants a reading.
notify_on_surveyNoEmail the account owner and managers each time a survey closes with fresh data, so the results reach them on their own. On by default; send false to keep this tracker silent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / next_survey_at / description
      Previous value: -"When the next survey runs, ISO 8601, strictly in the future; read as UTC without an offset. Later surveys keep that day and time at the pace of the frequency. It goes with a frequency that has a pace: on on_demand, leave it out and call survey_now when the person wants a reading."New value: +"When the next survey runs, ISO 8601, strictly in the future; read as UTC without an offset. Later surveys keep that day and time at the pace of the frequency. On a PAUSED tracker it is kept and read back like anywhere else, and it is what makes the next start_tracker wait instead of surveying right away. It goes with a frequency that has a pace: on on_demand, leave it out and call survey_now when the person wants a reading."
  2. Changed3 schema fields changed
    • changedInput schema / properties / frequency / description
      Previous value: -"How often a survey runs."New value: +"How often a survey runs. on_demand puts the tracker on no schedule at all: starting it runs one survey, and every survey after that is one you ask for with survey_now. Pick it for a one-off reading, or whenever the person wants to decide each time; the other values keep a survey running on their own pace."
    • changedInput schema / properties / frequency / enum
      Previous value: -[
-  "monthly",
-  "weekly",
-  "daily"
-]New value: +[
+  "monthly",
+  "weekly",
+  "daily",
+  "on_demand"
+]
    • changedInput schema / properties / next_survey_at / description
      Previous value: -"When the next survey runs, ISO 8601, strictly in the future; read as UTC without an offset. Later surveys keep that day and time at the pace of the frequency."New value: +"When the next survey runs, ISO 8601, strictly in the future; read as UTC without an offset. Later surveys keep that day and time at the pace of the frequency. It goes with a frequency that has a pace: on on_demand, leave it out and call survey_now when the person wants a reading."
  3. Changed1 schema field changed
    • changedInput schema / properties / engines / description
      Previous value: -"The AI engines surveyed."New value: +"The AI engines surveyed. A check is priced per engine, in USD: chatgpt 0.10, claude 0.20, gemini 0.10, perplexity 0.10, mistral 0.10, grok 0.20. Claude and Grok read more sources per answer, and their check carries that. The amount for the whole tracker comes back as cost_per_survey_minor, so quote that one to the person rather than adding these up."
  4. Changed1 schema field changed
    • changedInput schema / properties / notify_on_survey / description
      Previous value: -"Email the account owner and managers each time a survey closes with fresh data, so the results reach them on their own. Off by default."New value: +"Email the account owner and managers each time a survey closes with fresh data, so the results reach them on their own. On by default; send false to keep this tracker silent."
  5. Changed1 schema field changed
    • changedInput schema / properties / engines / items / enum
      Previous value: -[
-  "chatgpt",
-  "claude",
-  "gemini",
-  "perplexity"
-]New value: +[
+  "chatgpt",
+  "claude",
+  "gemini",
+  "perplexity",
+  "mistral",
+  "grok"
+]
  6. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description discloses key behavioral traits beyond annotations: it is non-idempotent (update version creates new tracker id under certain conditions), non-destructive (only sends fields change, no survey runs, no credit spent on paused tracker), and open-world (accepts partial updates). It also explains side effects like next_survey_at timing and cost implications.

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 description is thorough but somewhat repetitive and lengthy, with phrases like 'That is the way to move a paused tracker...' echoing earlier content. While it provides valuable detail, it could be more concise. The structure is reasonably front-loaded with the main purpose, but the extended conditional clauses add redundancy.

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?

Given the complexity (13 parameters, versioning semantics, paused behavior, cost calculations), the description is quite complete. It covers edge cases and provides guidance on quoting costs and scheduling. However, it lacks explicit output/return value description since no output schema exists, and could mention that responses include new tracker ids or version_created details more explicitly.

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?

All 13 parameters are covered in the schema with detailed descriptions, including costs, enums, and nuanced behaviors (e.g., project_id omission behavior, next_survey_at on paused trackers). The description enhances schema with semantic details like 'flag yours as favorite' and 'quote cost_per_survey_minor'. Slight deduction because some cross-field constraints (e.g., custom_prompt required when analyst selected) are implicit in schema description rather than in the tool description.

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?

The description states a specific verb ('Update') and resource ('a tracker'), and scopes it clearly: only fields sent change, with detailed conditional semantics for versions and paused trackers. It distinguishes update_tracker from siblings like create_tracker, pause_tracker, and start_tracker.

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?

The description explains when to use it (update configuration, change fields) and includes nuanced conditions (version vs. no-version, paused tracker behavior, on_demand frequency). It doesn't explicitly say when NOT to use it (e.g., use create_tracker for new trackers), but the sibling context makes this clear and the description provides strong usage context.

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

All Epovest 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