Skip to main content
Glama

company_customer_cohorts

Build customer cohort tables by month of first order, calculating repeat rates, revenue, acquisition costs, payback months, and value-to-cost ratios for a specified window.

Instructions

Build the sealed customer cohort table for the window: every customer first seen in the window grouped by the month of their first persisted order, with the orders, repeat rate, revenue per customer and its curve by month since, contribution per customer at the window's margin report margin, the acquisition spend per month from the persisted cost registers, the cost per acquired customer, the months to pay it back, and the value-to-cost ratio; returning customers from before the window are counted separately (payload: optional window_start, window_end).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nowNo
engineNo
operationNobuild
entity_refNo
project_idYes
bundle_jsonYes
payload_jsonNo{}

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It mentions 'sealed' implying an immutable/finalized output, and 'returning customers from before the window are counted separately' which adds behavioral context. However, it does not mention side effects (e.g., overwriting existing data), authentication needs, rate limits, or idempotency. It provides some value but is not comprehensive.

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

Conciseness2/5

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

The description is a single long run-on sentence with many clauses and a dense list of metrics. It is not tightly structured or concise; it would benefit from breaking into clear sentences. The core purpose is front-loaded, but the overall presentation is verbose and hard to parse quickly.

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?

There is an output schema, so return values are covered, but the description fails to explain the required parameters (project_id, bundle_json) and the structure of payload_json. For a complex tool with 7 parameters, this is a significant gap. No side effects or operational context is provided.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only mentions 'optional window_start, window_end' within the payload, but does not explain required parameters like project_id and bundle_json, or the payload_json structure. With 7 parameters and 2 required, the description leaves most parameter semantics unexplained.

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?

The description clearly states the action ('Build') and the resource ('sealed customer cohort table') with a defined scope ('for the window'). It lists specific metrics (orders, repeat rate, revenue per customer, contribution, acquisition spend, payback months, value-to-cost ratio) which distinguishes it from a generic cohort tool. However, it does not explicitly differentiate from the similar sibling 'company_cohorts'.

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?

The description does not provide any guidance on when to use this tool versus alternatives. It implies usage through the description of the output but does not mention when not to use it or suggest any sibling tools. No exclusions or prerequisites are stated.

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