bigfix-root-mcp

Overview Schema Source Related Servers Discussions Admin

Session Relevance Query

session_relevance_query

Evaluate BigFix session relevance queries on the root server to inspect computers, fixlets, actions, and sites without client round-trips, with limit/offset paging.

Instructions

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.

Input Schema

Name	Required	Description
`limit`	No	Max rows to return (default 500). The response reports total_available and truncated.
`offset`	No	Row offset, for paging through results.
`relevance`	Yes	A BigFix session relevance expression to evaluate.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.2.0Oct 20, 2026

addedInput schema / properties / limit

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Max rows to return (default 500). The response reports total_available and truncated."
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Row offset, for paging through results.",
+  "type": "integer"
+}

First observedv0.1.0Aug 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and discharges it well: it discloses the absence of row-limiting relevance operators, that limit bounds the response not the work, and that results are scoped to the configured operator so counts are a lower bound unless is_main_operator. This is exactly the behavioral context an agent needs before trusting the output.

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?

Front-loads the purpose and example, then sequences the paging caveat and result-scope warning. It is somewhat long with four paragraphs, but each carries distinct operational information; only minor tightening is possible.

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 no-annotation, 3-param query tool, the description covers the query domain, paging semantics, response envelope, and the critical operator-scope caveat. Even though an output schema exists, the surrounding caveats make the definition complete for correct invocation and interpretation.

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 coverage is 100%, so the schema already documents limit/offset/relevance, putting the baseline at 3. The description adds genuine meaning beyond the schema by explaining why limit/offset are necessary (the relevance operators are undefined) and clarifying that limit constrains the response rather than the evaluation work.

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?

States a specific verb+resource ('Evaluate a BigFix session relevance query on the root server') and immediately distinguishes it from client-side siblings by noting 'no client round-trip'. An agent can separate this from client_query/client_query_submit without opening either schema.

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?

Explains the context in which this applies (server-side data: computers, fixlets, actions, sites) and gives concrete usage guidance for paging (use limit/offset). It doesn't explicitly name the sibling to use for client-side evaluation, relying on the 'no client round-trip' phrase to imply the contrast.

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