Skip to main content
Glama

Create a feature rule

create_feature_rule

Save a feature rule: events matching its conditions count as feature_name, in past and future feature counts alike (they are worked out from the events). Check it with preview_feature_rule first. Every event it matches counts toward feature_name, including events other features already count: an event counts toward every feature that names it, and no rule takes events from another. Group pages with starts_with or matches on page_path (e.g. matches /products/*), or list pages in one any group (rather than several same-name rules), to give a funnel step a single feature to match. Funnels and flows only pick a rule up from today on. Uses a feature_rules slot (get_project slots_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": {
      "feature_name": "<feature_name>",
      "conditions": "<conditions>"
    },
    "name": "create_feature_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idNoThe setup run this change belongs to, from start_setup_run. Omit to start a new chat run (its id is returned).
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. Every item must match (AND); an item is one condition (property, operator, value) or an any group of 1 to 20 conditions of which at least one must match (OR). E.g. [{property: event_type, operator: equals, value: pageview}, {any: [{property: page_path, operator: equals, value: /pricing}, {property: page_path, operator: equals, value: /plans}]}] is a page view of either page. Numbers: [{property: event_type, operator: equals, value: pageview}, {property: page_path, operator: equals, value: /pricing}, {property: scroll_depth, operator: greater_than, value: '74'}] is a page view of /pricing read to at least 75 %. A page view gets its numbers when the visitor leaves or hides the page: feature counts catch up on later ones, a funnel or flow day counted shortly after midnight (project timezone) does not.
feature_nameYesThe feature name events matching the rule count as.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / conditions / description
      Previous value: -"Conditions. Every item must match (AND); an item is one condition (property, operator, value) or an any group of 1 to 20 conditions of which at least one must match (OR). E.g. [{property: event_type, operator: equals, value: pageview}, {any: [{property: page_path, operator: equals, value: /pricing}, {property: page_path, operator: equals, value: /plans}]}] is a page view of either page."New value: +"Conditions. Every item must match (AND); an item is one condition (property, operator, value) or an any group of 1 to 20 conditions of which at least one must match (OR). E.g. [{property: event_type, operator: equals, value: pageview}, {any: [{property: page_path, operator: equals, value: /pricing}, {property: page_path, operator: equals, value: /plans}]}] is a page view of either page. Numbers: [{property: event_type, operator: equals, value: pageview}, {property: page_path, operator: equals, value: /pricing}, {property: scroll_depth, operator: greater_than, value: '74'}] is a page view of /pricing read to at least 75 %. A page view gets its numbers when the visitor leaves or hides the page: feature counts catch up on later ones, a funnel or flow day counted shortly after midnight (project timezone) does not."
    • 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.8/5.0
Behavior5/5

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

Annotations already declare it is a non-read-only, non-destructive, non-idempotent write; the description adds substantial context beyond that: it consumes a feature_rules slot (get_project slots_left), it applies to past and future counts, it never steals events from other features, funnels and flows only see the rule from today on, and run_id grouping makes it undoable with the rest of a setup run.

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?

Front-loaded with the core semantics, then quota, retroactivity, and run_id guidance in a logical order with zero filler. It is dense and slightly repetitive ('every event it matches counts toward feature_name' vs 'no rule takes events from another'), but each sentence carries operational value.

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 write tool with no output schema, it covers everything an agent needs: quota consumption, retroactive vs funnel/flow timing, non-interference with other features, condition grouping strategy, and run_id behavior including the returned id. Nothing material is left unstated.

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, but the description adds meaning: feature_name's role in counting, the run_id lifecycle ('leave it out (never "") to start a new chat run, whose run_id is returned'), and the AND/OR structure and non-nesting of any groups. Minor gaps remain, such as not restating the project parameter's role.

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 ('Save a feature rule') and immediately defines the semantics: 'events matching its conditions count as feature_name, in past and future feature counts alike.' It also distinguishes itself from the sibling preview_feature_rule by telling the agent to check with it first, so the tool is identifiable 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Check it with preview_feature_rule first' names the alternative and the condition that selects it. It goes further, advising to group pages with starts_with/matches or a single any group 'rather than several same-name rules' so a funnel step has one feature to match, which is explicit when-to-use-this-shape guidance.

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