Skip to main content
Glama
zvieli
by zvieli

notify_new_jobs

Scan aggregated job sources, filter unseen postings via JobTracker, and send alerts so you only get new matching jobs.

Instructions

Scan aggregated jobs, filter unseen postings via JobTracker, and dispatch alerts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional maximum number of unseen jobs to notify in one batch.
channelNoNotification channel (default: 'telegram').telegram
sourcesNoOptional list of source IDs to fetch from (e.g. ['linkedin', 'comeet', 'workday']).
keywordsNoAdditional keywords to require or match.
locationNoGeographic location filter.
min_scoreNoMinimum match score (0-100) threshold for alerting.
work_modeNoPreferred work mode: 'remote', 'hybrid', or 'onsite'.
tech_stackNoPreferred tech stack list for ranking/filtering.
force_refreshNoForce live fetch from sources bypassing cache.
auto_mark_seenNoAutomatically record notified jobs in tracker to avoid duplicate alerts.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/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. It usefully discloses the stateful dedup behavior (filter unseen via JobTracker, dispatch alerts), but for a tool with external side effects it omits that alerts are actually sent to a channel, that auto_mark_seen mutates tracker state by default, and any permission or rate-limit considerations.

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?

A single twelve-word sentence ordered along the execution pipeline (scan, filter, dispatch) with no filler. It is efficiently front-loaded, though its extreme brevity leaves substantive gaps for a ten-parameter, side-effecting tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, but with ten parameters, zero annotations, and real side effects (outbound alerts plus tracker mutation), a one-line description leaves the agent without guidance on invocation context or consequences. It should do more given the tool's complexity.

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 all ten parameters are already self-documenting, including defaults for channel, force_refresh, and auto_mark_seen. The description adds no syntax or semantics beyond what the schema provides, which is the baseline 3 case.

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 uses specific verbs and a clear three-step pipeline (scan aggregated jobs, filter unseen via JobTracker, dispatch alerts), so the agent knows this is the end-to-end notification flow rather than a search primitive. It does not, however, distinguish itself from closely related siblings like run_job_scout, test_notifier, or get_job_matches.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The presence of siblings such as test_notifier (clearly a dry-run variant) makes the missing distinction especially costly, since nothing tells the agent to prefer one over the other.

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