Skip to main content
Glama
thenavidm

Dub MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Track a sale

track_sale
Destructive

Record a sale conversion for a short link to attribute revenue to the correct click, customer, and payment processor.

Instructions

Track a sale for a short link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountNoThe amount of the sale in cents (for all two-decimal currencies). If the sale is in a zero-decimal currency, pass the full integer value (e.g. `1580` JPY). Learn more: https://d.to/currency
accountNoExact configured private workspace profile label; not a tenant or provider account ID.
clickIdNo[For direct sale tracking]: The unique ID of the click that the sale conversion event is attributed to. You can read this value from `dub_id` cookie.
confirmNoMust be true for the requested mutation or exclusive private output file.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
currencyNoThe currency of the sale. Accepts ISO 4217 currency codes. Sales will be automatically converted and stored as USD at the latest exchange rates. Learn more: https://d.to/currencyusd
metadataNoAdditional metadata to be stored with the sale event. Max 10,000 characters when stringified.
eventNameNoThe name of the sale event. Recommended format: `Invoice paid` or `Subscription created`.Purchase
invoiceIdNoThe invoice ID of the sale. Can be used as a idempotency key – only one sale event can be recorded for a given invoice ID.
customerNameNo[For direct sale tracking]: The name of the customer. If not passed, a random name will be generated (e.g. “Big Red Caribou”).
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.
customerEmailNo[For direct sale tracking]: The email address of the customer.
leadEventNameNoThe name of the lead event that occurred before the sale (case-sensitive). This is used to associate the sale event with a particular lead event (instead of the latest lead event for a link-customer combination, which is the default behavior). For direct sale tracking, this field can also be used to specify the lead event name.
customerAvatarNo[For direct sale tracking]: The avatar URL of the customer.
paymentProcessorNoThe payment processor via which the sale was made.custom
customerExternalIdNoThe unique ID of the customer in your system. Will be used to identify and attribute all future events to this customer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true and readOnlyHint=false, and the description adds nothing beyond them. It omits the required confirm flag behavior, the invoiceId idempotency key, and what side effects a tracked sale produces - all meaningful context for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words, so structurally clean. But for a 16-parameter tool with nested objects and overloaded naming (payload vs. flat fields), one sentence is under-specified rather than appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation with nested objects, a confirm gate, invoice-based idempotency, and multiple tracking modes, the description covers none of it. With no output schema, the agent gets no signal about results, attribution requirements, or the significance of the destructive annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every one of the 16 parameters (including the nested payload) is documented in the schema itself, so the baseline of 3 applies. The description contributes no additional parameter meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb+resource ('Track a sale') and the event type distinguishes it from siblings like track_lead and track_open. However, 'for a short link' is imprecise: no linkId exists in the schema and attribution is actually via clickId/customerExternalId, so the scope claim is slightly misleading rather than fully precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool, when not to, or how it relates to track_lead/track_open. Nothing explains whether a lead must precede the sale or which of the two tracking modes (direct vs. invoice-based) to pick.

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

Deploy Server

Other Tools