JobMojito

Get merchant credit usage

get_merchant_credit_usage

Read-onlyIdempotent

[Results] Get the merchant's credit usage.

Per-event credit-usage ledger for a merchant: every billable analytics event (interview, pre-screening, public avatar, simulation, …) that consumed credits, ordered most recent first. Scoped to your token's merchant, or a merchant_id override for admins / sub-merchant operators. The credits consumed by each event are in stats.credit_amount. Capped at 1000 records per page.

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.
`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 credit-usage ledger down to a single interview or position. The type is detected automatically: for a position the response combines pre-screening and interview-result credits across the whole position; for an interview it returns that interview's credit events (including simulations and report translations).
`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	Credit-consuming analytics events for the merchant, most recent first. Each row is one billable event; the credits it consumed are in stats.credit_amount.
`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/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds genuinely useful behavior beyond that — result ordering (most recent first), the 1000-record page cap, the admin-only override semantics, and where the consumed credit figure lives (stats.credit_amount). It stops short of describing auth failure modes or rate limits.

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?

A short bracketed marker, a one-line statement of purpose, then two dense sentences covering scope, ordering, field location and the page cap. Front-loaded and nearly waste-free, though the parenthetical event list ('interview, pre-screening, public avatar, simulation, …') is slightly loose.

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?

With an output schema present and full parameter coverage, the description only needs to add the things structured fields don't carry — ordering, the 1000-record cap, scoping rules, and where the credit amount is found — and it does all of that. Nothing an agent needs to invoke this read tool correctly is missing.

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%, so the schema already documents limit, offset, merchant_id, interview_id and conversation_id, including the interview-vs-position detection logic. The description largely restates the merchant scoping rule rather than adding new parameter meaning, so the baseline 3 is appropriate.

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?

The description states a specific verb and resource ('Get the merchant's credit usage') and immediately sharpens it into a per-event credit-usage ledger listing every billable analytics event that consumed credits, ordered most recent first. That level of detail lets an agent distinguish it from sibling reporting tools like get_merchant_analytics or get_merchant_status without opening any schema.

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

Usage Guidelines3/5

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

It gives scoping context ('scoped to your token's merchant, or a merchant_id override for admins / sub-merchant operators') and a pagination cap, which implies when the tool applies, but it never names an alternative or states when NOT to use it versus the other merchant/interview reporting tools. Usage is implied rather than instructed.

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.