The SecOps Toolkit MCP is a local defensive security server providing AI assistants with security analysis utilities for logs, threat intelligence, and network data — no API keys or external network calls required.
Extract IOCs (extract_iocs): Parse free-form text or log output to identify indicators of compromise, including IPv4 addresses, URLs, domains, MD5/SHA1/SHA256 hashes, and CVE IDs. Automatically handles defanged input (e.g., 1.2.3[.]4, hxxp://).
Defang Indicators (defang_ioc): Convert a potentially dangerous indicator (e.g., 1.2.3.4) into a safe-to-share defanged format (e.g., 1.2.3[.]4) suitable for reports or messaging.
Refang Indicators (refang_ioc): Reverse a defanged indicator back to its original, usable form (e.g., 1.2.3[.]4 → 1.2.3.4).
Hash Text (hash_text): Compute a cryptographic hash (MD5, SHA1, SHA256, or SHA512) of any input string.
Password Entropy (password_entropy): Estimate password strength by calculating bits of entropy based on the character set used, returning length, charset size, entropy bits, and a strength label.
CIDR Network Info (cidr_info): Describe an IPv4/IPv6 network in CIDR notation, including netmask, host range, total address count, broadcast address, and whether the network is private.
IP in CIDR Check (ip_in_cidr): Determine whether a given IP address falls within a specified CIDR network range.
A small, dependency-light Model Context Protocol server that gives an AI assistant a set of defensive security helpers for working with logs, threat-intel notes, and network data — all running locally, with no API keys and no outbound network calls.
Built with FastMCP.
Tool | What it does |
| Pull IPs, URLs, domains, MD5/SHA1/SHA256 hashes, and CVE IDs out of free-form text. Handles defanged input ( |
| Make an indicator safe to paste: |
| Reverse a defanged indicator back to its real form. |
| Hash a string with md5 / sha1 / sha256 / sha512. |
| Estimate password strength in bits of entropy. |
| Describe a CIDR network: netmask, host range, size, privacy. |
| Check whether an IP falls inside a CIDR range. |
| Check a repo's top-level directory for files that shadow common dev command names ( |
| Assess a shell command for constructs (quote fragmentation, command substitution, IFS tricks, encoded pipelines, setuid grants, env-var poisoning via |
These are defensive / analysis utilities — parsing, hashing, and network math. They don't scan, attack, or reach out to any host.
Related MCP server: wrg-mcp-server
Requires Python 3.11+ and uv.
git clone https://github.com/glatinone/secops-toolkit-mcp.git
cd secops-toolkit-mcp
uv sync
uv run secops-toolkit-mcp # starts the server over stdioThat's it, the server is now running and waiting for an MCP client to connect over stdio. Wire it into a client (below), or call the underlying functions directly in Python (see Examples).
Add this to your client's MCP config (e.g. Claude Desktop's
claude_desktop_config.json). Point --directory at where you cloned the repo:
{
"mcpServers": {
"secops-toolkit": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/secops-toolkit-mcp", "secops-toolkit-mcp"]
}
}
}Then ask your assistant things like "extract the IOCs from this alert" or "is 10.0.4.20 inside 10.0.0.0/16?" and it will call these tools.
secops-scan-reposcan_repo_root is also available outside an MCP client, as its own console
script, for the exact moment it matters most: right after you clone or
download a repo and before you open it in an agentic coding tool.
uv run secops-scan-repo /path/to/a/freshly-cloned-repo
# secops-scan-repo: /path/to/a/freshly-cloned-repo (4 top-level file(s), 1 symlink(s) scanned)
#
# [CRITICAL] git.exe shadows the 'git' command
# [CRITICAL] vendor_link is a symlink resolving outside the repo root, to /home/dev/.ssh/authorized_keysExits 0 on a clean directory, 1 if a finding is at or above
--min-severity (default medium, i.e. any finding), 2 on a bad path.
-f/--format json gives the same structure scan_repo_root returns, for
scripting. This makes it a one-liner in a pre-clone git hook:
#!/bin/sh
# .git/hooks/post-checkout (or a wrapper your clone script calls)
secops-scan-repo "$(git rev-parse --show-toplevel)" || {
echo "secops-scan-repo: refusing to continue, see findings above" >&2
exit 1
}If installed system-wide (uv tool install . or pip install .), drop the
uv run prefix and call secops-scan-repo directly.
The tools are plain functions in core.py, so
you can call them directly (e.g. in a REPL or a script) without going through
an MCP client:
from secops_toolkit_mcp.core import extract_iocs, defang_ioc, hash_text, password_entropy, cidr_info, ip_in_cidr, assess_shell_command
extract_iocs("Reached out to 1.2.3[.]4 and hxxp://evil.example.com, hash 5d41402abc4b2a76b9719d911017c592, see CVE-2024-1234")
# {'md5': ['5d41402abc4b2a76b9719d911017c592'], 'ipv4': ['1.2.3.4'],
# 'url': ['http://evil.example.com'], 'domain': ['evil.example.com'],
# 'cve': ['CVE-2024-1234']}
defang_ioc("http://1.2.3.4/payload")
# 'hxxp[://]1[.]2[.]3[.]4/payload'
hash_text("hello world")
# {'algorithm': 'sha256', 'hex_digest': 'b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9'}
password_entropy("Tr0ub4dor&3")
# {'length': 11, 'charset_size': 94, 'entropy_bits': 72.1, 'strength': 'strong'}
cidr_info("10.0.0.0/24")
# {'network': '10.0.0.0', 'netmask': '255.255.255.0', 'prefix_length': 24,
# 'version': 4, 'num_addresses': 256, 'is_private': True,
# 'first_host': '10.0.0.1', 'last_host': '10.0.0.254', 'broadcast': '10.0.0.255'}
ip_in_cidr("10.0.0.5", "10.0.0.0/24")
# True
scan_repo_root("/path/to/a/freshly-cloned-repo")
# {'path': '/path/to/a/freshly-cloned-repo', 'entries_scanned': 4,
# 'symlinks_scanned': 1, 'clean': False, 'findings': [
# {'kind': 'shadowed_name', 'filename': 'git.exe', 'shadows': 'git',
# 'severity': 'critical'},
# {'kind': 'symlink_escape', 'path': 'vendor_link',
# 'resolves_to': '/home/dev/.ssh/authorized_keys', 'severity': 'critical'}
# ]}
assess_shell_command("r'm' -rf /")
# {'command': "r'm' -rf /", 'risk': 'dangerous', 'logical_commands': [
# {'raw_segment': "r'm' -rf /", 'tokens': ['rm', '-rf', '/'],
# 'effective_command': 'rm -rf /',
# 'findings': ['bypassed_raw_pattern_match', 'denylisted_pattern'],
# 'raw_denylist_hits': [], 'normalized_denylist_hits': ['recursive_root_delete'],
# 'risk': 'dangerous'}
# ], 'substitutions': [], 'pipe_findings': [], 'bypassed_raw_pattern_match': True}
# Note raw_denylist_hits is empty: a filter matching the raw text "r'm' -rf /"
# finds nothing. normalized_denylist_hits catches it because the tokens are
# what a real shell would actually run.
assess_shell_command("echo cm0gLXJmIC8= | base64 -d | sh")
# {'command': 'echo cm0gLXJmIC8= | base64 -d | sh', 'risk': 'dangerous',
# 'logical_commands': [
# {'raw_segment': 'echo cm0gLXJmIC8=', 'tokens': ['echo', 'cm0gLXJmIC8='],
# 'effective_command': 'echo cm0gLXJmIC8=', 'findings': [], 'risk': 'safe', ...},
# {'raw_segment': 'base64 -d', 'tokens': ['base64', '-d'],
# 'effective_command': 'base64 -d',
# 'findings': ['pipe_decoded_content_to_interpreter'], 'risk': 'dangerous', ...},
# {'raw_segment': 'sh', 'tokens': ['sh'], 'effective_command': 'sh',
# 'findings': ['pipe_decoded_content_to_interpreter'], 'risk': 'dangerous', ...}
# ],
# 'pipe_findings': [{'type': 'pipe_decoded_content_to_interpreter',
# 'segments': ['base64 -d', 'sh']}], ...}
# The base64 blob decodes to "rm -rf /" -- decoding it is what turns opaque
# text into an executable payload, the same "danger only visible after a
# transform the filter doesn't model" shape as piping a fetch into a shell.
assess_shell_command("cd ~/.ssh && cat authorized_keys")
# {'command': 'cd ~/.ssh && cat authorized_keys', 'risk': 'dangerous',
# 'logical_commands': [
# {'raw_segment': 'cd ~/.ssh', 'tokens': ['cd', '~/.ssh'],
# 'findings': ['cd_into_sensitive_directory'], 'risk': 'dangerous', ...},
# {'raw_segment': 'cat authorized_keys', 'tokens': ['cat', 'authorized_keys'],
# 'findings': [], 'risk': 'safe', ...}
# ], 'cd_findings': [{'type': 'cd_into_sensitive_directory',
# 'segments': ['cd ~/.ssh', 'cat authorized_keys']}], ...}
# A bare "cd ~/.ssh" alone would be safe -- nothing acts on it yet. Chained
# with a further command, the second segment's own relative-path filename
# ("authorized_keys" alone, no path prefix) would slip past every other
# check here, since none of them know the effective working directory changed.
assess_shell_command("export PAGER='open -a Calculator'")
# {'command': "export PAGER='open -a Calculator'", 'risk': 'dangerous',
# 'logical_commands': [
# {'raw_segment': "export PAGER='open -a Calculator'",
# 'tokens': ['export', 'PAGER=open -a Calculator'],
# 'findings': ['denylisted_pattern'],
# 'normalized_denylist_hits': ['env_poisoning_assignment'],
# 'risk': 'dangerous', ...}
# ], ...}
# Flagged even with nothing chained after it -- unlike "cd ~/.ssh", a
# poisoned PAGER persists in the calling agent's shell session and can be
# triggered by a later, separately-approved command ("git branch", "man ls")
# this function never sees, since each call only assesses one command string.
assess_shell_command("typeset -i ${(e):-'$(open -a Calculator)'}")
# {'command': "typeset -i ${(e):-'$(open -a Calculator)'}", 'risk': 'suspicious',
# 'logical_commands': [
# {'raw_segment': "typeset -i ${(e):-'$(open -a Calculator)'}",
# 'tokens': ['typeset', '-i', '${(e):-$(open -a Calculator)}'],
# 'effective_command': 'typeset -i ${(e):-$(open -a Calculator)}',
# 'findings': ['zsh_forced_parameter_expansion'],
# 'raw_denylist_hits': [], 'normalized_denylist_hits': [],
# 'risk': 'suspicious'}
# ], 'substitutions': [], 'pipe_findings': [], 'bypassed_raw_pattern_match': False}
# Flagged "suspicious", not "dangerous": zsh's (e) flag forces evaluation of the
# default value even though it's single-quoted, so the embedded $(open -a
# Calculator) runs anyway -- but (e) also has legitimate non-malicious uses,
# so this function can't claim certainty from the text alone.From an MCP client, the same calls happen through natural language, for example asking "hash this string with sha256" or "describe the network 10.0.0.0/24".
scan_repo_root existsMindgard disclosed (2026-07-15) that Cursor, GitHub Copilot CLI, Gemini CLI,
and Codex all resolve an unqualified git command on startup. Windows checks
the current working directory before PATH, so a cloned repo that ships a
file literally named git.exe at its root runs that file instead of the real
Git — before any workspace-trust prompt appears. As of this writing none of
the four vendors has shipped a fix.
scan_repo_root closes this independent of which tool eventually opens the
repo: point it at a directory before you open it (or wire it into a
pre-clone/pre-open hook) and it flags any top-level file whose name shadows a
commonly unqualified-invoked command (git, node, npm, python, bash,
docker, and similar), tiered by how directly the shape has been confirmed
exploitable:
critical — git, the name Mindgard's disclosure confirmed end-to-end.
high — shells and interpreters (node, npm, npx, python, bash,
cmd, powershell, ...) that agentic tools commonly invoke unqualified.
medium — other common dev tools (docker, make, curl, ssh, gh,
...) plausibly invoked the same way but not confirmed by the disclosure.
Only the top-level directory is checked, matching how Windows's own
unqualified-command search actually works (current directory, then PATH —
it does not recurse into subdirectories).
Wiz's "GhostApproval" (Amazon Q, Cursor) and Cursor's "DuneSlide"
(CVE-2026-50548/50549, CVSS 9.3-9.8) disclosures are a second, unrelated
masquerading shape: an approval dialog or sandbox check displays a decoy
path while a symlink silently redirects the actual write target outside the
trusted directory — up to and including ~/.ssh/authorized_keys. Both are
zero-click once triggered by a prompt-injected agent action.
scan_repo_root also walks the whole repo tree (not just the top level —
a planted symlink can sit anywhere a tool later writes through it) and
flags any symlink whose resolved target lies outside the scanned root:
critical — the resolved target hits a known sensitive path (an
.ssh/.aws/.gnupg/.docker/.kube/.azure directory, or a private
key/credential filename like authorized_keys, id_rsa, .npmrc,
.git-credentials).
high — resolves outside the root to anywhere else.
A symlinked directory's own contents are never walked into (only the symlink entry itself is inspected), so this can't be tricked into recursing outside the intended scan boundary.
assess_shell_command existsGuardFall (2026-06) tested 11 popular open-source AI coding agents (Aider,
Cline, Goose, Plandex, and others — roughly 548,000 combined GitHub stars)
and found that 10 of them run a command-safety guard which inspects the raw
string a model wrote, then hands that same string to a real shell. The shell
rewrites the string before anything executes: quotes get removed, backslash
escapes get resolved, $(...)/backtick command substitutions run, and
variables (including $IFS, the field separator, which defaults to
whitespace) get expanded. A guard that pattern-matches the raw text has
already lost by the time any of that happens. r'm' -rf / doesn't look like
rm -rf / to a regex, but a shell dequotes and concatenates it into exactly
that.
assess_shell_command closes that gap by tokenizing with the same
POSIX quote-removal rules a real shell uses (shlex), so the normalized
command is what gets checked, not the raw string. It also:
Extracts $(...)/backtick command substitutions and recursively assesses
the command hidden inside them.
Flags unquoted variable expansion, $IFS-based space-substitution tricks,
ANSI-C ($'...') quoting, and unbalanced quotes — constructs whose real
effect can't be determined from the text alone.
Flags a fetch piped straight into an interpreter (curl ... | sh), or an
encoded payload decoded and piped straight into one (base64 -d | sh,
xxd -r | sh) — patterns that give you no chance to inspect what you're
about to run.
Flags setuid grants (chmod +s, chmod 4755, install -m 4755) and
overwriting a credential file in place (sed -i/tee targeting
~/.aws/credentials, ~/.ssh/authorized_keys, and similar).
Flags a symlink whose target or link name lands on a sensitive path
(ln -s ~/.ssh/id_rsa ./notes.txt), and a cd into a sensitive directory
chained with a further command that would act on relative paths inside it
(cd ~/.aws && cat credentials) — the shell-level shape of Cursor's
DuneSlide disclosure (see below).
Flags export/typeset/declare/readonly/local assigning a
behavior-redirecting variable (PAGER, BROWSER, PYTHONWARNINGS,
PERL5OPT), and zsh's zero-click ${(e):-...} forced-parameter-expansion
construct — Cursor's Terminal Tool Allowlist Bypass disclosure (see below).
It never executes the command, or any part of it, at any point — this is
static text analysis, not a sandbox. Returns risk (safe, suspicious, or
dangerous) plus bypassed_raw_pattern_match: concrete, per-call evidence
that a normalized check caught something a raw-text filter would have missed.
The bypass classes above aren't a guess at what GuardFall's disclosure might
cover — they were checked directly against GuardFall's own published
write-ups (not a summary of them). Confirmed already caught: quote
fragmentation/merge (r''m, r'm' -rf /), $IFS-as-space substitution,
command substitution used as an argument, backtick substitution, ANSI-C
quoting. Two real gaps found and closed in this pass: the encoded-pipeline
class (echo <base64> | base64 -d | sh) and several "alternative destructive
utility" shapes the denylist didn't cover (setuid grants, in-place credential
file overwrites, and $HOME/~-relative sensitive paths like
rm -rf "$HOME/.aws/credentials", GuardFall's own cited real-world example).
One limitation is deliberate, not missed: a command substitution that
computes the command name itself ($(echo rm) -rf /) can only be flagged
suspicious, not dangerous, without actually running the substitution to
see what it produces — and running untrusted code to decide whether it's
safe to run defeats the point. See tests/test_core.py's "GuardFall
disclosed corpus" section for the full payload-by-payload results.
Cursor's DuneSlide disclosure (CVE-2026-50548/50549, see the symlink-escape
section above) is two write-sandbox escapes: an agent-controlled
working_directory parameter that silently expands the writable-path
allowlist, and a symlink whose target the sandbox trusts instead of
rejecting when canonicalization fails. scan_repo_root's symlink-escape
check already finds a symlink planted in a repo before it's opened —
but neither Cursor bug is about a pre-existing file; both are about what
the agent's own command does mid-session, which is assess_shell_command's
job, not scan_repo_root's.
Checked structurally against parsed tokens, the same way as the rm
sensitive-target check above (ln's and cd's flags vary too much for a
single regex), reusing the same sensitive dir/file name list:
ln -s/ln --symbolic, when its target or its link name hits a
known-sensitive path (.ssh/.aws/.gnupg/.docker/.kube/.azure, or
a credential filename like authorized_keys/id_rsa) — either side can
be the sensitive one, since the attack's whole point is to make one side
look innocent.
cd into a known-sensitive directory, only when chained (&&, ;,
a pipe, or a newline) with a further command — a bare cd ~/.ssh with
nothing acting on it afterward hasn't done anything yet, the same
"danger is in the combination" posture pipe_findings already uses for
fetch-piped-to-interpreter.
A plain hard link (ln with no -s) is a structurally different, lower-risk
operation and stays out of scope. Both checks tokenize with the same quote-
removal and $IFS-expansion rules as everything else in this function, so
l'n' -s ~/.ssh/authorized_keys ./x and cd$IFS~/.aws && cat credentials
are caught too, not just the unobfuscated form.
Cursor's Terminal Tool Allowlist Bypass (CVE-2026-22708, fixed in 2.3) is a
third, distinct bypass mechanism: a command allowlist validates which
external binary runs, but shell builtins aren't external binaries, so
export, typeset, declare, readonly, and local execute unconditionally
regardless of what's on the allowlist. An attacker (via prompt injection) uses
one of them to poison an environment variable a later, separately-approved
command reads — PAGER hijacks git branch/man ls, BROWSER hijacks a
URL-opening command, PYTHONWARNINGS/PERL5OPT chain into arbitrary
Python/Perl execution the next time those interpreters run. None of this
requires ever executing a disallowed command string.
assess_shell_command flags an export/typeset/declare/readonly/local
invocation that assigns one of these variables as dangerous on its own —
deliberately not requiring a chained follow-up command in the same string,
unlike the DuneSlide cd check above. A poisoned PAGER persists in the
calling agent's shell session; the command that actually gets hijacked is
usually issued in a later, separate tool call this function has no visibility
into, so the poisoning step itself is what has to be caught:
assess_shell_command("export PAGER='open -a Calculator'")
# risk: dangerous — flagged even though nothing in *this* command string
# reads PAGER back yet.The disclosure's PoC also included a zero-click variant with no export step
at all: zsh's ${(e):-...} parameter-expansion flag forces evaluation of its
default value even when that value is single-quoted —
typeset -i ${(e):-'$(open -a Calculator)'} runs the embedded command despite
the quotes that would normally disable expansion, bypassing the same
single-quote assumption this function's own command-substitution extraction
relies on elsewhere. Flagged as zsh_forced_parameter_expansion, a construct
whose real effect can't be determined from the text alone — the same honest
treatment as ifs_manipulation/ansi_c_quoting, not overclaimed as
dangerous on its own since (e) also has legitimate, non-malicious uses.
Deliberately out of scope: unset and set, which the same disclosure also
names as bypassing the allowlist, but neither can carry a VAR=value
assignment the way export/typeset/declare/readonly/local do —
unset only removes a variable, and set (without -o) manipulates
positional parameters, not the environment. And LD_PRELOAD, a well-known
dangerous variable elsewhere, isn't in this list since it wasn't part of this
disclosure's own confirmed PoC payloads — added only if a future disclosure
or real-world case demonstrates it.
The included Dockerfile builds a container that launches the server over
stdio, so an MCP client can run it without a local Python/uv install:
docker build -t secops-toolkit-mcp .
docker run -i --rm secops-toolkit-mcpTo use it from an MCP client, point the client's config at docker run
instead of uv run:
{
"mcpServers": {
"secops-toolkit": {
"command": "docker",
"args": ["run", "-i", "--rm", "secops-toolkit-mcp"]
}
}
}Client shows the server as disconnected / no tools listed. MCP clients
talk to this server over stdio, so anything else printed to stdout will
break the protocol. Confirm you're running uv run secops-toolkit-mcp (or
the Docker command above) exactly, not piping it through another wrapper
that adds its own output.
--directory path errors in the client config. The path must be
absolute and point at the cloned repo root (the folder containing
pyproject.toml), not the src/ directory.
ValueError from hash_text, cidr_info, or ip_in_cidr. These raise
on bad input (unsupported hash algorithm, malformed IP/CIDR) with a message
naming the invalid value, by design, rather than failing silently.
Python version errors during uv sync. The project requires Python
3.11+ (see .python-version); uv will fetch a matching interpreter
automatically if one isn't already installed.
uv sync # install deps (incl. dev)
uv run pytest # run the test suiteThe logic lives in core.py as plain,
testable functions; server.py is a thin
layer that exposes them as MCP tools.
See CONTRIBUTING.md for the full workflow for adding a new tool, and CHANGELOG.md for release history.
Initial tool set: IOC extraction, defang/refang, hashing, password entropy, CIDR math (v0.1.0)
CI on Python 3.11 to 3.13, CHANGELOG (v0.2.0)
scan_repo_root, a pre-clone/pre-open check for binaries that shadow
common dev command names (v0.3.0), closing the Mindgard 2026-07-15
unqualified-git disclosure
assess_shell_command, a shell command safety check that assesses
what a shell actually runs rather than the raw string a model wrote
(v0.4.0), closing the GuardFall 2026-06 bypass class
secops-scan-repo, a standalone CLI for scan_repo_root (v0.5.0), so
it can run in a pre-clone git hook or CI step without an MCP client
scan_repo_root symlink-escape check (v0.6.0): flags a symlink
anywhere in the repo tree whose resolved target lies outside the repo
root, closing the GhostApproval/DuneSlide hidden-write-target pattern
assess_shell_command validated directly against GuardFall's disclosed
bypass corpus (v0.7.0), not just a research digest of it — closed two real
gaps found this way: encoded pipelines (base64 -d | sh, xxd -r | sh)
and alternative destructive-utility shapes (setuid grants, in-place
credential-file overwrites, $HOME/~-relative sensitive rm targets)
assess_shell_command widened for Cursor's DuneSlide disclosure
(v0.8.0): flags an agent-issued ln -s/ln --symbolic targeting (or
named after) a sensitive path, and a cd into a sensitive directory
chained with a further command — the shell-level shape of both
CVE-2026-50548 (working_directory abuse) and CVE-2026-50549 (symlink
canonicalization bypass)
assess_shell_command widened for Cursor's Terminal Tool Allowlist
Bypass (v0.9.0, CVE-2026-22708): flags export/typeset/declare/
readonly/local assigning a behavior-redirecting variable (PAGER,
BROWSER, PYTHONWARNINGS, PERL5OPT) that a later, separately-approved
command would then respect — a structurally distinct bypass from the
GuardFall and DuneSlide shapes above, since it attacks what a trusted
command's environment inherits, not what command string runs. Also
flags zsh's zero-click ${(e):-...} forced-parameter-expansion construct
Widen scan_repo_root's shadowed-name/extension coverage, its
sensitive-target symlink list, and assess_shell_command's denylist
patterns as real-world use surfaces gaps; all three are intentionally
high-signal, not exhaustive (see the module comments in core.py)
PyPI packaging, once the same pattern is proven end to end on mcpscan first
Contributions welcome, open an issue or PR.
MIT — see LICENSE.
Assess a shell command for constructs that look benign to naive string matching but execute something else once a shell actually expands them.
Closes the bypass class GuardFall (2026-06) confirmed against 10 of 11 popular open-source AI coding agents (Aider, Cline, Goose, Plandex, and others): their command-safety guards check the raw string a model wrote, not what the shell rewrites it into via quote removal, backslash escapes, command substitution, and variable/IFS expansion. Never executes the command or any part of it.
Tokenizes with real POSIX quote-removal rules so quote-fragmented or
backslash-obfuscated commands (r'm' -rf /) normalize to what actually
runs (rm -rf /) before any check. Flags command substitution
($(...), backticks, recursively assessed), unquoted variable
expansion, IFS manipulation, ANSI-C quoting, a fetch or encoded-payload
decode piped straight into an interpreter (curl ... | sh,
base64 -d | sh), setuid grants (chmod +s, install -m 4755),
and in-place credential-file overwrites (sed -i/tee targeting
~/.aws/credentials and similar). Also flags the shell-level shape of
Cursor's DuneSlide disclosure (CVE-2026-50548/50549): a symlink whose
target or link name lands on a sensitive path (ln -s ~/.ssh/id_rsa ./notes.txt), and a cd into a sensitive directory chained with a
further command that would act on relative paths inside it (cd ~/.aws && cat credentials). Also flags Cursor's Terminal Tool Allowlist
Bypass (CVE-2026-22708): export/typeset/declare/readonly/
local assigning a behavior-redirecting variable (PAGER,
BROWSER, PYTHONWARNINGS, PERL5OPT) that a later, separately-
approved command would then respect, plus zsh's zero-click ${(e):-...}
forced-parameter-expansion construct. Returns risk (safe,
suspicious, or dangerous), per-segment findings, and
bypassed_raw_pattern_match -- concrete evidence a normalized segment
caught something the raw text alone would have missed.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that the tool never executes the command, tokenizes with POSIX rules, and returns risk levels and findings. It also explains the types of dangerous constructs flagged (e.g., command substitution, variable expansion, symlink attacks). Since no annotations are provided, the description fully carries the burden of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured, starting with the overarching purpose, then detailing specific attack classes, and ending with output fields. While slightly long, every sentence adds value, making it appropriately detailed for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, behavior, output (risk, findings, bypassed_raw_pattern_match), and specific attack patterns. It is complete for an agent to understand when and how to use the tool, especially given the complexity and the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'command', which is a string. The description adds meaning by explaining it is a shell command to assess, but the schema is minimal (0% coverage). Given the single obvious parameter, the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses shell commands for constructs that bypass naive string matching, listing specific attack classes (GuardFall, DuneSlide, Terminal Tool Bypass). It is distinct from sibling tools (e.g., refang_ioc, extract_iocs) which deal with IOCs, not shell commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool (when you need to detect obfuscated shell commands) but does not explicitly state when not to use it or name alternatives. However, the specificity makes usage clear, and no sibling tool performs similar analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe an IPv4/IPv6 network: netmask, host range, size, and privacy.
Accepts CIDR notation such as 192.168.0.0/24 or 10.0.0.5/8.
| Name | Required | Description | Default |
|---|---|---|---|
| cidr | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral transparency. It implies a read-only operation ('Describe') and lists return attributes, but does not explicitly state safety, authorization needs, or potential side effects. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—with the purpose stated upfront and an example immediately following. Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no annotations), the description covers core functionality and input format. The output schema is present, so return values are not required in the description. It is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by providing concrete examples of valid CIDR notation (e.g., '192.168.0.0/24' and '10.0.0.5/8'). This adds significant meaning beyond the schema's bare parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to describe an IPv4/IPv6 network, listing specific attributes like netmask, host range, size, and privacy. It differentiates well from siblings such as ip_in_cidr, which focuses on IP membership checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ip_in_cidr or extract_iocs. The description lacks explicit context for appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an indicator safe to share by defanging it (1.2.3.4 -> 1.2.3[.]4).
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only reveals the transformation effect. It does not disclose any side effects, reversibility, permissions, or other behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. However, it could be slightly improved by expanding on parameter semantics without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transformation tool with one input and a likely clear output, the description is mostly complete. The missing parameter detail is a gap, but overall it provides sufficient context for an agent to understand the tool's core function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the 'indicator' parameter but only gives an IP example. It does not clarify what types of indicators are accepted (e.g., IPs, URLs, hashes), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('make an indicator safe to share by defanging it') and provides an example transformation. It distinguishes itself from the sibling tool 'refang_ioc' by specifying the defanging direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when sharing indicators safely, but does not explicitly state when to use this tool vs alternatives (e.g., refang_ioc) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract indicators of compromise from free-form text or log output.
Finds IPv4 addresses, URLs, domains, MD5/SHA1/SHA256 hashes, and CVE IDs.
Defanged indicators (1.2.3[.]4, hxxp://) are handled automatically.
Returns a dict keyed by indicator type; only types that were found appear.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it returns a dict keyed by indicator type (only types found) and handles defanged indicators, but does not specify behavior for empty inputs (e.g., returns empty dict or None) or any performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no unnecessary words. The main purpose is front-loaded, and every sentence adds useful information. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no annotations, and an output schema (not shown), the description covers the core functionality, supported IOC types, and return format. However, it omits details about how to handle cases with no indicators found, which is a minor gap for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter 'text' with 0% schema description coverage. The description adds that it expects free-form text or log output, but no further details on constraints like length, encoding, or format are provided, which is minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts indicators of compromise from free-form text or log output. It lists specific indicator types (IPv4, URLs, domains, hashes, CVE IDs) and mentions handling defanged indicators, which distinguishes it from sibling tools like defang_ioc and refang_ioc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for text containing IOCs and mentions defanged handling, but it does not explicitly state when to use this tool over alternatives like hash_text or cidr_info. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a cryptographic hash of a string.
algorithm is one of md5, sha1, sha256 (default), or sha512.
Returns the algorithm used and the lowercase hex digest.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| algorithm | No | sha256 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the behavior: compute a hash, algorithm options, and return format (algorithm + hex digest). No side effects or permissions needed, so adequate for a pure function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Front-loaded with the action verb and resource. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no nested objects) and existence of an output schema, the description fully covers what the tool does and returns. No gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining the text parameter as the string to hash and listing the algorithm options (md5, sha1, sha256, sha512) with a default. This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a cryptographic hash of a string, which is a specific verb and resource. It lists the supported algorithms and default, and it is distinct from sibling tools that handle IOCs and entropy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, but sibling tools are clearly unrelated (IOC handling, CIDR), so it is evident this tool is for hashing strings. Context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an IP address falls inside a given CIDR network.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | ||
| cidr | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'check whether', which is read-only, but fails to mention error conditions (e.g., invalid IP or CIDR format), or any additional side effects. The output schema exists but its details are not visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no redundant information, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two string parameters) and the presence of an output schema, the description is minimally complete. However, it lacks guidance on input formats, edge cases, and how it complements sibling tools like 'cidr_info'. With no annotations, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema has no descriptions for the two parameters. The tool description does not add any semantic details, format hints, or examples for 'ip' or 'cidr' strings, leaving the agent without guidance on valid input formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and the resource 'IP address falls inside a given CIDR network'. It is distinct from sibling tools like 'cidr_info' which returns info about a CIDR, and other sibling tools are unrelated to IP/CIDR checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing IP membership in a CIDR network, but does not explicitly state when to use this tool versus alternatives (e.g., 'cidr_info'), nor does it mention when not to use it. It relies on the agent inferring the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate password strength as bits of entropy over the charset used.
Returns length, charset size, entropy in bits, and a strength label. This is a quick floor estimate, not a check of whether a specific password is on a breach list.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must carry full weight. It explains the tool is non-destructive (read-only estimation) and describes return values and limitation. Good for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, directly conveys purpose and limitations. Perfectly sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and presence of output schema, description covers return values and key limitation. Could mention if password is sensitive, but otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% and description adds no extra meaning for the single 'password' parameter. It's obvious from context, but no format, length constraints, or sensitivity warnings provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool estimates password strength as bits of entropy, returns specific fields, and distinguishes it from breach checking. Sibling tools are unrelated, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes it's a quick floor estimate and not a breach list check, implying its use case. Could detail when to use exactly, but siblings are distinct so not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse a defanged indicator back to its real form (1.2.3[.]4 -> 1.2.3.4).
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It accurately describes the transformation with an example. However, it does not mention error handling, input validation, or any side effects. For a simple transformation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus an example. No wasted words. Front-loaded with action and example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no enums, output schema exists), the description is nearly complete. It lacks details on validation or edge cases, but the core functionality is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds context via an example but does not explain what constitutes a defanged indicator or the expected format. This is a gap when the schema provides only a type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Reverse a defanged indicator back to its real form' with an illustrative example. It distinguishes this tool from its counterpart 'defang_ioc' by specifying the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a defanged indicator needs to be restored, but does not explicitly state when not to use or mention alternatives. The sibling tool 'defang_ioc' provides natural contrast, but explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a repo's top-level directory for files that shadow common
developer command names (git.exe, node.exe, npm.cmd, etc.),
and the whole tree for symlinks that resolve outside the directory.
Run this before opening a freshly cloned or downloaded repository in an
agentic coding tool. On Windows, several tools (Cursor, GitHub Copilot
CLI, Gemini CLI, Codex) resolve an unqualified command like git from
the current directory before PATH, so a malicious repo shipping its own
git.exe at the root runs instead of the real one, before any
workspace-trust prompt appears. Severity: critical for git (the
confirmed vector), high for shells/interpreters, medium for other common
dev tools. Only the top-level directory is checked for this, not
subdirectories.
Separately, a symlink anywhere in the tree whose resolved target lies
outside this directory is flagged too (the GhostApproval/DuneSlide
hidden-write-target pattern: an approval dialog shows a decoy path while
the symlink redirects the real write elsewhere, e.g.
~/.ssh/authorized_keys). Critical if the resolved target hits a known
sensitive path (SSH/cloud-credential directories, private key files),
high otherwise.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and effectively discloses behavior: it checks top-level for shadowed executables and whole-tree for external symlinks, with severity levels. It does not mention non-destructive nature or auth needs, but these are implied by scanning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the purpose and then detailing two distinct checks with rationale. It is relatively long but every sentence adds value, explaining the threat model and severity. Minor trimming possible but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two scanning operations, no annotations, and an output schema present (so return values don't need explanation), the description is complete. It covers what is checked, why, severity, and the security patterns involved. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required 'path' parameter, but the description provides no explicit definition or example of what the path should represent. With 0% schema description coverage, the description must compensate, but it only implies the path via context. This is insufficient for unambiguous parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a repo's top-level directory for shadowed developer command names and the whole tree for external symlinks. This is specific, actionable, and distinguishes it from sibling tools which focus on IOCs and text manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises running this tool 'before opening a freshly cloned or downloaded repository in an agentic coding tool,' and explains the security rationale. It does not provide explicit when-not-to-use guidance or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose: IOC handling (defang/refang/extract), hashing, password entropy, CIDR operations, shell command assessment, and repo scanning. No overlap or ambiguity.
All tools use snake_case, but naming pattern varies between verb_noun (extract_iocs, scan_repo_root) and noun_noun (password_entropy, cidr_info). Mostly consistent but minor mixing.
9 tools cover a broad range of secops tasks without being excessive. Each tool adds value, and the count is well-scoped for the server's purpose.
Covers core secops areas: IOC handling, hashing, password analysis, CIDR, shell assessment, repo scanning. Minor gaps like URL analysis missing, but no critical dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/glatinone/secops-toolkit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
