Skip to main content
Glama

import_job_alerts

Idempotent

Import job-alert emails from LinkedIn, Built In, and Indeed to track matching roles, filter out irrelevant jobs, and avoid duplicates in your jobwatch digest.

Instructions

Track the jobs in job-alert emails (LinkedIn, Built In, Indeed; other senders with a generic reader). Search the person's mail for them first, e.g. from:jobalerts-noreply@linkedin.com, from:builtin.com, from:jobalert.indeed.com, from:match.indeed.com (Indeed's job matches, as its app notifies them), and pass each message in; jobwatch never needs a mail password. Links lose their tracking parameters. Each job whose title, place and pay pass the watchlist's filters is looked for on the company's own board (a link to a supported board is read from there); job sites' pages are read only when their robots.txt allows (LinkedIn's and Indeed's don't, so the email's details are used). Jobs already tracked are left alone (known); new ones show up in get_digest, with via saying where they came from. Returns counts and each job: key, result (new, known, duplicate: twice in these emails), how (board, posting, page or email), filtered (why the filters leave it out of the digest, or null) and duplicate_of (the job applied to, queued or skipped that it's maybe the same opening as, as get_job gives it, or null). For emails about the person's applications (confirmations, rejections, interviews), use read_status_emails.

Input Schema

NameRequiredDescriptionDefault
emailsYesThe alert emails, one string each: the raw message (RFC822, as a mail connector's raw format gives it, base64url-encoded as from Gmail's API is fine too; best, since it names the sender) or just its HTML or plain-text body.
dry_runNoSay what would be tracked, and record nothing.
follow_linksNoLook for each job that passes the filters on the company's own board, and read links robots.txt allows. False tracks each job as the email has it, with no requests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as non-read-only, idempotent, open-world, and non-destructive, but the description adds substantial context: no mail password is needed, tracking parameters are stripped, jobs are filtered and looked up on company boards where robots.txt allows, and already-tracked jobs are left alone. These details are consistent with idempotentHint=true and destructiveHint=false.

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 first-step guidance are front-loaded, and most details are useful for a complex import operation. However, it is a dense single paragraph with long run-on clauses, so scanability could be improved with structure.

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?

Although there is no output schema, the description explains the return shape: counts plus per-job fields such as key, result, how, filtered, and duplicate_of. It also explains where new jobs appear via get_digest, which is enough context for an agent to invoke and interpret the tool correctly.

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 schema already documents emails, dry_run, and follow_links in detail. The description reinforces that each message should be passed in and hints at follow_links behavior, but it does not add meaningful semantics beyond the schema for dry_run or the exact link-following parameter behavior.

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?

Starts with a specific verb and resource: 'Track the jobs in job-alert emails,' and names the relevant sources. It also explicitly distinguishes this from read_status_emails, so an agent can tell which tool handles job alerts versus application-status emails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete first-step guidance: search the person's mail with sender-specific queries and pass each matching message in. It also clearly states when not to use this tool: for application confirmations, rejections, and interviews, use read_status_emails instead.

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