Skip to main content
Glama

list_deleted_postings

List deleted Lever postings within a required 30-day deleted_at window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults per page. Lever accepts 1-100; default is endpoint-specific.
cursorNoLever pagination offset token from a previous response. Use next_cursor from the prior tool result.
deleted_at_endYesExclusive upper bound in Unix milliseconds. Window may not exceed 30 days.
deleted_at_startYesInclusive lower bound in Unix milliseconds.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of transparency. It discloses the 30-day window limitation and the fact that only deleted postings are returned, which are useful behavioral traits. However, it does not explicitly state that the operation is read-only, nor does it describe pagination behavior or what happens if the window constraint is violated.

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

Conciseness5/5

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

The description is a single, clear sentence that front-loads the action and resource. Every word contributes: it specifies 'deleted,' 'Lever postings,' and the essential 30-day window constraint. There is no redundancy or filler.

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?

The description, combined with a fully detailed schema, provides enough context for a list tool. It clearly states what is listed and the critical time-window requirement. It does not describe the return format, but since no output schema exists and 'list' implies a collection of postings, this is a minor gap.

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 baseline is 3. The description adds a small amount of context by highlighting the 'required 30-day deleted_at window,' which aligns with the schema's own note on deleted_at_end. It does not provide additional meaning for limit or cursor beyond what the schema already states.

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 clearly states a specific verb ('List') and a distinct resource ('deleted Lever postings'). It also introduces the key constraint of a required 30-day deleted_at window, which distinguishes this tool from sibling tools like list_postings, list_deleted_applications, or list_deleted_opportunities.

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?

The description implies usage: when you need to retrieve deleted postings within a 30-day window. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for non-deleted postings, use list_postings). The required window is a constraint but not a comparative guideline.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation4/5

Most tools target distinct resource-action combinations, but the sheer count (108) and the presence of closely related tools like list_opportunity_feedback / get_opportunity_feedback may cause occasional agent confusion.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern (e.g., create_*, get_*, list_*, update_*, delete_*, add_*, remove_*). Minor exceptions like apply_to_posting still fit the overall structure.

Tool Count2/5

With 108 tools, the surface is excessively large for most agent workflows. Many tools could be merged or removed without losing essential functionality, leading to decision overload.

Completeness5/5

The tool set covers the full Lever API surface comprehensively, including opportunities, postings, requisitions, users, webhooks, templates, files, and compliance data, leaving no obvious gaps.

Resources