JobMojito

List report datasets and fields

list_report_fields

Read-onlyIdempotent

[Reports] List what a custom report can use on this account: datasets (interview results, invitations, position pipeline, ATS pipeline, credits, coaching sessions - only those the account and your role include), their dimensions (group by / conditions, with allowed values) and measures. A report definition may only use ids listed here. Custom reports are switched on per account by JobMojito; while they are off, every custom report tool is refused with 403 (built-in reports keep working) 'Custom reports are not enabled for this account.' Retrying does not change that; JobMojito switches them on.

Every argument in full, with examples: get_tool_reference.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_report_fields"
  }
}

Input Schema

Name	Required	Description
`dataset`	No	Only this dataset (e.g. positions, interview_results); the other keys are returned as usual.
`llm_model`	No	Your model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
`merchant_id`	No	Optional merchant to scope to. Admins and sub-merchant operators only; other callers always use their token's merchant.
`conversation_id`	No	The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Output Schema

Name	Required	Description
`limits`	Yes
`schema`	Yes
`datasets`	Yes
`can_share`	Yes
`where_ops`	Yes
`block_types`	Yes
`period_presets`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 9, 2026

changedInput schema / properties / dataset / description

Previous value: -"Only this dataset (e.g. positions, interview_results); the other keys are returned as usual. Unknown ids return no datasets."New value: +"Only this dataset (e.g. positions, interview_results); the other keys are returned as usual."

removedInput schema / properties / dataset / example
```
Removed value: -"positions"
```

addedInput schema / properties / llm_model

Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}

removedInput schema / properties / merchant_id / example

Removed value: -"28106cba-1c27-4e53-b149-32113e5e8e31"

removedOutput schema / properties / can_share / description

Removed value: -"false for hiring managers (read-only role)."

removedOutput schema / properties / datasets / description

Removed value: -"Datasets you may use: id, label, description, snapshot (ignores the period), and fields: id, kind (dimension | measure), type, label, description, values (allowed values of a text dimension), grains (date), table_only, format."

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / conversation_id / description

Previous 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."New value: +"The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics."

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / dataset

Added value: +{
+  "description": "Only this dataset (e.g. positions, interview_results); the other keys are returned as usual. Unknown ids return no datasets.",
+  "example": "positions",
+  "pattern": "^[a-z][a-z0-9_]{0,40}$",
+  "type": "string"
+}

AddedOct 18, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the account-level feature gate, the exact refusal mode (403 with the message "Custom reports are not enabled for this account."), that built-in reports keep working, and that retrying will not change the outcome. That is precisely the kind of failure-mode context an agent needs before calling.

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 most important content — what is returned and the id constraint — is front-loaded in the first two sentences, with the gating caveat following. The 403 paragraph is a bit long relative to its value, but each sentence (refusal message, built-in reports unaffected, retry futility) carries distinct information.

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?

An output schema exists, so return shape need not be described, and the description still characterizes the payload (datasets, dimensions, measures) and the role-based scoping. It is nearly complete for a read-only listing tool; only explicit routing against sibling report tools is absent.

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 all four parameters are already documented in the schema, including the dataset filter's "other keys are returned as usual" nuance. The description adds no parameter-level meaning of its own beyond pointing to get_tool_reference for full argument examples, so baseline 3 applies.

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 opens with a specific verb and resource ("List what a custom report can use on this account") and enumerates the returned content: datasets, their dimensions with allowed values, and measures. It also states the scoping rule (only datasets the account and the caller's role include), which distinguishes it from list_reports/get_report that deal with saved report definitions.

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?

"A report definition may only use ids listed here" gives clear when-to-use context: call this before authoring or saving a report. The 403 explanation tells the agent what to do when refused (nothing — retrying is futile). It stops short of explicitly naming alternatives such as list_reports or get_report.

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.