Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Schimmilab/ipsymcon-mcp-server --skill ips-cleanupgit clone --depth 1 https://github.com/Schimmilab/ipsymcon-mcp-serverWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/schimmilab/ipsymcon-mcp-server/ips-cleanup)<a href="https://agentmods.dev/skills/schimmilab/ipsymcon-mcp-server/ips-cleanup"><img src="https://agentmods.dev/badge/skills/schimmilab/ipsymcon-mcp-server/ips-cleanup.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00056 | $0.00750 |
| Opus 5 | $0.00028 | $0.00375 |
| Sonnet 5 | $0.00011 | $0.00150 |
| Haiku 4.5 | $0.00006 | $0.00075 |
Grade A, and why
ips-cleanup scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 55 lines — stays where its author put it; the contents beside it link to each section on GitHub.
IP-Symcon cleanup & error review
Find what's broken or dead in an IP-Symcon system and resolve it: surface the instances in an error state and the dead/orphaned objects, then fix what's safely fixable and remove what's truly dead — without trading old errors for new orphans. Read-only review by default; every write goes through a plan you approve first.
REQUIRED BACKGROUND: the ipsymcon skill — same MCP, same plan-before-you-touch rule, the
ips_call gateway and type-specific deletes. This is cleanup-specific orchestration on top.
Why it exists (the trap it prevents)
"The logs are always red" is usually a handful of broken instances spamming errors, not a hopeless mess — but removing a broken instance naively orphans everything connected to it. A device connects to its gateway via ConnectionID, not as a tree-child — so a children+links check reports "0 dependencies" and is dangerously wrong. (Verified live: a Hue bridge showed 0 children / 0 links, yet had 4 lamps connected via ConnectionID.) This skill always checks three vectors before deleting, and removes bottom-up.
Relationship to migration
This is Phase 0 of a migration: clean the source first, so a greenfield migrate
(ips-migration skill) carries a healthy system across instead of re-implementing the cruft. Also
useful standalone as a periodic health check.
The phases
1 Review (read-only) → 2 Triage (you decide) → 3 Safe removal (plan-first)
↘ 4 Fix (apply safe, flag creds) → 5 Verify
Step-by-step, the ready-to-run scan scripts and the delete-order rules: references/workflow.md.
The non-negotiables
- Review is read-only. Phases 1–2 never write. Surfacing problems ≠ changing the system.
- Look for what still runs, not only for what is red. An active event on a dead branch keeps
polling APIs and keeping stale credentials in use while every status reads
102. Phase 1b. Deactivating an event is the cheap, reversible first move — propose it before any removal plan. - Three-vector dependency check before ANY instance delete — children · incoming links · ConnectionID. Skipping ConnectionID is exactly how you create new red while removing old red.
- Plan-first for every write. Present the full removal cascade / fix set, then STOP for approval.
- Delete bottom-up, type-specific. Connected devices before their gateway, children before
parents;
IPS_DeleteVariable/Category/Script/Event/Instance/Link— there is no generic delete. - Never guess credentials. API keys, cloud logins, passwords → diagnose and flag for the
human. Apply only what's safe on your own (re-apply config,
IPS_ApplyChanges, reconnect). - Write-gated (
IPS_ENABLE_WRITE); an IPS backup is the safety net, the plan is the guardrail.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 55 lines · 56 tokens per session scan A bb72c384ee5d
ips-cleanup is a skill published in the GitHub repository Schimmilab/ipsymcon-mcp-server (0 stars, last pushed yesterday), licensed MIT. It adds 56 tokens to every session and 750 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
home-assistant-rest
Control and query Home Assistant through the connector's callservice tool — REST API patterns, common domains, how to find entities before acting.
devices-mcp-home
Live inventory of the user's smart home on this devices-mcp installation — cameras, Hue lights, Tapo P115 plugs, Netatmo weather, Ring, Nest Protect, Shelly sensors, and robots. Use when the user asks what devices they have, what's online, or wants a status summary before controlling hardware.
gke-ai-troubleshooting-tpu-dynamic-slices-monitoring
Monitors, troubleshoots, and manages GKE TPU Dynamic Slices custom resources. Use when checking TPU slice lifecycle states, troubleshooting slice provisioning failures, validating single-slice or multi-slice (JobSet) workload manifests, or safely patching stuck finalizers and disabling the slice controller. Don't use…
gke-ai-troubleshooting-tpu-vbar-oom
Diagnoses and prevents vbarcontrolagent segfaults, out-of-memory (OOM) errors, and TPU device initialization failures on TPU v6e nodes in GKE caused by race conditions during TPU device resets or high-frequency metrics polling. Use when troubleshooting vbarcontrolagent crashes, memory cgroup OOMs in serial console…
doca-flow
Build and debug DOCA Flow applications on supported NVIDIA NICs/DPUs: define match/action pipes, initialize ports and representors, choose forwarding targets, validate pipes before hardware programming, read counters, match the Flow version to the installed DOCA release, and diagnose Flow API errors. Trigger on DOCA…
diagnose-driver-install
Diagnose NVIDIA driver installation failures on DeepOps-managed nodes — nvidia-smi errors, "No devices were found", DKMS build failures, or GPU pods crash-looping. Use before reinstalling anything.