Skip to main content
Glama

volanea_track_event

Send a product event exactly as the user's app would (POST /v1/events). Auto-creates the contact if unknown, and SYNCHRONOUSLY fires any workflow whose trigger is event:<name> plus any matching webhooks — so this is how you verify an event-triggered automation for real. Also useful to seed a test contact — but note that a contact created this way is tagged as a test artifact and is EXCLUDED from segment evaluation and campaign audiences, so it will never appear in a volanea_create_segment dryRun count or a campaign's recipient list, whatever its fields say. System prefixes (email./contact./segment./workflow.) are reserved.

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>",
      "email": "<email>"
    },
    "name": "volanea_track_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataNoEvent payload; available to workflows as {{variables}}.
nameYesEvent name, e.g. "user.signed_up". Use the same name the app will send.
emailYesContact's email address.

Output Schema

NameRequiredDescriptionDefault
codeNoMachine-readable failure code to branch on. Present only when success is false.
dataNoPresent when success is true.
errorNoHuman-readable failure reason. Present only when success is false.
successYesFalse when the call failed; read `error` and `code` in that case.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing the write side effects in detail: auto-creating unknown contacts, synchronous workflow and webhook firing, the test-artifact tag, and the resulting exclusion from segment dryRun counts and campaign audiences. The reserved-prefix rule is a behavioral constraint an agent could not infer from structured fields.

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 core action and endpoint, then layers side effects and the test-artifact caveat in a logical order. It is dense but every sentence carries information; the capitalized SYNCHRONOUSLY and EXCLUDED emphasize genuinely load-bearing distinctions rather than padding.

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?

An output schema exists, so return values need not be explained, and the description covers the mutation side effects and audience-exclusion consequences thoroughly. Minor gaps remain: it doesn't say what error occurs if a reserved prefix is used, nor whether repeated sends are deduplicated.

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: the event `name` must match what the app sends, and the system prefixes (email./contact./segment./workflow.) are reserved, which is a naming constraint absent from the schema. The `data` payload's role as workflow {{variables}} is already in the schema, so no extra credit there.

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 specific verb and resource ('Send a product event ... POST /v1/events') and immediately names the distinguishing capability: it synchronously fires workflows triggered by `event:<name>` plus matching webhooks. That separates it from siblings like volanea_test_workflow and volanea_test_webhook_delivery, which verify things in simulation rather than by emitting a real event.

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 clear when-to-use framing ('this is how you verify an event-triggered automation for real') and a secondary use case ('seed a test contact') with an explicit caveat about test-artifact exclusion. It does not name sibling alternatives by name (e.g., cleanup via volanea_cleanup_test_data after seeding), so the routing guidance is clear but not exhaustive.

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