Skip to main content
Glama
Sign In
adhistory-mcp

adhistory-mcp

by OBrandon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Greenhouse, Lever & Ashby jobs

ats_jobs
Read-onlyIdempotent

List open jobs from Greenhouse, Lever, or Ashby boards and filter by remote status, location, or keywords. Returns structured job details, pay ranges, and application URLs.

Instructions

List open jobs from company job boards on Greenhouse, Lever or Ashby. Each item: ATS, company, title, department, team, location, remote flag, employment type, posted/updated dates, pay range when published, job and apply URLs, optional description text. Cost: $1.50 per 1,000 jobs on the user's Apify account; the default 20 jobs cost $0.03. Latency: usually 5-30 s.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "boards": "<boards>"
    },
    "name": "ats_jobs"
  }
}

Input Schema

NameRequiredDescriptionDefault
boardsYesJob board links, e.g. https://boards.greenhouse.io/airbnb, https://jobs.lever.co/palantir, https://jobs.ashbyhq.com/openai
max_itemsNoStop after this many jobs in total.
remote_onlyNoKeep only remote jobs.
search_textNoOptional. Keep jobs whose title, department or team contains all these words.
location_containsNoOptional. Keep jobs whose location contains this.
include_descriptionNoAdd the job description text. Same price.
max_items_per_boardNoOptional cap per board so one big company does not use the whole limit.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world and non-destructive semantics, yet the description adds real value beyond them: pricing ($1.50 per 1,000 jobs, default 20 jobs = $0.03) and expected latency of 5-30 s. It also notes that include_description carries no extra charge, which prevents a cost-driven decision error. Not a 5 only because failure modes for invalid or unsupported board URLs are unaddressed.

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 purpose, followed by output fields, then cost and latency in two short clauses with zero filler. The per-field enumeration is somewhat redundant given an output schema exists, which costs a little tightness.

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?

For a 7-parameter scraping tool with an output schema and full annotation coverage, the description covers platforms, result shape, cost and latency - everything needed to call it correctly. Remaining gaps are edge behavior: unsupported board formats, partial failures across multiple boards, and empty-result handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema cannot: the cost consequence of the default max_items value ($0.03 for 20 jobs) and the fact that description text is free. It does not clarify filter interaction (e.g. remote_only combined with search_text) or the difference between max_items and max_items_per_board beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List open jobs from company job boards on Greenhouse, Lever or Ashby" gives a specific verb and resource plus the platform scope, which implicitly separates it from workday_jobs and remote_jobs. It stops short of naming those siblings, so an agent must infer the boundary rather than being told it.

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 platform restriction and the filtering parameters imply when the tool applies, and the cost/latency lines help an agent decide whether the call is affordable. There is no explicit when-to-use or when-not-to-use statement, and no named alternative for Workday boards or non-board sources.

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

Deploy Server

Other Tools