Skip to main content
Glama

Epovest

by com.epovest
OverviewDiscussionsAdmin

Create a tracker

create_tracker

Create a tracker in draft. It measures nothing yet: call start_tracker to launch it against the prepaid credit balance. Validation rules and messages are the same as the app configurator. Omitted, next_survey_at means the first survey runs at start_tracker. For a single reading with nothing running afterwards, set frequency to on_demand: start_tracker runs one survey, and the next ones come from survey_now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesDisplay name of the tracker.
enginesYesThe 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.
promptsYesThe 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.
frequencyYesHow 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.
resolutionYesRepetitions of every question per engine and survey: hd=1, full_hd=3, 4k=6, 8k=9. Answers are stochastic; more repetitions sharpen the rates.
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.6/5.0
Behavior5/5

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

The annotations are all false and provide no safety signal, so the description carries the burden. It discloses the draft state, that creation itself measures nothing, that launching consumes prepaid credit, that an omitted next_survey_at means the first survey runs at start_tracker, and the on_demand one-shot behavior. This is valuable behavior beyond the schema and annotations.

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

Conciseness5/5

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

Four sentences with no filler. The purpose and draft state are front-loaded, and every sentence adds lifecycle, validation, or scheduling context that is not redundant with the schema.

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 tool with 12 parameters and no output schema, the description plus rich 100% schema coverage covers the creation workflow and key default behaviors. The main gap is that it never states what create_tracker returns, such as the new tracker's ID, which would matter when no output schema is present.

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. The description adds cross-parameter meaning not in the schema, especially the interaction between frequency, next_survey_at, start_tracker, and survey_now. It does not re-describe every parameter, but the schema already handles those details.

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 clear verb and resource: 'Create a tracker in draft.' It immediately distinguishes itself from later lifecycle tools by explaining the tracker 'measures nothing yet' until start_tracker is called. This makes its scope unmistakable next to start_tracker, survey_now, and update_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?

Gives explicit workflow guidance: 'call start_tracker to launch it against the prepaid credit balance' and explains when to choose on_demand for a single reading, with follow-ups via survey_now. It does not enumerate exclusions against the many other create_* siblings, but the draft-then-launch context is clear.

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