Skip to main content
Glama

Search job boards now

start_radar_scan
Idempotent

Start a job radar scan: search job boards for vacancies matching the user's active resume. Runs asynchronously — returns a task_id immediately; the scan takes up to a minute, then get_radar_matches shows the results and get_radar_status.last_scan_at says whether it brought anything in (a scan that found nothing new leaves it as it was); get_task_status(task_id) reports progress and the outcome. Calling it while a scan is already running returns the same task_id (no double scan). Consumes one radar scan from the user's plan quota — several a day on a paid plan, one a week on the free plan, where the morning's automatic scan counts too; the account's first scan ever is not counted, and neither is a scan with changed filters after one that found nothing, while the account has never had a match. Returns 'not_found' if the user has no resume yet, 'role_unknown' when nothing names the role to search for (no role in the radar filters or career memory, no title, position or skills on the resume; set_radar_filters stores a role), and 'limit_exceeded' when the quota is spent; get_radar_status.next_scan_at then says when a free user's weekly scan comes back. The same search as the last scan (same role, place and filters on the same resume) within an hour of it starts nothing and spends nothing: it returns 'recent_scan' with the minutes since that scan and when the same search can run again; a search with other filters (set_radar_filters) starts at once.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
statusNoprocessing
task_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare mutation/idempotency/open-world traits; the description adds the substantive behavior: asynchronous task_id return, up-to-a-minute duration, quota consumption rules per plan, the free-scan exceptions, and the 'not_found' / 'role_unknown' / 'limit_exceeded' outcomes with their remediation paths.

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?

Purpose and async behavior are front-loaded and nothing is redundant, but the rest is compressed into one dense semicolon-chained paragraph covering quota, errors, and cooldown. It would scan better split into short labeled clauses, though no sentence is filler.

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?

For a zero-parameter mutation with an output schema, the description covers the async lifecycle, every error code with its cause and fix, quota accounting, and dedup semantics. An agent has everything needed to invoke it and interpret the outcome.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. It does correctly imply that the roles, location and filters come from previously stored state (radar filters, career memory, resume), which helps an agent understand where the search inputs come from.

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 first clause gives a specific verb and resource ('Start a job radar scan: search job boards for vacancies matching the user's active resume'), and it explicitly distinguishes itself from get_radar_matches, get_radar_status, get_task_status and set_radar_filters by naming each.

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

Usage Guidelines5/5

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

It states when to call, what happens if a scan is already running, when a repeat search is suppressed ('recent_scan' with cooldown minutes), and how a changed-filter search bypasses that. Alternatives for retrieving results are named explicitly.

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.