Skip to main content
Glama

Render the customer lifetime value ranking

well_render_customer_ltv
Read-only

Draw the customer lifetime value (LTV) ranking as a bar chart card: one bar per customer, the highest first.

Call it once, after well_measure_customer_ltv, and send no figure. It runs the measure itself for the workspace of the call and draws that result, so every name, flag and LTV on the card is the server's. You pass only: window as the measure's result echoed it (from, to and month_count), counterparty_alias_sets exactly as you passed them to the measure, the currency the card draws, left_off_currencies and conversions. Read the figures for your answer from the measure's result, not from this tool's. Do not call it when the measure returned no row: say there is nothing to rank instead.

One currency per card. Set currency to the currency the card draws. Every other currency in the measure's currencies goes in exactly one of two places. Convert it: add a conversions entry with the rate into currency and its date, from the currency conversion step, and the tool applies it to each customer's LTV. Or leave it off: name it in left_off_currencies, which keeps its customers off the card, because Well has no rate for it or because converting it is not allowed. The card's own currency is never converted and never left off. A card that converts draws only when no currency on it, the card's own currency included, has more than 100 customers, because the measure cuts rows past that. Otherwise draw the card's own currency alone and name the others in left_off_currencies.

The card draws at most 12 customers, never a summed "other" bar, and its small form quotes the average LTV per customer. The result states average_ltv, customer_count (the customers the average covers) and left_out_count (customers not drawn): say how many customers the card leaves out when it is above zero.

REFUSED rather than drawn:

  • a window that reaches the running month or covers more than 60 months

  • a measured currency that is neither converted nor left off, or a currency the measure did not find

  • the card's own currency in left_off_currencies or in conversions

  • a rate more than 1% away from Well's stored rate for the pair on its rate date, a rate dated outside the window's last complete month, or two rates for one currency

  • a card that converts when the measure cut rows from a currency on it

Because the measure runs again here, a ranking reads the invoices twice. That is by design: it is what ties the card to the server's figures.

When party_scope.side_unknown is true the workspace has no resolved own company, so no side filter was applied and the ranking covers invoices on both sides. Say the side is unknown, never that these are the customers' figures.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
windowYesThe `window` the measure's result echoed, unchanged: `from` inclusive, `to` exclusive, both YYYY-MM-01, and its `month_count`.
currencyYesThe one currency the card draws.
conversionsYesOne rate for each measured currency the card converts into its own.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
left_off_currenciesYesThe measured currencies the card does not draw. Their customers are not on the card.
counterparty_alias_setsNoThe alias sets passed to the measure, unchanged. Omit when the measure had none.

Output Schema

