Skip to main content
Glama

Flowsery

by com.flowsery
OverviewDiscussionsAdmin

Track Payment

track_payment
Destructive

Record an analytics payment; this never charges a customer, moves money, or issues a refund. Revenue appears in get_overview, get_timeseries, and the visitor profile. Skip it when the site's provider (Stripe, LemonSqueezy, Polar, and other connected providers) is tracked automatically; use track_goal for conversions without revenue. transactionId must be unique: a repeated id is rejected, not deduplicated. A new payment also records a payment goal completion (free_trial when amount is 0); isRenewal skips that. isRefund with an existing transactionId overwrites that payment's recorded refund amount and any supplied customer attribution instead of adding a row. Attribution looks up a known visitor by visitorUid, customerId, or email; with no match the revenue is kept but its source shows as Unknown. Requires websiteId or domain with a workspace token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoCustomer name
emailNoCustomer email
amountYesPayment amount in major currency units (e.g. 29.99). With isRefund, the amount refunded. 0 records a free_trial goal instead of a payment goal.
domainNoWebsite domain from list_websites (e.g. "example.com"). Alternative to websiteId with a workspace token.
currencyYesCurrency code (e.g. "USD", "EUR")
isRefundNoTrue to record a refund. With an existing transactionId, marks that payment refunded by amount instead of creating a new record.
isRenewalNoTrue for recurring/renewal charges. Renewals are counted in revenue but do not record the automatic payment goal.
timestampNoISO 8601 time the payment happened (e.g. "2026-01-15T10:30:00Z"), for backfilling. Defaults to now.
websiteIdNoWebsite ID from list_websites. Required with a workspace token unless domain is given; ignored with a website key.
customerIdNoCustomer ID from the payment provider. Also used to find the visitor when visitorUid is absent.
sessionUidNoSession ID for the current visitor session
visitorUidNoVisitor UID from the _fs_vid cookie. Strongly recommended: without it (or customerId/email matching a known visitor) the payment is attributed to Unknown
workspaceIdNoWorkspace to act in: an id from list_workspaces. Omit to use the default workspace. Use the same workspaceId for every call about the same workspace, since ids from one workspace do not exist in another
transactionIdYesUnique transaction ID from your payment provider. Must not repeat across payments; reuse it only with isRefund to mark that payment refunded.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoObject with status and data: a confirmation message once the payment is stored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. Changed1 schema field changed
    • addedInput schema / properties / timestamp
      Added value: +{
+  "description": "ISO 8601 time the payment happened (e.g. \"2026-01-15T10:30:00Z\"), for backfilling. Defaults to now.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "Workspace to act in: an id from list_workspaces. Omit to use the default workspace. Use the same workspaceId for every call about the same workspace, since ids from one workspace do not exist in another",
+  "type": "string"
+}
  4. Changed9 schema fields changed
    • changedInput schema / properties / amount / description
      Previous value: -"Payment amount (e.g. 29.99)"New value: +"Payment amount in major currency units (e.g. 29.99). With isRefund, the amount refunded. 0 records a free_trial goal instead of a payment goal."
    • changedInput schema / properties / customerId / description
      Previous value: -"Customer ID from payment provider"New value: +"Customer ID from the payment provider. Also used to find the visitor when visitorUid is absent."
    • changedInput schema / properties / domain / description
      Previous value: -"Website domain to query. Required when using a workspace token unless websiteId is provided."New value: +"Website domain from list_websites (e.g. \"example.com\"). Alternative to websiteId with a workspace token."
    • changedInput schema / properties / isRefund / description
      Previous value: -"True for refunded payments"New value: +"True to record a refund. With an existing transactionId, marks that payment refunded by amount instead of creating a new record."
    • changedInput schema / properties / isRenewal / description
      Previous value: -"True for recurring/renewal payments"New value: +"True for recurring/renewal charges. Renewals are counted in revenue but do not record the automatic payment goal."
    • changedInput schema / properties / transactionId / description
      Previous value: -"Unique transaction ID from your payment provider"New value: +"Unique transaction ID from your payment provider. Must not repeat across payments; reuse it only with isRefund to mark that payment refunded."
    • changedInput schema / properties / visitorUid / description
      Previous value: -"Visitor UID from _fs_vid cookie — strongly recommended for accurate revenue attribution"New value: +"Visitor UID from the _fs_vid cookie. Strongly recommended: without it (or customerId/email matching a known visitor) the payment is attributed to Unknown"
    • changedInput schema / properties / websiteId / description
      Previous value: -"Website ID to query. Required when using a workspace token unless domain is provided."New value: +"Website ID from list_websites. Required with a workspace token unless domain is given; ignored with a website key."
    • changedOutput schema / properties / result / description
      Previous value: -"Confirmation of the recorded payment."New value: +"Object with status and data: a confirmation message once the payment is stored."
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=true), and the description goes well beyond them: it states no money moves, that repeated transactionIds are rejected rather than deduplicated, that isRefund overwrites an existing record, that a payment auto-creates a goal, and that unmatched attribution falls back to Unknown. This is exactly the mutation semantics an agent needs before calling.

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?

Dense but front-loaded, leading with what the tool is not (never charges, moves money, refunds) before edge cases. Every sentence carries usable information, though the single block paragraph could be broken up for scanability.

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 14-parameter mutation tool with an output schema present, the description covers the risky behaviors, attribution fallback, goal side effect, and identifier prerequisites. Nothing an agent needs to invoke it safely 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, but the description adds real semantic detail the schema lacks: the rejected-not-deduplicated behavior of transactionId, the overwrite semantics of isRefund, the free_trial goal on zero amount, and the attribution lookup order. Some phrasing (websiteId/domain requirement) restates schema, keeping it from a 5.

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+resource ('Record an analytics payment') and immediately scopes it against siblings by naming track_goal as the no-revenue alternative. An agent can distinguish this from delete_payments, get_overview, etc. without opening a 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 when-not guidance ('Skip it when the site's provider is tracked automatically') and a named alternative for the adjacent case ('use track_goal for conversions without revenue'). Prerequisites (websiteId or domain with a workspace token) are also stated.

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

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