Skip to main content
Glama

Create a funnel

create_funnel

Save a funnel of 2 to 10 ordered steps. Its steps and trait_scope are final (update_funnel changes only its name and goal settings), and it counts visitors only from the day it is created: there is no history to fill in. So check every step with preview_funnel first, and create the funnels that matter early. A step on a data-track name that is not deployed yet matches nothing until the code ships: expected, not broken; tell the user. Uses a funnels slot (get_project slots_left). is_goal makes it a goal in the same call, with an optional goal_value (see update_funnel). 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": {
      "name": "<name>",
      "steps": "<steps>"
    },
    "name": "create_funnel"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesFunnel name, at most 100 characters (also the goal's name when is_goal).
stepsYes2 to 10 steps in order. Each step's filters is an object with any of event_type (pageview, click, form_submit, custom), page_origin, page_path (exact, as stored, e.g. /products/:id) and feature (a data-track name or feature rule name; met by any event that feature counts, so a feature rule with starts_with or matches on page_path makes one step out of many pages). All must match, exactly and case-sensitively. Final once created.
run_idNoThe setup run this change belongs to, from start_setup_run. Omit to start a new chat run (its id is returned).
is_goalNotrue makes the funnel a goal in the same call: its conversions (visitor-days reaching the last step that day) show per source and campaign. At most 5 goals per project; a goal is still one of the plan's funnels.
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).
goal_valueNoWhat one conversion is worth, in the project's currency (get_project). Omit for no value.
trait_scopeNoHow the funnel counts when it is read for one trait (get_funnel's trait). visitor (the default): a visitor whose events carried the trait anywhere that day counts under it at every step, also on pages that do not send it. Right for A/B tests (only the tested page sends variant-b, the purchase on the thank-you page still counts for variant B) and for traits that describe the visitor. step: a step counts under the trait only when the event that met that step carried it, for a trait that describes the moment (an upgrade funnel read for plan-free, whose last page sends plan-pro). Final once created, like the steps. Leave it out unless the user wants step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / goal_value
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "What one conversion is worth, in the project's currency (get_project). Omit for no value.",
      +  "properties": {
      +    "amount": {
      +      "description": "kind fixed only, and then required: the amount per conversion in the project's currency (get_project), as a decimal string with at most 3 decimals and no sign, currency or separators, e.g. \"40\" or \"19.99\". It applies to every counted day, past ones included.",
      +      "type": "string"
      +    },
      +    "detail": {
      +      "description": "kind detail only, and then required: attrs.KEY, the detail the last step's event already sends with the amount (e.g. attrs.total from track('Purchase', { total: 34.5 })). Revenue counts from the day it is set: earlier days cannot be recounted. Values that are not plain decimal numbers count as nothing.",
      +      "type": "string"
      +    },
      +    "kind": {
      +      "description": "none (no value), fixed (an amount per conversion) or detail (a detail of the last step's event is the revenue).",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "kind"
      +  ],
      +  "type": [
      +    "null",
      +    "object"
      +  ]
      +}
    • addedInput schema / properties / is_goal
      Added value: +{
      +  "description": "true makes the funnel a goal in the same call: its conversions (visitor-days reaching the last step that day) show per source and campaign. At most 5 goals per project; a goal is still one of the plan's funnels.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / name / description
      Previous value: -"Funnel name."New value: +"Funnel name, at most 100 characters (also the goal's name when is_goal)."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: it discloses irreversibility of steps and trait_scope, that visitor counting starts at creation with no backfill, that an undeployed data-track name matches nothing until code ships ('expected, not broken'), that a funnels slot is consumed, and that goal_value applies retroactively to past counted days. These are exactly the non-obvious traits an agent needs before a non-idempotent write.

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-loads the most consequential fact (finality of steps) and packs slot cost, goal coupling and run_id semantics into tight sentences with no filler. It is dense and somewhat run-on across long clauses, which costs a little readability, but essentially every sentence carries unique operational 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 7-parameter non-idempotent write with no output schema, the description covers everything an agent needs: side effects (slot use, goal creation), irreversibility, return value of run_id, cross-tool dependencies (preview_funnel, start_setup_run, get_project, update_funnel), and the edge case of not-yet-deployed data-track names.

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 real meaning beyond it: the 'never ""' rule for run_id and the undo-together rationale, 'leave it out unless the user wants step' for trait_scope, and 'see update_funnel' for goal_value. It does not restate the step filter vocabulary, which the schema already handles in depth.

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 plus a hard scope constraint: 'Save a funnel of 2 to 10 ordered steps.' It immediately distinguishes itself from update_funnel ('changes only its name and goal settings') and preview_funnel, so an agent can separate create from modify and from validate without reading 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?

Gives explicit sequencing ('check every step with preview_funnel first, and create the funnels that matter early'), explicit run_id routing with an exclusion ('Pass run_id from start_setup_run ... leave it out (never "") to start a new chat run'), and names the tool to consult for slot availability (get_project slots_left). Both when-to-use and when-not-to-use are covered.

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