Skip to main content
Glama
Sign In

Privatrak

by com.privatrak
OverviewDiscussionsAdmin

Preview a feature rule

preview_feature_rule
Read-onlyIdempotent

Check a feature rule before saving it; saves nothing. matched_events: events the conditions match in the range, pageviews included. Rules have no precedence: saving counts all of them toward feature_name, whatever else names them. already_in_feature: those feature_name already counts; new_events: the rest; unassigned_events: those no feature names yet. also_counted_as: other features that also count some of them and keep doing so (not a conflict; a long list can mean too broad). With feature_name, feature_total_after_save is what list_features will show once saved. top_elements shows what matched. Events, not visitors. At most 92 days per call. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

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": {
      "conditions": "<conditions>"
    },
    "name": "preview_feature_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast day, YYYY-MM-DD in the project's timezone, inclusive. Default: yesterday, the last complete day.
fromNoFirst day, YYYY-MM-DD in the project's timezone, inclusive. Default: 27 days before 'to'. At most 92 days in one call.
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).
conditionsYesConditions, exactly as for creating a rule: every item must match (AND); an item is one condition (property, operator, value) or an any group of conditions of which at least one must match (OR).
feature_nameNoThe feature name you would save the rule under. Optional; with it the answer includes the feature's total after saving.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / conditions / items / properties / operator / description
      Previous value: -"A plain condition's operator: equals, contains, starts_with or matches (a whole-value pattern where * stands for any text, e.g. /products/*; a pattern of only * is refused). Matching is case-sensitive (/Pricing does not match /pricing) except on query.utm_source, query.utm_medium and query.ref, which ignore case."New value: +"A plain condition's operator: equals, contains, starts_with or matches (a whole-value pattern where * stands for any text, e.g. /products/*; a pattern of only * is refused). Matching is case-sensitive (/Pricing does not match /pricing) except on query.utm_source, query.utm_medium and query.ref, which ignore case. scroll_depth and time_on_page_seconds take equals, greater_than, less_than (both strict, > and <: scroll_depth greater_than 74 is 75 or more) or exists (has a value), with a whole number in range as the value, digits only; no text operator. attrs.KEY also takes greater_than and less_than (strict), comparing the detail as a number: attrs.total greater_than 100, with a plain decimal number as the value (100, 34.5, -3; no exponent or separators); an event without the detail or whose detail is not a number matches neither. greater_than, less_than and exists work on nothing else."
    • changedInput schema / properties / conditions / items / properties / property / description
      Previous value: -"A plain condition's property: event_type, page_origin, page_path, element_tag, element_selector, element_selector_generalized, element_text, referrer (the referring URL; sent with page views only) or query.PARAM (one URL parameter, e.g. query.utm_source; on every event of that page, clicks included; missing means no match). For 'came from X' add event_type equals pageview. Leave out in an any group."New value: +"A plain condition's property: event_type, page_origin, page_path, element_tag, element_selector, element_selector_generalized, element_text, referrer (the referring URL; sent with page views only), query.PARAM (one URL parameter, e.g. query.utm_source; on every event of that page, clicks included; missing means no match), attrs.KEY (one detail of the event: a data-track-KEY attribute or a key of track()'s details, e.g. attrs.total; missing means no match), or a page view's numbers: scroll_depth (how far down the page the visitor got, whole percent 0-100: 0 never scrolled, 100 the bottom) and time_on_page_seconds (active seconds on the page, 0-1800), which only page views carry and which arrive when the visitor leaves or hides the page (until then, or from an older tracker, none, which no comparison matches). For 'came from X' add event_type equals pageview. Leave out in an any group."
    • changedInput schema / properties / conditions / items / properties / value / description
      Previous value: -"A plain condition's value, non-empty."New value: +"A plain condition's value, non-empty, except for exists, which takes none. For scroll_depth and time_on_page_seconds a whole number such as 74; for greater_than or less_than on attrs.KEY a plain decimal number such as 100 or 34.5."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly and idempotent, but the description goes well beyond them: it explains that rules have no precedence, that saving counts all matching rules toward feature_name, that also_counted_as is not a conflict but a breadth signal, and what feature_total_after_save will look like in list_features. With no output schema, this return-value disclosure is exactly the burden the description needs to carry.

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?

The critical fact — nothing is saved — is front-loaded, and the output-field glossary is compact. Some tail material (92-day limit, YYYY-MM-DD, timezone pointer) duplicates schema text and could be trimmed without losing information.

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 preview tool with no output schema and a deeply nested conditions parameter, the description supplies the semantic layer: what each response field means, how counting and precedence work, and the caveat about broad rules. Nothing an agent needs to interpret the preview correctly 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 the baseline is 3; the description still adds meaning by explaining that feature_name changes the response (it produces the post-save total) and that from/to default to the last 28 complete days. The 92-day cap and date formats restate the schema rather than extend it.

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 opening clause names a specific verb and resource — "Check a feature rule before saving it; saves nothing" — which immediately distinguishes it from create_feature_rule and update_feature_rule in the sibling list. An agent can select it without opening the schema.

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 phrase "before saving it" establishes the pre-write validation context clearly, and the closing note on omitting from/to gives a default usage path. It stops short of explicitly naming create_feature_rule/update_feature_rule as the follow-up alternatives, so routing is strongly implied rather than stated.

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

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