searchnapply

Update a job monitor

monitor_update

DestructiveIdempotent

Purpose: Change a saved monitor without losing what it collected or what the user decided; send only what changes, since everything else stays as saved. It returns the monitor as saved; a change that makes it match another saved monitor is refused instead and answered with a plain sentence rather than the monitor. When: The user wants a different title, location, company, keyword or field on a saved monitor. 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`	No	Real location names in plain words, each read as the closest known location, so check monitor.locations in the result for what it watches.
`monitorId`	Yes	The monitor id from monitor_list.
`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`	No	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; leave it out to keep the monitor's current setting.
`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?

Goes well past the annotations: discloses partial-update semantics (only sent fields change), the failure mode for a result that would duplicate another saved monitor (a plain sentence instead of the monitor), the success return shape, and a token cost estimate. Annotations already cover safety/idempotency flags, and the description adds the missing behavioral context about what is preserved versus overwritten.

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?

Three labeled sentences (Purpose/When/Cost), front-loaded with the operation's contract and free of repetition. Every sentence carries distinct information an agent needs before calling.

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 16 parameters, an output schema, and full annotation coverage, the description covers the essentials: partial update, refusal case, return value, and cost. It is slightly thin on failure modes like an unknown monitorId and does not address the destructiveHint=true flag explicitly, but the output schema and annotations offset most of that.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning for a 16-parameter tool by framing all non-required fields as optional patches that leave current values untouched. It does not detail defaults or enum semantics beyond what the schema already states.

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?

States a specific verb+resource (change a saved monitor) and immediately pins down patch semantics: 'send only what changes, since everything else stays as saved.' That distinguishes it from monitor_create or a full replace, though it never names a sibling tool the way an ideal definition would.

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

Usage Guidelines3/5

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

The 'When:' clause gives a concrete trigger (user wants a different title, location, company, keyword or field on a saved monitor), which is better than implied usage. But there is no when-not guidance, no prerequisites, and no routing to siblings such as monitor_create, monitor_get, or monitor_delete for adjacent intents.

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?