Evaluate a BigFix session relevance query on the root server.

Session relevance queries data the server already has (computers, fixlets, actions, sites, operators...) with no client round-trip. Examples: 'number of bes computers', '(name of it, id of it) of bes computers whose (now - last report time of it < 1 * day)'.

There is no way to limit rows in the relevance itself - 'first', 'firsts', 'items' and 'elements' are all undefined operators on a BigFix root server. Use the limit/offset parameters instead; the response reports total_available and truncated. Note the server still evaluates the whole query, so limit bounds the response, not the work.

Returns the server's JSON envelope: {"result": [...], "plural": ..., "type": ..., "evaltime_ms": ...} (plus "count" when the server sends it) and bounding metadata.

Results are evaluated within the configured operator's scope. Unless whoami reports is_main_operator, counts and lists are a lower bound on what exists - report them as visible to this operator, not as the complete state of BigFix.

Statically analyze a relevance expression WITHOUT evaluating it anywhere.

Offline and instant: checks that the expression parses (with a positioned error when it does not), infers types, classifies the dialect (session vs client), flags inspectors no reference dump defines, finds unbound 'it', and scores complexity/evaluation cost. Use it to validate a query before session_relevance_query or client_query, or to understand a relevance error after one.

Advisory: the inspector table is a snapshot, so an unknown inspector is a warning (the live server may still know it), and a clean report does not guarantee the server will accept the query.

Search the BigFix inspector reference (offline snapshot; no server call).

Fuzzy: returns exact, prefix and near-miss matches with signatures, result types and the dialect each inspector exists in. Use it before writing a query, or after an 'is not defined' error to find the right name. Snapshot caveat: absence here does not prove absence on the live server.

Submit a BigFix client (fast) query. Targeting: set exactly one of target_all, target_computer_ids, target_computer_names, or target_relevance (client relevance evaluated on each agent to decide applicability). Targeting is limited to the configured operator's scope, so target_all means all computers this operator can see, not necessarily all computers in BigFix.

Fetch current results for a previously submitted client fast query.

Results are cumulative and there is no completion flag: safe and cheap to call repeatedly until reported_count stops growing or the expected number of computers have reported.

reported_count and result_row_count always describe the full result set; the returned rows are windowed by limit/offset.

Submit a BigFix client (fast) query and wait for results, polling until done or timeout. Targeting: set exactly one of target_all, target_computer_ids, target_computer_names, or target_relevance (client relevance evaluated on each agent to decide applicability). Targeting is limited to the configured operator's scope, so target_all means all computers this operator can see, not necessarily all computers in BigFix.

Get BigFix root server info (version, etc) from /api/serverinfo.

List all sites visible to the configured operator.

Returns {"data": , "truncated": ..., "total_chars": ...}. A deployment subscribed to many external content sites can produce a large listing; when it exceeds the size cap, data is null and note says so rather than handing back a half-cut structure that looks complete.

Look up a computer group by name within an explicit site path.

Implemented against /api/computergroups/{site_path} directly rather than besapi's get_computergroup, which routes through the mutable "current site path" connection state this server avoids.

Get one computer's full record from /api/computer/{id}.

Includes the reported properties BigFix holds for that computer. Use find_computers first if you only know part of the name.

Find computers whose name contains a substring.

Returns (name, id, last report time) rows. The search term cannot contain a double quote - BigFix relevance string literals have no escape for one.

Content currently relevant to one computer (/api/computer/{id}/fixlets).

This is the patch/compliance question: what BigFix currently considers applicable to that machine.

Get an action's definition from /api/action/{id}.

Get an action's per-computer execution state (/api/action/{id}/status).

The "did my change actually work" tool. Status is scoped to the computers the configured operator can see.

List actions visible to the configured operator (/api/actions).

Search content by name across every site the operator can see.

Returns rows of {name, id, site_name, site_path} - site_path is what get_content needs. It is null when the site name is ambiguous (two sites of different types sharing a display name), with the options listed under site_path_candidates rather than guessed at.

The search term cannot contain a double quote.

Get one fixlet, task, analysis or baseline by site path and ID.

List console operators visible to the configured operator.

List BigFix roles visible to the configured operator.

Validate BES XML against the BigFix schemas.

Makes no server call.

Use before asking anyone to import content: it catches malformed or non-conforming XML locally instead of as a REST error.

Look up a BigFix operator (console user) by name.

Read a BigFix dashboard datastore variable value (read-only).

Show the configured connection: user, root server, main operator status.

writes_enabled says whether the gated write tools are registered in this process; when false they are absent from the tool list entirely.

Cheap connectivity and permission smoke test. is_main_operator tells you whether results from the other tools can be treated as the full state of BigFix (master operator) or only as this operator's scoped view, which may be incomplete in ways this operator cannot detect.

Read-only escape hatch: GET any BigFix REST API path under /api/.

GET is non-mutating across the BigFix REST API. Use path 'help' to discover available endpoints. Response text is capped at max_chars; total_chars reports the full length.

List targets available to qna_eval_client_relevance.

inventory_path is the inventory file in use: BIGFIX_QNA_INVENTORY when the server sets it, else the default search (~/.bigfix/remote_clients.toml, then the all-users config directory); null when none was found. A run that names no targets uses every inventory host. auto_discovery says whether qna_discover_targets is available (it probes local qna, container images and developer.bigfix.com, and adds what works to ~/.bigfix/remote_clients.toml); auto_discovery_pending says no inventory file exists yet, so the next run naming no targets discovers first without being asked. containers_allowed says whether arbitrary container image names may be passed as targets. Listing never probes or writes anything.

Evaluate CLIENT relevance with the BigFix qna tool - a fast feedback loop that never touches the BigFix deployment.

qna runs on lab targets (containers or admin-inventoried hosts), NOT on managed BigFix endpoints: results reflect each target machine only. There is no operator scope, no site subscriptions and no client settings, so inspectors that depend on deployment state will differ from what client_query returns. Iterate on relevance syntax and inspector behavior here, then confirm on real agents with client_query.

With no inventory_targets or container_images, it runs on every inventory host (qna only reads). An online_evaluator inventory host sends the client relevance to developer.bigfix.com; name targets to keep a query off it. When no inventory file exists yet (qna_list_targets: auto_discovery_pending), such a run first discovers what works on the server's host and records it in ~/.bigfix/remote_clients.toml; once the file exists, discovery runs only through qna_discover_targets. The payload's auto_discovery says what was added. A discovering run can take minutes.

Per-target failures come back as result rows with error_kind ('relevance', 'qna', 'bootstrap', 'transport', 'resolve'), never as a tool error. ok_count and target_count describe the whole run; the rows are windowed by limit/offset.

Find qna targets that work on the server's host and add them to the inventory, like the bigfix-remote-client-relevance CLI's --auto-discovery. Evaluates nothing.

Probes this host's qna, a downloaded qna, the container engine's images and developer.bigfix.com, then adds what works and is not already listed to ~/.bigfix/remote_clients.toml. Never uses SSH discovery and never prompts. Slow: it can take minutes. Use it when qna_list_targets shows no (or too few) inventory hosts; a run of qna_eval_client_relevance naming no targets only discovers by itself when no inventory file exists yet.

Returns path (the inventory written), added (new host names) and inventory (every target now listed).