bigfix-root-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BES_PASSWORD | No | Password for the REST operator | |
| BES_USER_NAME | Yes | REST operator username | |
| BES_SSL_VERIFY | No | TLS verification setting: 'false', 'true', or a CA bundle path | false |
| BES_ROOT_SERVER | Yes | Root server URL (e.g. https://bes.example.com:52311) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| session_relevance_queryA | 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 server-side result limit, so bound large result sets in the relevance itself (e.g. 'firsts 100 of bes computers'). Returns the raw JSON envelope: {"result": [...], "evaltime_ms": ...}. 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. |
| client_query_submitA | 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. |
| client_query_resultsA | 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. |
| client_queryA | 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_server_infoA | Get BigFix root server info (version, etc) from /api/serverinfo. |
| list_sitesA | List all sites visible to the configured operator. |
| get_computer_groupA | 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_operatorA | Look up a BigFix operator (console user) by name. |
| get_dashboard_variableA | Read a BigFix dashboard datastore variable value (read-only). |
| whoamiA | Show the configured connection: user, root server, main operator status. 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. |
| api_getA | 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 truncated to 50KB. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Each tool targets a distinct resource or operation: server info, session relevance, client query lifecycle (submit/results/combined), sites, computer groups, operators, dashboard variables, and a generic API GET. The three client query tools are clearly separated by their role in the workflow, and session_relevance_query vs client_query is explicitly server-side vs client-side.
Naming is inconsistent: most tools use verb_noun (get_server_info, list_sites, get_operator), but there are noun phrases (session_relevance_query, client_query, client_query_results), an object-verb (client_query_submit, api_get), and a standalone verb (whoami). This mixing of verb-first and noun-first patterns makes the set harder to predict.
11 tools is well within the ideal range for a domain-specific server. Each tool serves a distinct need, from connectivity checks to relevance queries, client data collection, and resource lookups. No tool feels superfluous, and the count is appropriate for a read-only BigFix root server interface.
The tool surface comprehensively covers the read-only querying and inspection domain: server info, session relevance, client relevance, sites, computer groups, operators, dashboard variables, and a generic API escape hatch. The powerful session_relevance_query and api_get cover any gaps for listing or deep inspection, and the absence of mutating tools is consistent with the stated read-only nature.