MCP-6 #4970 "Automation tools: playbooks, runs, schedules, alert actions". Viewer: list_playbooks, get_playbook (secret defaults masked), list_inventory (variable names only), list_ansible_runs, get_ansible_run (log tail + grep), list_schedules, wait_for_run (polls, 120s cap). Operator: run_playbook (check mode unless check=false; a steward:confirm playbook applies only with confirmed=true; secret variables reach the run but are never stored, audited or returned), cancel_ansible_run, and create/update/delete_schedule (secrets refused, check by default). Admin: set_alert_action, and the docker plugin's prune_docker, which previews from the disk report unless check=false (Ansible's check mode skips the prune commands, so a check run would show nothing). Every write is audited as "<user> via MCP" with the token id; the audit tool's user filter includes those rows. prune_extra_vars moves to the docker service so the page and the tool share it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
23 lines
922 B
Python
23 lines
922 B
Python
"""Core MCP tool modules.
|
|
|
|
Each module defines plain `async def` tools at module level (tests call them
|
|
directly) and a `register(register_tool)` that lists them with their minimum
|
|
role. `register_tool(fn, role=..., read_only=...)` takes both as required
|
|
keywords: a tool with no declared role is unreachable, and there is no default
|
|
read_only for a mutating tool to inherit by forgetting.
|
|
|
|
A tool's docstring IS its contract with the agent — it ships as the tool's
|
|
description. Say what it is for, when to reach for it over its siblings, what
|
|
each argument's empty value means, and what comes back.
|
|
"""
|
|
from __future__ import annotations
|
|
|
|
from . import alerts, audit, automation, hosts, metrics, monitors, overview, session
|
|
|
|
_MODULES = (session, overview, hosts, monitors, alerts, metrics, audit, automation)
|
|
|
|
|
|
def register_all(register_tool) -> None:
|
|
for module in _MODULES:
|
|
module.register(register_tool)
|