Skip to main content
Glama

Read job search status

get_radar_status
Read-only

State of the user's job radar: how many matches are in the working list, still waiting in the pool, saved, deferred or in the Skipped pile ('archived' counts what was skipped and what was put away); when a scan last brought something in; whether the daily automatic search is switched on; and the explicit search filters, if the user set any — the progress picture without paging through every match. last_scan_at moves when new vacancies arrive, so a scan that found nothing new leaves it unchanged. search_query is what the last scan actually searched for (role, place, country) — the role there came from the filters, career memory or the resume, so an empty filters.role does not mean the radar searched for no role; search_query.role is the title the boards were searched with and search_query.role_display the same role in the user's own words, as typed in the filters; search_role is what the next scan searches for (null: nothing names a role yet). next_scan_at is set only on the free plan while its one scan a week is spent. All zeros with auto_search_enabled=false is the normal answer for someone who has never used the radar.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
savedNo
activeYesMatches in the working list right now (new plus saved).
filtersNoExplicit search filters, when the user set any. They outrank the resume.
archivedNo
deferredNo
search_roleNoThe title the next scan searches for: the role from the filters, career memory or the resume, spelled the way job boards spell it once a scan has derived the search profile for this resume and role; before that, the role as set. Null means nothing names a role — a scan would fail with role_unknown until the user gives one.
last_scan_atNoISO timestamp of the most recent match found by a scan; null if the radar never ran.
next_scan_atNoFree plan only, while its one scan a week is spent: ISO timestamp of when the next scan becomes available. Null when a scan is available now or the plan is paid (a paid plan's scans come back the next day).
search_queryNoWhat the last scan actually searched for — the role, place and country the radar settled on from filters, career memory, the resume and, when nothing else named one, the country the user signed up from. Null before the first scan. It stays after the filters or the resume change until the next scan, so it can differ from filters and search_role, which is what the next scan will run. The role here is what the scan searched for even when filters.role is empty.
pool_remainingYesFound but not yet shown to the user — what a fresh look would reveal.
auto_search_enabledYesWhether the daily automatic scan and its digest are on for this user.
search_paused_untilNoISO timestamp the user's search pause ends, null when there is none. While paused, nothing the product starts on its own reaches them and the daily scan does not run. set_search_pause with months=null lifts it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / $defs / RadarSearchQueryItem / properties / role / description
      Added value: +"The title the boards were searched with. Once a scan has derived the search profile it is the English spelling job boards use, so it can differ from the words the user typed."
    • addedOutput schema / $defs / RadarSearchQueryItem / properties / role_display
      Added value: +{
      +  "description": "The same role in the user's own words: filters.role as typed when the last scan ran those filters, otherwise the searched title. This is the name the user knows the role by.",
      +  "title": "Role Display",
      +  "type": "string"
      +}
    • changedOutput schema / $defs / RadarSearchQueryItem / required
      Previous value: -[
      -  "role"
      -]New value: +[
      +  "role",
      +  "role_display"
      +]
  2. Changed3 schema fields changed
    • addedOutput schema / $defs / RadarLocalBoardItem
      Added value: +{
      +  "properties": {
      +    "name": {
      +      "title": "Name",
      +      "type": "string"
      +    },
      +    "url": {
      +      "title": "Url",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "name",
      +    "url"
      +  ],
      +  "title": "RadarLocalBoardItem",
      +  "type": "object"
      +}
    • addedOutput schema / $defs / RadarSearchQueryItem / properties / found
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Matches the last scan kept under the filters; null while it runs and on scans before 2026-09-27.",
      +  "title": "Found"
      +}
    • addedOutput schema / $defs / RadarSearchQueryItem / properties / local_board
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/RadarLocalBoardItem"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "In countries whose postings live mostly on a local job site the radar does not search (Kazakhstan, Ukraine, Turkey, Korea, Georgia, the Gulf and others): that site's name and its search for the role. The radar never reads it; null for every other country."
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish that this is a safe read-only operation, and the description adds substantial behavioral context beyond them: last_scan_at only moves when new vacancies arrive, next_scan_at is set only on the free plan when the weekly scan is spent, and all zeros with auto_search_enabled=false is normal for a never-used radar. These are important interpretive traits that an agent would not get from the annotations alone.

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?

The description is front-loaded with the core status categories and then adds only field-specific interpretation. It is dense and longer than many definitions, but nearly every sentence clarifies a real ambiguity such as search_query versus search_role or why filters.role may be empty.

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

Completeness5/5

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

Given the output schema and read-only annotations, the description is complete enough for correct invocation and interpretation. It covers the status categories, edge cases, plan-specific behavior, and the distinction between filters, last scan query, and next scan role.

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?

The tool has zero parameters, so the schema cannot provide parameter-level semantics and the description does not need to compensate. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on returned state rather than inventing parameter guidance.

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 read operation and enumerates exactly what the status contains: working-list matches, pool, saved, deferred, skipped, last scan, auto-search, filters. It clearly distinguishes this summary view from paging through individual matches, making it easy to separate from siblings like get_radar_matches.

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?

It provides clear context for when to use this tool by framing it as 'the progress picture without paging through every match,' which implicitly points to get_radar_matches as the detailed alternative. However, it does not explicitly name that sibling or state any when-not conditions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.