NameRequiredDescriptionDefault
ruleYes
windowYes
entriesYes
partialYes
successYes
currencyYes
portfolioYes
average_ltvYes
computed_byYes
conversionsYes
party_scopeYesWhat the receivable side resolved to. `side_unknown: true` means the workspace resolved no own company, so NO side filter was applied (`applied: false`) and the ranking covers invoices on both sides — say the side is unknown, never that these are the customers' figures. `null` when no read reported a scope resolution.
young_countYes
customer_countYes
left_out_countYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
omitted_row_countYes
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
left_off_currenciesYes
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
omitted_drawn_row_countYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • removedOutput schema / properties / average_ltv / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / average_ltv / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / entries / items / properties / label / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / entries / items / properties / label / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / portfolio / properties / lifespan_months / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / portfolio / properties / lifespan_months / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / portfolio / properties / monthly_churn / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / portfolio / properties / monthly_churn / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed4 schema fields changed
    • changedInput schema / properties / window / description
      Previous value: -"The window the measure read, unchanged: `from` inclusive, `to` exclusive, both YYYY-MM-01."New value: +"The `window` the measure's result echoed, unchanged: `from` inclusive, `to` exclusive, both YYYY-MM-01, and its `month_count`."
    • addedInput schema / properties / window / properties / month_count
      Added value: +{
      +  "description": "The measure's own count of the window's months, when you send its `window` back as it is.",
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
    • addedOutput schema / properties / window / properties / month_count
      Added value: +{
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
    • changedOutput schema / properties / window / required
      Previous value: -[
      -  "from",
      -  "to"
      -]New value: +[
      +  "from",
      +  "to",
      +  "month_count"
      +]
  3. Changed3 schema fields changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
    • addedOutput schema / properties / party_scope
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": false,
      +      "properties": {
      +        "applied": {
      +          "type": "boolean"
      +        },
      +        "requested": {
      +          "enum": [
      +            "purchase",
      +            "sales",
      +            "intra_self",
      +            "unattributed"
      +          ],
      +          "type": "string"
      +        },
      +        "side_unknown": {
      +          "type": "boolean"
      +        }
      +      },
      +      "required": [
      +        "requested",
      +        "applied",
      +        "side_unknown"
      +      ],
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "What the receivable side resolved to. `side_unknown: true` means the workspace resolved no own company, so NO side filter was applied (`applied: false`) and the ranking covers invoices on both sides — say the side is unknown, never that these are the customers' figures. `null` when no read reported a scope resolution."
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "window",
      -  "currency",
      -  "entries",
      -  "average_ltv",
      -  "customer_count",
      -  "left_out_count",
      -  "young_count",
      -  "portfolio",
      -  "conversions",
      -  "left_off_currencies",
      -  "rule",
      -  "omitted_row_count",
      -  "omitted_drawn_row_count",
      -  "partial",
      -  "computed_by",
      -  "success"
      -]New value: +[
      +  "window",
      +  "currency",
      +  "entries",
      +  "average_ltv",
      +  "customer_count",
      +  "left_out_count",
      +  "young_count",
      +  "portfolio",
      +  "conversions",
      +  "left_off_currencies",
      +  "rule",
      +  "omitted_row_count",
      +  "omitted_drawn_row_count",
      +  "partial",
      +  "party_scope",
      +  "computed_by",
      +  "success"
      +]
  4. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • addedOutput schema / properties / newly_connected
      Added value: +{
      +  "description": "Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "type": "string"
      +      },
      +      "service_id": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "service_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  6. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare it as a safe read, but the description adds substantial behavior: a full REFUSED list (windows reaching the running month, >60 months, unmatched currencies, rates >1% off stored rates), the 12-customer draw cap, no summed "other" bar, the 100-customer cut interaction, and the deliberate double read of invoices. It also discloses the `party_scope.side_unknown` caveat and what the agent must say in that case.

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?

The critical instruction (call once, after the measure, send no figure) is front-loaded and bolded, and the REFUSED list is easy to scan. It is long, and the currency rules are stated twice — once in prose ("The card's own currency is never converted and never left off") and again in the REFUSED list — which is mild redundancy rather than a structural flaw.

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 an 8-parameter tool with nested objects and a large currency enum, the description covers invocation order, input provenance, refusal conditions, output interpretation (average_ltv, customer_count, left_out_count) and the double-read behavior. An output schema exists, but the description still tells the agent how to phrase the answer from those fields, so nothing material is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds meaning the schema cannot convey: `window` must be the measure's echoed value, `counterparty_alias_sets` must be byte-identical to what the measure received, `currency`/`left_off_currencies`/`conversions` are mutually exclusive placements for every other currency, and the card's own currency may never appear in the latter two. That is genuine semantic guidance, not restatement.

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?

Names a specific verb and artifact ("draw the customer lifetime value ranking as a bar chart card: one bar per customer, the highest first") and explicitly separates itself from the sibling `well_measure_customer_ltv` by stating it re-runs the measure itself. An agent can tell instantly that this is the charting counterpart to the measure, not a data-fetch tool.

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 ("Call it once, after `well_measure_customer_ltv`, and send no figure"), an explicit negative case ("Do not call it when the measure returned no row: say there is nothing to rank instead"), and workspace-token branching (call directly for one workspace, pass `workspace_id` for several). No inference required.

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