searchnapply

Create a job monitor

monitor_create

Idempotent

Purpose: Save a search as a monitor that keeps collecting matching job postings for the user; only a title and one real location are required, and the rest narrow it further without being 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.2/5.0

Behavior4/5

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

The annotations already declare that this is a non-read-only, non-destructive, idempotent, closed-world operation. The description adds useful behavioral context: it starts with already-matching postings, datePosted narrows that initial set, duplicate saves are refused, and the cost is about 160 tokens.

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 short, front-loaded with purpose, and organized into Purpose, When, and Cost. Every sentence adds 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?

Given the 15 parameters, nested experience object, full schema descriptions, annotations, and an output schema, the description covers the essential creation behavior, required inputs, duplicate refusal, and cost. Minor gaps like permission requirements are not material for this closed-world tool.

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 all parameters in detail. The description only restates that title and one location are required and that other fields narrow the search, so it does not significantly add meaning beyond the schema.

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?

The description states a specific verb and resource: saving a search as a monitor that keeps collecting matching job postings. It clearly differentiates creation from monitor listing, retrieval, update, and deletion by focusing on persistence and collection.

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 explicitly restricts use to cases where the user asks to be kept informed about a search, which is a strong usage condition. However, it does not name alternative sibling tools such as job_postings_search for one-off searches or monitor_update for later changes.

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?