Skip to main content
Glama

Bob Ross ๐ŸŽจ

PyPI CI License: MIT

"We don't make mistakes, just happy little servers."

An MCP server for managing a Canonical Landscape estate from an AI agent (Claude Code / Desktop). Bob Ross wraps the Landscape API as calm, friendly MCP tools โ€” inventory, alerts, activities, patching, script execution, reboots โ€” with a safety layer built right in, so your agent can tend a whole fleet of happy little servers without ever beating the devil out of the wrong one.

Everybody needs a friend. Even your Ubuntu estate.


๐Ÿ–Œ๏ธ Why it's not just a dumb API wrapper

A blank canvas is a beautiful thing โ€” and so is a fleet that's still standing. Bob Ross paints carefully:

  • Blast-radius preview โ€” before you touch anything, resolve_query steps back from the easel and shows you how many machines a query matches (and a sample). Always know how big the canvas is.

  • Dry-run โ†’ confirm handshake โ€” every destructive tool returns a short-lived confirm_token on the first call. You have to call again with the token to actually do it. If the set of matched machines drifts in between, the token is refused. No happy little accident reboots 500 boxes.

  • Secure by default โ€” read-only mode is on out of the box (we all start with a clean canvas). Writes need two switches flipped on purpose. TLS is verified. Secrets never touch the logs.

  • Full audit log โ€” every stroke (dry runs, executes, denials) is appended to a redacted JSONL trail. You can always see what the brush did.

  • Activity-aware โ€” write actions in Landscape run later, asynchronously. Pass wait=true and Bob Ross watches the paint dry, then tells you succeeded / failed / still-going per machine โ€” not just "queued."

  • Dual auth โ€” legacy HMAC query API or REST bearer token, auto-detected.


Related MCP server: Enterprise DevOps MCP Server

๐ŸŽจ Get the paints out (install)

From PyPI โ€” the whole studio in one command:

pip install bob-ross-landscape

That gives you the bob-ross command (the import package is bob_ross).

git clone https://github.com/just-an-oldsalt/bob-ross
cd bob-ross
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
pytest                    # unit tests (safety / signing / config / health / ...)
python scripts/smoke.py   # safe live smoke test vs your instance (read-only, no writes)

๐Ÿ–ผ๏ธ Set up your palette (configuration)

Everything is BOBROSS_* env vars (or a .env file โ€” see .env.example):

Var

Default

Meaning

BOBROSS_LANDSCAPE_URL

โ€”

Landscape base URL (no trailing /api/)

BOBROSS_ACCESS_KEY / BOBROSS_SECRET_KEY

โ€”

Legacy HMAC keys (mode A)

BOBROSS_API_TOKEN

โ€”

REST bearer token (mode B)

BOBROSS_READ_ONLY

true

Blocks all writes โ€” the safe blank canvas

BOBROSS_ALLOW_WRITES

false

The second switch needed to enable writes

BOBROSS_TLS_VERIFY

true

Verify TLS certs (set false only for dev self-signed)

To let Bob Ross pick up a brush, flip both BOBROSS_READ_ONLY=false and BOBROSS_ALLOW_WRITES=true. Even then, every destructive action still needs the dry-run โ†’ confirm handshake. Belt and suspenders. Happy and safe.


๐Ÿช„ Add it to Claude Code

pip install bob-ross-landscape

claude mcp add bob-ross --scope user \
  --env BOBROSS_LANDSCAPE_URL=https://landscape.example.com \
  --env BOBROSS_ACCESS_KEY=YOUR_KEY \
  --env BOBROSS_SECRET_KEY=YOUR_SECRET \
  -- bob-ross

Prefer to keep secrets out of Claude's config? Put them in a .env file and run from that directory instead:

claude mcp add bob-ross --scope user -- \
  bash -lc 'cd /path/to/your/bobross-env && exec bob-ross'

Claude Desktop (stdio)

{
  "mcpServers": {
    "bob-ross": {
      "command": "bob-ross",
      "env": {
        "BOBROSS_LANDSCAPE_URL": "https://landscape.example.com",
        "BOBROSS_ACCESS_KEY": "YOUR_KEY",
        "BOBROSS_SECRET_KEY": "YOUR_SECRET"
      }
    }
  }
}

Bob Ross always wakes up in read-only mode. Start there. Get comfortable. Then, when you're ready, let's get a little crazy.


๐ŸŒฒ The brushes (tools)

Read (always safe โ€” look all you like): ping ยท estate_health ยท list_computers ยท get_computer ยท resolve_query ยท pending_updates ยท list_alerts ยท list_activities ยท get_activity ยท wait_for_activity ยท list_scripts

