Skip to main content
Glama
Sign In

Nevent MCP

by io.github.nevent-dev
OverviewDiscussionsAdmin

nevent_event_sales_provenance

Read-only

Where the ticket sales of ONE event come from (nev-data-api, analytics warehouse). Pick the event with nevent_list_events (TICKETED events), then choose a view. summary (default): sales grouped by dimension — provider, distribution channel, purchase channel, promo code or marketing (UTM source > medium > campaign; drill down with level + parent, copying the group key from the previous response); returns the top groups and an «Otros» bucket. daily: day-by-day series stacked by one dimension (provider | distribution | purchaseChannel | promoCode). campaigns: sales attributed to Nevent campaigns through tracking links. overview: totals, coverage and freshness of each block — read it first to know how much of the data carries provenance. from and to (YYYY-MM-DD, purchase days in tz, default Europe/Madrid) are required. Currencies are never added together: omit currency for one block per currency, or pass EUR. population defaults to SETTLED_SALES (settled sales); ALL_REPORTED includes refunded purchases and is NOT collected revenue. Amounts are the gross reported by the source, never net. Provenance fields can be missing: coverage and «unknown» buckets are part of the answer, do not present them as zero or as organic. The data is a warehouse (lags the sale by the pipeline); the view reports its freshness. Scoped to the active tenant and its descendants by the session JWT.

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": {
      "event_id": "<event_id>",
      "from": "<from>",
      "to": "<to>"
    },
    "name": "nevent_event_sales_provenance"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesLast purchase day, YYYY-MM-DD, inclusive. Max range 3660 days.
tzNoIANA time zone that defines the purchase days. Default Europe/Madrid.
topNoGroups to list before collapsing the rest into «Otros». summary: 1-50, default 20. daily: 1-10, default 4.
fromYesFirst purchase day, YYYY-MM-DD (local day of tz). Required by every view.
viewNoWhat to return. summary (default): sales grouped by provider / distribution / purchase channel / promo code / marketing (UTM). daily: dense day-by-day series stacked by one distribution dimension. campaigns: sales attributed to Nevent campaigns through tracking links. overview: totals, coverage and data freshness per block.
levelNosummary with dimension=marketing only: source (default), medium or campaign. medium and campaign need parent.
parentNosummary with dimension=marketing and level=medium|campaign: the key of the group one level up, copied verbatim from a previous summary response.
searchNosummary only: filter groups by text (max 100 chars).
currencyNoISO 4217 currency (EUR). NONE selects purchases without currency. Omit to get one block per currency: amounts of different currencies are never added together.
event_idYesEvent ID (24-char hex). Get it from nevent_list_events.
dimensionNoGrouping dimension. summary: provider | distribution | purchaseChannel | promoCode | marketing (default marketing). daily: provider | distribution | purchaseChannel | promoCode (default distribution; marketing is not allowed). Not valid for overview/campaigns.
populationNoWhich purchases to count. SETTLED_SALES (default): settled sales. REFUNDED_FULL: fully refunded. REFUNDED_UNREPRESENTABLE: other refunds (may be partial, refunded amount unknown). ALL_REPORTED: all of the above plus unrecognised states; its gross includes refunded purchases, so it is NOT collected revenue.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare a safe read operation, and the description adds substantial business context beyond them: warehouse lag with self-reported freshness, coverage and 'unknown' buckets that must not be read as zero/organic, gross-never-net amounts, and strict no-cross-currency summing. It also discloses JWT-based tenant scoping.

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?

Purpose is front-loaded and nearly every clause carries real information, but the whole definition is one dense block of semicolons and parentheticals that would scan better broken into per-view lines. Length is justified by the 12-parameter surface, though.

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?

For a 12-parameter tool with no output schema, the description covers each view's output, drill-down mechanics, freshness, coverage caveats and currency rules. It stops short of describing response shape/size for summary and daily, which is the main remaining gap.

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; the description earns extra credit by explaining semantics the schema does not, such as copying the group key from the previous response for parent drill-down, omitting currency to get one block per currency, and ALL_REPORTED not being collected revenue.

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: 'Where the ticket sales of ONE event come from (nev-data-api, analytics warehouse).' The ONE-event scope plus the four named views clearly separates it from the generic analytics/campaign siblings 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 an explicit workflow: pick the event with nevent_list_events (TICKETED events), then choose a view, and even says to read 'overview' first to gauge provenance coverage. It also states exclusion-style rules (marketing not allowed for daily, population default, currency omission) rather than leaving them to inference.

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

All Nevent MCP 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