Bob Ross
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOBROSS_API_TOKEN | No | REST bearer token (mode A) | |
| BOBROSS_READ_ONLY | No | Blocks all writes (default: true) | true |
| BOBROSS_ACCESS_KEY | No | Legacy HMAC access key (mode B) | |
| BOBROSS_SECRET_KEY | No | Legacy HMAC secret key (mode B) | |
| BOBROSS_TLS_VERIFY | No | Verify TLS certs (default: true) | true |
| BOBROSS_ALLOW_WRITES | No | Second switch required for writes (default: false) | false |
| BOBROSS_LANDSCAPE_URL | Yes | Landscape base URL |
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
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Check connectivity and that credentials work against Landscape. |
| list_computersA | List computers in the estate. |
| get_computerB | Full detail for a single computer by id. |
| resolve_queryA | Preview the BLAST RADIUS of a query: how many machines it matches and a sample of them. Always run this before a destructive action. |
| list_alertsA | Active alerts across the estate (pending security upgrades, offline, etc.). |
| list_activitiesC | Recent activities (async jobs) and their status. Use to track prior actions. |
| get_activityA | Status/detail of one activity by id (e.g. to see if a reboot finished). |
| estate_healthA | One-shot situational awareness across the whole estate: totals, machines
needing reboots, stale/offline machines, distribution breakdown, alert counts,
recent failed activities, and a ranked |
| pending_updatesA | List packages with pending upgrades on matched machines — what would actually change if you patched. Returns totals, a per-machine upgrade count, and a sample of packages. Preview this before apply_security_upgrades / upgrade_packages. |
| wait_for_activityA | Poll an activity (e.g. a reboot or patch job) until it finishes or times out, then report its final status. Use after a write action to confirm success. |
| list_scriptsA | Stored scripts available to run via execute_script. |
| execute_scriptA | Run a stored script on matched machines. Dry run first (omit confirm_token). Set wait=true to poll the resulting activity to completion and report pass/fail. |
| reboot_computersA | Reboot matched machines. Dry run first (omit confirm_token). Set wait=true to poll until the reboot activity finishes. |
| apply_security_upgradesB | Apply pending security (USN) upgrades to matched machines. Dry run first. Set wait=true to poll the upgrade activity to completion. |
| upgrade_packagesA | Upgrade packages on matched machines (omit |
| install_packagesA | Install packages on matched machines. Dry run first (omit confirm_token). Set wait=true to poll to completion. |
| remove_packagesA | Remove packages from matched machines. Dry run first (omit confirm_token). Set wait=true to poll to completion. |
| add_tagsB | Add tags to matched machines (non-destructive, but still write-gated). |
| remove_tagsC | Remove tags from matched machines (write-gated). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| patch_security_updates | Guided workflow to safely apply pending security updates to a tag. |
| triage_estate | Walk the whole estate and propose a prioritized action plan. |
| reboot_reboot_required | Safely reboot every machine flagged reboot-required. |
| patch_machine | Safely patch one machine end-to-end. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| computers_resource | Cheap read-only snapshot of the estate for grounding context. |
| alerts_resource | Cheap read-only snapshot of active alerts. |
| health_resource | Estate-health snapshot (same shape as the estate_health tool). |
TDQS
Scored across 19 tools
Each tool has a clearly distinct purpose, from package management to query resolution and system health. Even similar operations like apply_security_upgrades and upgrade_packages are differentiated by description and scope, leaving no ambiguity for an agent.
Most tool names follow a verb_noun pattern (e.g., install_packages, list_computers), with a few exceptions like pending_updates (adjective_noun) and estate_health (noun_noun). The pattern is largely consistent, aiding predictability.
With 19 tools covering a broad IT estate management domain, the count is slightly above the ideal range but justified by the need for granular operations (e.g., separate security upgrades, pending updates, scripts). No tool feels superfluous.
The tool surface covers core CRUD and lifecycle operations for computers, packages, tags, scripts, and activities. Minor gaps exist, such as lack of computer creation/deletion or patch scheduling, but the set is sufficient for common management tasks.