Write (gated โ€” dry-run โ†’ confirm every time): execute_script ยท reboot_computers ยท apply_security_upgrades ยท upgrade_packages ยท install_packages ยท remove_packages ยท add_tags ยท remove_tags

Activity-creating write tools take wait=true to poll the resulting Landscape activity to a terminal status and hand back a completion summary (succeeded / failed / still-incomplete) โ€” so your agent knows the real outcome, not just "queued."

Resources: landscape://computers ยท landscape://alerts ยท landscape://health ยท landscape://computer/{computer_id} (template)

Prompts: patch_security_updates ยท triage_estate ยท reboot_reboot_required ยท patch_machine


๐Ÿ”๏ธ A happy little workflow

You have unlimited power here. Move mountains โ€” one confirmed step at a time:

you:  "what needs my attention across the fleet?"
       โ†’ estate_health  โ†’  "kaylee-mc: 138 pending upgrades, 3 boxes need reboots"

you:  "what would patching kaylee-mc actually change?"
       โ†’ pending_updates title:kaylee-mc  โ†’  the list, per package

you:  "apply the security upgrades there"
       โ†’ apply_security_upgrades  โ†’  dry-run shows blast radius + a confirm_token
       โ†’ (you approve)            โ†’  re-run with the token + wait=true
       โ†’ completion: succeeded โœ…  no failed patches, just happy little servers


"Talent is a pursued interest. Anything you're willing to practice, you can do."

Now go tend some happy little servers. ๐ŸŽจ

Available Tools

19 tools
add_tagsB

Add tags to matched machines (non-destructive, but still write-gated).

Inputs: tags (required), query (required), confirm_token. Returns: object

apply_security_upgradesB
Destructive

Apply pending security (USN) upgrades to matched machines. Dry run first. Set wait=true to poll the upgrade activity to completion.

Inputs: query (required), wait, wait_timeout, confirm_token. Returns: object

estate_healthA
Read-only

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 attention list of what to act on.

Inputs: stale_after_hours. Returns: object

execute_scriptA
Destructive

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.

Inputs: query (required), script_id (required), wait, username, +2 more. Returns: object

get_activityA
Read-only

Status/detail of one activity by id (e.g. to see if a reboot finished).

Inputs: activity_id (required). Returns: object

get_computerB
Read-only

Full detail for a single computer by id.

Inputs: computer_id (required). Returns: object

install_packagesA
Destructive

Install packages on matched machines. Dry run first (omit confirm_token). Set wait=true to poll to completion.

Inputs: query (required), packages (required), wait, wait_timeout, +1 more. Returns: object

list_activitiesC
Read-only

Recent activities (async jobs) and their status. Use to track prior actions.

Inputs: limit, query. Returns: object

list_alertsA
Read-only

Active alerts across the estate (pending security upgrades, offline, etc.).

Inputs: no named parameters. Returns: object

list_computersA
Read-only

List computers in the estate. query uses Landscape's query language (e.g. 'tag:web', 'os:noble', 'alert:security-upgrades').

Inputs: limit, query, offset. Returns: object

list_scriptsA
Read-only

Stored scripts available to run via execute_script.

Inputs: no named parameters. Returns: object

pending_updatesA
Read-only

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.

Inputs: query (required), sample. Returns: object

pingA
Read-only

Check connectivity and that credentials work against Landscape.

Inputs: no named parameters. Returns: object

reboot_computersA
Destructive

Reboot matched machines. Dry run first (omit confirm_token). Set wait=true to poll until the reboot activity finishes.

Inputs: query (required), wait, wait_timeout, confirm_token. Returns: object

remove_packagesA
Destructive

Remove packages from matched machines. Dry run first (omit confirm_token). Set wait=true to poll to completion.

Inputs: query (required), packages (required), wait, wait_timeout, +1 more. Returns: object

remove_tagsC

Remove tags from matched machines (write-gated).

Inputs: tags (required), query (required), confirm_token. Returns: object

resolve_queryA
Read-only

Preview the BLAST RADIUS of a query: how many machines it matches and a sample of them. Always run this before a destructive action.

Inputs: query (required). Returns: object

upgrade_packagesA
Destructive

Upgrade packages on matched machines (omit packages to upgrade all). Dry run first. Set wait=true to poll to completion.

Inputs: query (required), wait, packages, wait_timeout, +1 more. Returns: object

wait_for_activityA
Read-only

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.

Inputs: activity_id (required), timeout_seconds. Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelogโ€ฆ

    TDQS

    A3.7/5.0

    Scored across 19 tools

    Disambiguation5/5

    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.

    Naming Consistency4/5

    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.

    Tool Count4/5

    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.

    Completeness4/5

    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.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers