save_searchSave a search to your account (up to 50). Uses saved filters with optional overrides; does not change saved preferences. Email is initially off and can be enabled separately. Saving the same search again returns the existing one.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| filters | No |
Changes observed during successful MCP inspections.
Input schema / properties / filters / properties / origin / descriptionPrevious value: -"Driving start coordinates. Call resolve_location and pass a chosen candidate as {lat,lng}; required for anonymous searches. Null clears a saved origin."New value: +"Driving start coordinates. Coordinates as {lat,lng}; required for anonymous searches. Null clears a saved origin."Input schema / properties / filters / properties / function / descriptionPrevious value: -"Function code from get_filter_options; empty string clears."New value: +"Function code from get_filter_options, or several comma-separated to match any of them; empty string clears."Input schema / properties / filters / properties / function / maxLengthPrevious value: -40New value: +400Input schema / properties / filters / properties / industry / descriptionPrevious value: -"Industry code from get_filter_options; empty string clears."New value: +"Industry code from get_filter_options, or several comma-separated to match any of them; empty string clears."Input schema / properties / filters / properties / industry / maxLengthPrevious value: -40New value: +400Input schema / properties / filters / properties / level / descriptionPrevious value: -"Seniority inferred from title and experience; empty string clears."New value: +"Seniority inferred from title and experience: intern, entry, mid, senior, manager or director, or several comma-separated to match any of them; empty string clears."Input schema / properties / filters / properties / level / enumRemoved value: -[
- "",
- "intern",
- "entry",
- "mid",
- "senior",
- "manager",
- "director"
-]Input schema / properties / filters / properties / level / maxLengthAdded value: +100Input schema / properties / filters / properties / level / patternAdded value: +"^((intern|entry|mid|senior|manager|director)(,(intern|entry|mid|senior|manager|director))*)?$"Input schema / properties / filters / properties / sort / descriptionPrevious value: -"Shortest commute, newest first, or highest annualized pay first; default commute."New value: +"Closest (shortest commute), newest first, or highest annualized pay first; default commute."Input schema / properties / filters / properties / max_minutes / descriptionPrevious value: -"Maximum one-way driving minutes, excluding live traffic; default 20."New value: +"Maximum one-way driving minutes; default 20."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds genuinely useful behavior beyond annotations: a hard quota of 50, that saved preferences are left untouched, that email notifications default to off, and that re-saving returns the existing entry rather than creating a duplicate (reinforcing idempotentHint). It stops short of saying what happens when the 50 limit is reached or what errors/permissions apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with purpose and capped by dedupe semantics; no filler. The sentences are slightly telegraphic but every one carries a distinct fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a two-parameter tool with a richly annotated nested schema, but for a mutation that creates persistent account records it omits what the call returns (a saved-search id?), what occurs at the 50-search cap, and how it relates to update_search/delete_saved_search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% top-level schema description coverage, the description carries the burden and only partially does so: 'uses saved filters with optional overrides' clarifies that the filters object is a sparse override of existing saved filters, which is real added meaning. The 'name' parameter and the return value are never mentioned, leaving a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Save a search to your account') plus a concrete constraint (up to 50), which is more than a restatement of the title. It does not explicitly distinguish itself from update_search, set_filters, or set_search_email, so an agent must infer the boundary from wording alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied routing is present: 'does not change saved preferences' and 'Email is initially off and can be enabled separately' nudge the agent toward set_filters/set_search_email for those concerns. However, no sibling is named and there is no explicit 'use this when... instead of update_search' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.