LABSCO SUMMARY

Rug-pull detection needs a baseline, so create one first.

The attack this catches that a config scan cannot is a server that looked fine when you approved it and changed its tool definitions afterwards. That only works if there is a recorded baseline to compare against, which is a separate command you run before the proxy is any use for it. The other half worth knowing is the asymmetry in safety: scanning a config is inert, running the proxy launches whatever that config says to launch — so the Docker path is the right one for anything you did not write.

What it is

A security tool for MCP infrastructure with two modes. Static analysis reads a config file and looks for the attacks that live in tool descriptions. Runtime protection puts a proxy between your client and the real server, inspecting traffic in both directions and quarantining what looks wrong. Everything runs locally — no cloud API, no account.

What you get

14 detection rules, 7 static and 7 runtime
Static rules over a config file: prompt injection in tool descriptions, semantic poisoning caught by local ONNX embeddings, data exfiltration patterns, hardcoded credentials, command injection, hidden unicode and base64 obfuscation, and unencrypted transports
Runtime rules over live traffic: ANSI terminal manipulation, prompt injection in server responses, credential and PII leaks across tools, rug pulls where a server silently changes its tool definitions after you approved them, homoglyph and typosquatting tool shadowing, multi-step attack chains, and statistical anomalies
A baseline of approved tool definitions you create and then enforce, which is what makes rug-pull detection possible at all
Quarantined responses held for review and released when you decide, plus traffic logs you can list, search and summarise
Reported results: 83% detection on a 23-vector research attack corpus, 100% on real-world CVE patterns, no false positives on legitimate tool descriptions, validated against named public exploits rather than synthetic ones
CI-friendly output: JSON format, severity filtering, and exit codes of 0 for clean, 1 for findings and 2 for critical findings

Requirements

Python 3.10+ and pip install glyph-scan; the package is glyph-scan (version 0.3.0) and the command is glyph. No account, no cloud API, no key — the ML analysis runs on local ONNX. One warning worth taking seriously: static scanning is safe because it only parses JSON, but runtime scanning spawns the processes defined in the config, and a malicious config can contain arbitrary commands. For untrusted configs the README's answer is to run the proxy inside Docker with the config mounted.

Setup effort

One command — pip install glyph-scan

See installation options

USE CASES

01

Checking a server before you connect to it

Scan the config statically — it only parses JSON, so nothing is executed — and read the findings by severity.

02

Catching a server that changes after approval

Record a baseline of the tool definitions you accepted, then run the proxy so any silent change is flagged as a rug pull.

03

Blocking injection that arrives in a response

Run traffic through the proxy so hidden instructions and ANSI manipulation in server output are sanitised before they reach the client.

04

Gating MCP configs in CI

Run the scan with JSON output and let the exit code fail the build on critical findings.

05

Inspecting a config you do not trust

Run the runtime scan inside a container with the config mounted, since the proxy spawns whatever the config defines.

BEFORE YOU INSTALL

What to know first

Requires

pip on PATH

INSTALLATION

Connect your client

This project publishes no client configuration, so the entry for your client is yours to write.

Server setup

TERMINAL

pip install glyph-scan

Glyph