Skip to main content
Glama

Job Postings

JobPostings
Read-only

Job Postings: Job Postings is a jobs API that returns the open positions on a company's public career board. Every job comes back in the same shape: title, department, team, locations, remote and workplace type, employment type, posting date and apply link. Filter by keyword, location, department, employment type, posting date or remote. Paid plans add the full job description and salary ranges where the company publishes them. (Cost: 10 credits)

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

Input Schema

NameRequiredDescriptionDefault
urlNoA link to the company's careers board or one of its job pages, as an alternative to company. Links to a company's own website are not supported; pass company instead.
pageNoPage of results to return: 10 jobs per page on the free plan, 50 on paid plans.
remoteNotrue returns only jobs open to remote work; false only jobs that are not.
companyNoThe company's career board name, usually the company name in lowercase, for example airbnb, stripe or palantir. Required unless url is given.
keywordNoReturn only jobs whose title, department or team contains every word given, for example engineer or product designer.
locationNoReturn only jobs with a location containing this text, for example London, New York or Germany.
minSalaryNoReturn only jobs whose salary range reaches at least this amount, in the job's own currency and pay period: the top of the range is compared, or the bottom when no top is given. Jobs that publish no salary are left out when this is set.
departmentNoReturn only jobs whose department or team contains this text, for example Engineering or Sales.
postedSinceNoReturn only jobs first published at or after this date or date-time (ISO 8601, for example 2026-10-01), or within this age: a number followed by h, d or w, for example 12h, 7d or 2w. Jobs with no posting date are left out when this is set.
employmentTypeNoReturn only jobs of this employment type. Jobs whose board gives no employment type are kept, since many boards leave it blank; only jobs of another type are left out.

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNoError message, null on success
statusNo"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value is the pricing model: 10 credits per call and a plan split that gates full descriptions and salary ranges. That is genuinely useful behavioral context an agent cannot see in the annotations, though it says nothing about failure modes for unsupported boards.

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

Conciseness3/5

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

The content is largely earned, particularly the credit cost and result-shape summary, but the opening redundantly repeats the tool name and title ("Job Postings: Job Postings is a jobs API") and the field-shape sentence partially duplicates the output schema.

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 10-parameter, open-world read tool with an output schema and full schema coverage, the description covers what the tool returns, how it is filtered, plan limits and credit cost. The only real gap is that it never states the company-or-url requirement, leaving that to the schema.

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 parameter meaning is already fully documented. The description restates the filter list (keyword, location, department, employment type, posting date, remote) without adding syntax or semantics, and it omits minSalary as an explicit filter. Baseline 3 applies when the schema carries the detail.

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?

The description states a specific verb and resource: it returns open positions from a company's public career board and enumerates the fields each job carries. It does not name or contrast with the closest siblings (JobSearch, JobsReport), so an agent must infer which job-related tool to pick.

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 lists the available filters and discloses the 10-credit cost, which implies intended use, but never states when to choose this over JobSearch or JobsReport. The crucial rule about passing company vs. url appears only in the schema, not the description.

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.