Skip to main content
Glama

Joeb

Get job details

get_jobs
Read-only

Show everything Joeb knows about up to 10 jobs, named by id or by posting link, one block per job.

Takes 1 to 10 entries. Name each job by its id as a row shows it (its first 12 characters), by any unique prefix of 8 or more characters, by its full id, or by its posting link (starting http:// or https://), such as one the user pastes. Joeb reads Greenhouse, Ashby and Lever posting pages; a company's own careers page can't be mapped to its posting.

Returns a block per job, in the order given, a blank line between:

[{id}] {title} — {company}

Place: {place} · {remote|on-site} Level: {seniority} · Salary: {salary} · Posted: {date} ({age}) · Source: {source} URL: {url} Your state: {liked|dismissed} · applied {date} · company blocked Removed from the employer's site on {date}; don't send the user to apply. Summary: {summary} Company: {about the company} Day to day:

  • {item} Requirements:

  • {item} Posting: {the raw posting text, only with include_posting=true} A fact or line the job lacks is left out, and dates are UTC. The bracketed id is the job's first 12 characters, which update_jobs, clear_jobs and block_companies take. "Your state" lists only what holds of the user's state on the job (liked or dismissed, applied, its company blocked), and the line is left out when nothing does. A removed posting is shown with the date it came down: mention the removal, and don't send the user to apply to it.

An entry that names no job doesn't fail the call: it gets a line in its place, "## '{entry}': " and why: not a job id or a posting link, no job with that id, an id matching several jobs (with a longer id to use for each), a link to a posting Joeb doesn't have yet, or a link Joeb can't read. A job named more than once, by any of its ids or links, is shown once, where it was first named.

include_posting=true adds each job's raw posting text, thousands of characters each, so ask for it only to confirm what the rest of the block doesn't say (visa sponsorship, office locations, tech stack), for the jobs that need it. A reply holds at most 40,000 characters: an entry that doesn't fit is left out whole, and the last line names each one left out, to ask for again. The one thing cut instead is the first job's posting text, which is cut to fit and ends with a note that the full posting is at its URL.

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": {
      "jobs": "<jobs>"
    },
    "name": "get_jobs"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobsYesThe jobs to show, 1 to 10, each named by its id (the 12 characters a row shows, any unique prefix of 8 or more, or the full id) or by its posting link, starting http:// or https://.
include_postingNoWhether to add each job's full posting text, as scraped from the employer's page. It runs to thousands of characters a job, so ask for it only when the rest of the block doesn't settle a question.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare a safe read; the description goes far beyond by disclosing the 40,000-character reply cap, that oversized entries are dropped whole and named at the end, that only the first job's posting text is truncated, that bad entries degrade to inline error lines rather than failing the call, and that duplicates are collapsed. That is exactly the operational context an agent needs before invoking.

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 block layout is front-loaded and the error semantics are well-sequenced, but the prose is long and repeats itself: the removed-posting instruction appears twice (once in the block legend, once after it) and include_posting guidance is restated in the closing paragraph.

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?

There is no output schema, and the description compensates by specifying the exact returned block format, which lines are omitted when absent, UTC dates, and the truncation footer. Nothing material about calling this tool is left undocumented.

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% and already states the id-prefix and link rules, so the schema does most of the work. The description still adds meaning the schema lacks: that duplicates named by any id or link are shown once at first mention, and that include_posting runs to thousands of characters and interacts with the reply cap.

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?

Opens with a specific verb and resource ("Show everything Joeb knows about up to 10 jobs") and constrains scope (count limit, naming by id or posting link), which separates it from search_jobs and list_saved_jobs without needing their schemas.

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?

Gives explicit conditional guidance for include_posting ("ask for it only to confirm what the rest of the block doesn't say (visa sponsorship, office locations, tech stack)") and for removed postings ("don't send the user to apply"). It stops short of naming search_jobs or list_saved_jobs as the alternative for discovery-style lookups.

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.

Resources