searchnapply

Create a job monitor

monitor_create

Idempotent

Purpose: Save a search as a monitor that keeps collecting matching job postings for the user; a title and one real location are required, it starts with the postings that already match, with datePosted narrowing that start to recent ones, and saving the same search twice is refused. When: Only when the user asks to be kept informed about a search. Cost: About 160 tokens for the saved monitor.

Input Schema

Name	Required	Description
`keywords`	No	Words that must appear in the posting's text.
`companies`	No	Company names; a posting from any of them is kept, and leaving them out watches the whole market.
`locations`	Yes	Real location names in plain words, each read as the closest known location, so check monitor.locations in the result for what it watches.
`salaryMax`	No	Highest yearly salary to keep, in US dollars after the same conversion.
`salaryMin`	No	Lowest yearly salary to keep, in US dollars after each posting's published salary is converted.
`titleText`	Yes	Words of the job title, matched to one of searchnapply's known roles when one fits (resolvedRole.display names it), which the monitor then watches, and otherwise matched against posting titles.
`datePosted`	No	How recently the posting was published; leave it out for any date.
`department`	No	One department slug, to narrow a title that spans departments; call job_postings_search_fields for what each one holds.
`experience`	No	Experience level to keep, given as exact, since a monitor keeps one level and no lowest level.
`includeFamily`	No	Also return postings from the resolved role's wider family; false, the default, keeps the exact role only.
`locationTypes`	No	Workplace types to keep.
`employmentType`	No	Employment type to keep.
`salaryCurrency`	No	A three-letter currency code that only labels the monitor.
`excludeKeywords`	No	Words that must not appear in the title or the text, 1 to 10 words.
`includeNoSalary`	No	Keep postings that publish no salary; true by default.

Output Schema

Name	Required	Description
`monitor`	Yes	The monitor as saved.
`titleNote`	No	Present when no role matched: the title words are matched against posting titles.
`resolvedRole`	No	The role the title words were read as; absent when no role matched.
`unrecognizedLocations`	No	The location names that matched no known location and were left out.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond annotations, the description discloses that title and a real location are required, that the monitor begins with already-matching postings, that datePosted narrows that initial set, that duplicate searches are refused, and the approximate token cost. These details materially help an agent understand the creation behavior and side effects.

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

Conciseness5/5

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

The description is structured into Purpose, When, and Cost, making it easy to scan and front-loaded with the most important information. Every line contributes useful information without repetition.

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 complex 15-parameter creation tool, the description covers purpose, usage condition, key creation behavior, duplicate handling, and cost, while the output schema and rich input schema cover returns and parameters. It is largely complete, though it could briefly mention update/list siblings for lifecycle context.

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 detailed parameter semantics are already handled by the input schema. The description adds modest extra meaning, especially that datePosted narrows the initial matching set, but it does not meaningfully explain most of the 15 parameters beyond what the schema already provides.

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 gives a specific verb and resource: saving a search as a monitor that keeps collecting matching job postings. It distinguishes this from a one-off search by explaining ongoing collection, though it does not explicitly contrast with creation/update siblings like monitor_update.

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?

The 'When' line clearly limits use to cases where the user asks to be kept informed about a search. It gives a strong usage condition but does not name alternatives such as monitor_update for existing monitors or monitor_list for inspection.

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

All searchnapply tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?