Selenios

Export hiring history

export_hiring_history

Read-onlyIdempotent

Export the organization's full hiring history to an Excel workbook, traceable from the opening of each vacancy to the hire. Three sheets joined by ID columns: vacancies (opening, first publication, closing and cancellation dates, status, opening reason, owners, target hires, number of applications and hires, days to first hire, and the job request it came from with its requester and approval date); applications (candidate, source, applied date, current stage, outcome, hire or rejection date and reason, score, days in process); stage movements (one row per stage change with its date, from/to stage, who moved it, rejection reason and days in the previous stage). Filters vacancies by opening date or by id. Up to 20000 applications per file; a larger history is exported in parts by narrowing the range. Dates are in UTC. The file is personal and can be downloaded for 24 hours.

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": "export_hiring_history"
  }
}

Input Schema

Name	Required	Description
`openedTo`	No	Only vacancies opened on or before this date (YYYY-MM-DD).
`openedFrom`	No	Only vacancies opened on or after this date (YYYY-MM-DD).
`jobDescriptionIds`	No	Only these vacancies, by job position ID.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / jobDescriptionIds / description

Previous value: -"Only these vacancies, by id (from list_jobs)."New value: +"Only these vacancies, by job position ID."

First observedOct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already establish that this is a non-destructive, read-only operation, and the description adds substantial context: the workbook structure, the three sheets and their fields, the 20,000-application cap, the part-export strategy, UTC dates, and the 24-hour personal download window. This is behaviorally rich beyond the annotations and consistent with them.

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 purpose and output artifact are front-loaded, and the long field enumeration is justified because there is no output schema. The single dense paragraph is information-rich but slightly harder to scan than a more structured presentation would be.

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 a complex export tool with no output schema, the description covers the output structure, included fields, filtering behavior, size limits, timezone, and file lifetime. An agent has enough information to invoke it correctly and explain the resulting file.

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 three parameters are already documented in the schema. The description adds that filters apply to vacancies by opening date or id and that narrowing the range is how larger histories are split, but it does not add format or semantic detail beyond the schema.

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 and resource: export the organization's full hiring history to an Excel workbook. It distinguishes the scope from sibling retrieval tools by describing a complete, multi-sheet historical export rather than a single record or metric.

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?

The description makes clear the tool is for a full hiring-history export and explains how to handle large histories by narrowing the date or vacancy range. It does not explicitly name alternatives such as get_dashboard_metrics or search_candidates, so the when-not-to-use guidance is implicit.

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

All Selenios 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.

Resources

Need Help?