JobMojito

Get merchant analytics

get_merchant_analytics

Read-onlyIdempotent

[Results] Get the merchant's daily event analytics.

Daily event-count time-series for a merchant over a date range (the admin-portal analytics events graph), scoped to your token's merchant (or a merchant_id override). Optionally drilled to a single interview. Capped at 1000 records per page. Note: only day/event combinations with a non-zero count are returned — any day/event pair absent from the response should be treated as a count of 0 by the caller.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of records to return (1–1000).
`offset`	No	Number of records to skip from the start of the result set.
`date_to`	Yes	End of the date range (inclusive), YYYY-MM-DD.
`date_from`	Yes	Start of the date range (inclusive), YYYY-MM-DD.
`merchant_id`	No	Optional merchant to scope to. Admins and sub-merchant operators only; other callers always use their token's merchant.
`interview_id`	No	Optional interview (interview_def_set) or position (position_def_set) id to drill the event counts down. The type is detected automatically: a position aggregates the daily counts across every interview that makes up the position; an interview filters to that single definition.
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Daily event counts for the requested range, ordered by day ascending. Only day/event combinations with a non-zero count are returned; missing combinations should be treated as 0 by the caller.
`pagination`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

changedInput schema / properties / conversation_id / description

Previous value: -"Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it."New value: +"Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request."

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / conversation_id

Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}

addedOutput schema / properties / _mcp_instructions

Added value: +{
+  "description": "Server-issued metadata for this conversation.",
+  "properties": {
+    "conversation_id": {
+      "description": "The server-issued conversation identifier.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedJul 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real behavioral value beyond that: a 1000-record page cap and, importantly, the zero-suppression rule that absent day/event pairs must be treated as count 0. It doesn't cover auth requirements or rate limits, keeping it short of a 5.

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?

Front-loaded with the core purpose, followed by scope, drill-down, cap, and the sparse-result caveat in a logical order. It is a little dense, and the '[Results]' prefix is unexplained, but every sentence carries weight.

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?

With an output schema present, return values need no explanation, and the description still covers scope, pagination cap, drill-down, and the zero-suppression caveat. The conversation_id lifecycle is fully specified in the schema parameter, so the definition is essentially complete for correct invocation.

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 coverage is 100%, so the schema already documents all parameters and the baseline is 3. The description reinforces scoping (merchant_id override) and drill-down behavior, but its phrase 'drilled to a single interview' omits the position_def_set case that the schema documents, adding marginal rather than corrective value.

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?

States a specific verb+resource: retrieve a merchant's daily event-count time-series over a date range, explicitly tied to the admin-portal analytics events graph. This is clearly distinguishable from siblings like get_merchant_credit_usage and get_merchant_status, which concern billing and account state, not event analytics.

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

Usage Guidelines4/5

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

Gives clear usage context: scoped to the token's merchant by default, with merchant_id override restricted to admins/sub-merchant operators, and optional drill-down to an interview/position. It stops short of naming alternative tools or stating when-not to use it, so no explicit alternatives are provided.

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

All JobMojito tools Inspect

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.