Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@script-decoder-mcp analyze this PowerShell script and explain what it does"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A defensive, static-analysis MCP server that explains what a script does — in plain English and with technical evidence — without ever executing it.
Paste a Python, PowerShell, shell, JavaScript, batch, or VBScript script (or a single command line) and get back: a behavior breakdown (network, file, process, persistence, credential-access, discovery, defense-evasion, execution), safely decoded obfuscated content, extracted indicators of compromise, a transparent risk score, and a contextual MITRE ATT&CK mapping — all with source-line evidence and explicit observed/inferred/ possible classifications.
Defensive-use statement: this project performs static analysis only. It never executes, imports, compiles-for-execution, or otherwise runs submitted content. It never sends submitted scripts or decoded content to any third-party service. It is intended for SOC analysts, incident responders, and anyone who needs to understand an unfamiliar or suspicious script before deciding what to do with it — not to enable offensive use.
Five MCP tools: analyze_script, decode_blob, extract_indicators,
explain_command, compare_scripts.
A local browser GUI (see Browser GUI) for the same five analyses, with no MCP client required.
Six language analyzers: Python (AST-based), PowerShell, shell (bash/sh/zsh), JavaScript, batch, and VBScript (rule-based).
Bounded recursive decoding: Base64, Base32, hex, URL encoding, Unicode escapes,
HTML entities, gzip/zlib/bz2, ROT13, reversed strings, PowerShell
-EncodedCommand, integer/char-code arrays, simple string concatenation, and
explicit-key XOR — chained safely up to a configurable depth, with decompression-bomb
protection.
IOC extraction: URLs, domains, IPv4/IPv6, emails, file paths, registry keys,
hashes, mutex-like strings, user agents, named pipes, scheduled-task/service names, and
common cloud resource identifiers — including defanged-notation recognition
(hxxp, example[.]com, 10[.]0[.]0[.]1).
Transparent, documented risk scoring (0-100) with contributing factors listed in every response — never a black box, never a malware verdict.
Conservative, local, offline MITRE ATT&CK mapping.
Prompt-injection safe: all submitted and decoded content is treated as inert data, never as instructions, and is explicitly labeled as untrusted in evidence excerpts.
Optional, local, disabled-by-default CyberChef-style adapter for a small set of additional decode operations, with no network access and an operation allowlist.
No outbound network access is required or performed during analysis.
Related MCP server: KeyboardCrumbs MCP Server
See docs/architecture.md for the full breakdown. In short:
MCP client (e.g. Claude Desktop)
│ stdio (default) or localhost HTTP
▼
server.py (5 MCP tools)
│
├─ analyzers/ language detection + per-language static analysis (AST for
│ Python, regex/rule-based for the rest)
├─ decoding/ bounded recursive decoding engine, native decoders, optional
│ local CyberChef-style adapter
├─ extraction/ IOC extraction
├─ classification/ risk scoring + ATT&CK mapping
├─ reporting/ assembles the final structured response + summaries
└─ security/ sanitization and trust-boundary helpersNothing in this pipeline executes, imports, or evaluates submitted content. See
docs/threat-model.md for the full threat model and
SECURITY.md for the security policy.
Requires Python 3.12+.
python -m venv .venv
# Windows: .venv\Scripts\activate macOS/Linux: source .venv/bin/activate
pip install -e ".[dev]"Optional: Node.js 18+ if you want to enable the local CyberChef-style adapter (disabled by default; not required for any core functionality).
pip install -e ".[dev]"
python -m pytest
ruff check .
ruff format --check .
mypy srcDefault transport is stdio, which is what MCP clients like Claude Desktop expect:
python -m script_decoder_mcp
# or, after `pip install -e .`:
script-decoder-mcpSet SDMCP_TRANSPORT=http (see .env.example) to run over localhost
HTTP instead; it binds 127.0.0.1 by default and is never exposed remotely without
explicit additional configuration, which this project does not provide.
Prefer a browser over an MCP client? There's a local web GUI that calls the exact same
analyzer/decoder code as the MCP tools -- it's a thin FastAPI wrapper around
reporting/formatter.py, not a separate implementation, so results never drift from the
MCP server.
pip install -e ".[web]"
python -m script_decoder_mcp.web.app
# or: make webThen open http://127.0.0.1:8787. It has one tab per tool (Analyze Script, Decode
Blob, Extract Indicators, Explain Command, Compare Scripts), plus "Load good/bad example"
buttons that load examples/good_script_benign.py and
examples/bad_script_suspicious.py for a quick
before/after. Like the MCP server, it binds to 127.0.0.1 only by default
(SDMCP_WEB_HOST/SDMCP_WEB_PORT to change), has no authentication, is not meant to be
exposed beyond localhost, and never sends anything you paste anywhere beyond your own
machine.
Add to your MCP client config (see
examples/claude-desktop-config.example.json
and examples/mcp-client-config.example.json):
{
"mcpServers": {
"script-decoder": {
"command": "script-decoder-mcp",
"args": []
}
}
}If you haven't installed the console script, point command at the venv's Python and
args at ["-m", "script_decoder_mcp"] instead.
analyze_scriptStatically analyzes a full script. Input: content (required), language (default
auto), filename, decode_embedded_content (default true),
include_line_references (default true), analysis_depth (quick/standard/deep,
default standard), map_to_attack (default true).
Returns a schema_version-stamped response with summary, plain_language_summary,
analyst_summary, verdict, risk_score, risk_factors, behaviors (each with
category, title, description, evidence, source_lines, confidence,
classification — observed/inferred/possible — and severity),
decoded_artifacts, indicators, imports/functions/commands,
suspicious_constructs, attack_techniques, limitations, errors, and
analysis_metadata. execution_performed is always false.
decode_blobDecodes a single encoded/obfuscated value. Input: content (required),
encoding_hint, max_depth, use_cyberchef (default false). Returns the detected
encodings, every attempted decode chain, the successful chain (if any), decoded
text/size/hashes, any indicators found in the decoded text, and warnings. Never claims to
decode arbitrary encryption and never brute-forces a password or key.
extract_indicatorsExtracts IOCs from arbitrary text or source. Input: content (required). Returns a
dictionary of indicator categories, each entry carrying value, normalized_value,
type, source_lines, context, confidence, and defanged_value.
explain_commandExplains a single command line. Input: command (required), shell
(auto/cmd/powershell/bash/zsh/python, default auto), include_tokens.
Returns executable, arguments, pipelines, redirections, environment changes, possible
side effects, and suspicious features — never runs the command.
compare_scriptsDiffs two versions of a script. Input: original_content, new_content, language
(default auto), decode_embedded_content (default true). Returns added/removed
behaviors, changed indicators, newly decoded artifacts, the risk-score delta, and
line-level change summary.
See examples/sample_requests.md.
Disabled by default (SDMCP_CYBERCHEF_ENABLED=false). When enabled, decode_blob
(with use_cyberchef: true) can fall back to a small local Node.js worker
(cyberchef-worker/index.mjs) for a fixed, allowlisted set of operations: From Base64,
From Base32, From Hex, URL Decode, HTML Entity Decode, Gunzip, Zlib Inflate,
ROT13, Reverse.
Deviation from the original design: rather than depending on the cyberchef npm
package (a large dependency tree), the worker reimplements these named operations using
only Node.js built-ins, in a single auditable file. It performs no network access, no
filesystem access beyond stdin, and no dynamic code loading. See
cyberchef-worker/README.md for details and how to extend
it. It is never called against a public CyberChef instance, and native Python decoders
remain fully functional with or without it.
docker compose build
docker compose run --rm script-decoder-mcpThe image runs as a non-root user, uses a multistage build, and does not require network
access at runtime. See Dockerfile and
docker-compose.yml.
Static analysis only: no eval/exec/compile-for-execution of submitted content, no
os.system/shell=True on submitted content, no importing of submitted scripts, no
outbound network requests, no DNS resolution, no reputation-service calls.
Every resource limit (input size, decode output size, decompression size, recursion
depth, candidate branches, analysis duration, indicators per category, evidence excerpt
length) is documented in .env.example and enforced in
src/script_decoder_mcp/limits.py; a threshold
being hit is always reported as a limitation, never silently ignored.
All submitted and decoded content is treated as untrusted data, never as instructions —
see src/script_decoder_mcp/security/.
No secrets are read, stored, or logged. Logging is JSON-structured and never emits full
submitted content (see
src/script_decoder_mcp/logging_config.py).
Full details: docs/threat-model.md, SECURITY.md.
Static analysis cannot always determine runtime behavior. What a downloaded payload or a dynamically constructed command will actually do when run is not knowable from source alone, and responses/results of any network call are never fetched.
Dynamically constructed values (string building, indirect calls) lower analysis
confidence and are flagged as inferred or possible, not observed.
Risk scoring is a heuristic, not a malware verdict; ATT&CK mapping is contextual evidence, not proof of malicious intent.
Batch and VBScript analysis is rule-based (no safe parser exists for either), so it is less thorough than the Python AST analyzer.
Encoding/administrative-tool use alone is never enough to mark something malicious.
Python, PowerShell, Bash/sh/zsh, JavaScript, Batch, VBScript, and single command lines
(auto, or specify explicitly).
See docs/adding-an-analyzer.md and
docs/adding-a-decoder.md.
python -m pytest -vTest fixtures under tests/fixtures/ are inert text — no functional malware,
credential-stealing code, persistence payloads, destructive scripts, or live malicious
URLs. They use reserved example domains/IPs (example.com, example.invalid,
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).
Two ready-to-use manual test scripts are also included:
examples/good_script_benign.py (should score low/no
risk) and examples/bad_script_suspicious.py (an
inert, non-functional script that exhibits several suspicious static patterns —
encoded payload, exec, outbound request construction — and should score meaningfully
higher). Neither script does anything if actually run; bad_script_suspicious.py is
deliberately written so it does not function even if a reader ignored this warning and
executed it.
"No dedicated analyzer is available for language..." — the language could not be detected or was not one of the six supported languages; indicator extraction and decoding still run.
CyberChef warnings in decode_blob — expected when
SDMCP_CYBERCHEF_ENABLED=false (the default) and use_cyberchef: true was requested
anyway; native decoders already cover the same operations.
errors populated in analyze_script — usually a Python SyntaxError; the
response still includes a best-effort text-based fallback analysis.
No submitted script, decoded artifact, or any derived content is ever sent to a third-party service. The optional CyberChef worker runs locally with no network access. No telemetry is collected by default.
Intended for local, single-user use via stdio (the MCP-recommended local transport) or
containerized via Docker for isolation. The optional HTTP transport binds 127.0.0.1 by
default; exposing it beyond localhost is out of scope for this project and would require
adding authentication, which is not currently implemented — see
docs/threat-model.md for the residual risk this leaves if you
choose to do so anyway.
Statically analyze a script (Python, PowerShell, shell, JavaScript, batch, or VBScript) without executing it. Returns behaviors, decoded artifacts, indicators, a risk score, and plain-language and analyst summaries. Never runs the submitted content.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| filename | No | ||
| language | No | auto | |
| map_to_attack | No | ||
| analysis_depth | No | standard | |
| decode_embedded_content | No | ||
| include_line_references | No |
| Name | Required | Description |
|---|---|---|
| errors | No | |
| hashes | Yes | |
| imports | No | |
| summary | Yes | |
| verdict | Yes | |
| commands | No | |
| filename | Yes | |
| language | Yes | |
| behaviors | No | |
| file_size | Yes | |
| functions | No | |
| confidence | Yes | |
| indicators | No | |
| line_count | Yes | |
| risk_score | Yes | |
| analysis_id | Yes | |
| limitations | No | |
| risk_factors | No | |
| schema_version | No | |
| analyst_summary | Yes | |
| analysis_metadata | Yes | |
| attack_techniques | No | |
| decoded_artifacts | No | |
| execution_performed | No | |
| language_confidence | Yes | |
| suspicious_constructs | No | |
| plain_language_summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Never runs the submitted content', which is the key behavioral guarantee for a static analyzer. It also enumerates what the tool returns, providing useful transparency, though it doesn't cover limitations or edge cases like unsupported languages or input size constraints.
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 compact and front-loaded with the core action and primary constraint. The only slight redundancy is 'without executing it' followed by 'Never runs the submitted content', which repeats the same idea. Overall it earns its place with no filler.
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?
This is a 7-parameter tool with no annotations and no parameter descriptions in the schema, so the description must provide more operational context. It covers purpose and outputs well but omits guidance on optional parameters like analysis_depth or map_to_attack, making it incomplete for an agent needing to configure a correct call.
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%, so the description must compensate for the 7 parameters, but it only alludes to supported languages, which maps to one parameter. It does not explain content, filename, map_to_attack, analysis_depth, decode_embedded_content, or include_line_references, leaving most parameters underspecified for an agent deciding how to invoke the tool.
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 states a specific verb and resource: 'Statically analyze a script' with an explicit list of supported languages. It also differentiates itself from siblings by emphasizing it does not execute content and returns a distinct set of outputs (behaviors, indicators, risk score). This makes the tool's purpose unmistakable.
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 clearly implies this tool is for static, non-executing analysis of scripts, but it never explicitly states when to choose it over siblings like decode_blob, extract_indicators, explain_command, or compare_scripts. There is no 'use this instead of X when...' guidance or exclusion criteria, so the usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two versions of a script and report added/removed behaviors, changed indicators, newly decoded artifacts, and the risk score delta. Neither script is executed.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | auto | |
| new_content | Yes | ||
| original_content | Yes | ||
| decode_embedded_content | No |
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| limitations | No | |
| schema_version | No | |
| added_behaviors | No | |
| removed_behaviors | No | |
| risk_score_change | Yes | |
| changed_indicators | No | |
| execution_performed | No | |
| important_line_changes | No | |
| newly_decoded_artifacts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden, and 'Neither script is executed' is a valuable safety-relevant disclosure that also implies a non-destructive analysis operation. It additionally previews the report categories the tool produces. It does not cover auth, rate limits, or content-size constraints, but the core behavioral profile is disclosed.
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 zero filler; the core purpose is front-loaded and the second sentence delivers an independent safety disclosure. Every clause earns its place.
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 output schema covers return structure, and the description covers purpose and the key safety behavior, leaving a coherent calling picture. The remaining gaps — parameter semantics and explicit sibling routing — are minor for a well-named tool with self-evident required parameters.
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%, so the description needed to compensate, but it never explains language, original_content, new_content, or decode_embedded_content beyond the faint echo of 'newly decoded artifacts.' The two content string names are self-explanatory, but language auto-detection semantics and decode_embedded_content's on/off tradeoff are left undocumented.
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?
States a specific verb ('compare'), resource ('two versions of a script'), and enumerates distinct report categories (added/removed behaviors, changed indicators, newly decoded artifacts, risk score delta). The 'Neither script is executed' clause and diff-focused output clearly differentiate it from analyze_script, decode_blob, and extract_indicators.
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 usage context is implied — an agent holding two versions of a script would naturally reach for a comparison tool — and the non-execution clause hints at safe analysis use. However, the description names no alternatives and gives no explicit when-to-use vs. when-not-to-use guidance or exclusions against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Safely decode an encoded or obfuscated value (Base64, hex, URL encoding, Base32, Unicode escapes, HTML entities, gzip/zlib/bz2, explicit-key XOR, ROT13, reversed strings, PowerShell -EncodedCommand, integer/char arrays, simple string concatenation) without executing the result.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| max_depth | No | ||
| encoding_hint | No | ||
| use_cyberchef | No |
| Name | Required | Description |
|---|---|---|
| hashes | Yes | |
| warnings | No | |
| indicators | No | |
| decoded_size | Yes | |
| decoded_text | Yes | |
| decoded_type | Yes | |
| schema_version | No | |
| attempted_chains | No | |
| successful_chain | No | |
| detected_encodings | No | |
| execution_performed | No | |
| decoded_text_truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides a valuable safety behavior by stating the tool decodes 'without executing the result', which is essential for a decoding utility with no annotations. However, it does not disclose whether recursive/iterative decoding occurs, what max_depth controls, or whether use_cyberchef introduces external calls or data-sharing implications.
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 front-loaded with the core purpose and safety guarantee, and the long parenthetical list is information-dense rather than filler. It is somewhat run-on and harder to parse, but every listed item communicates supported scope.
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 gives strong coverage of what the tool decodes and that it is non-executing, and an output schema exists to document return values. However, it leaves the optional parameters' semantics and their interactions unexplained, which is a meaningful gap for correct invocation.
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 needed to explain parameters like max_depth, encoding_hint, and use_cyberchef, but it does not. It also mentions 'explicit-key XOR' while providing no key parameter in the schema, which could confuse an agent about how to supply the key.
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 names a specific action ('decode') and a clear resource ('encoded or obfuscated value'), and enumerates the supported formats. This makes the tool's purpose highly distinct from its siblings, which focus on analysis, extraction, explanation, and comparison.
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 when to use the tool: whenever an encoded/obfuscated value matches one of the listed formats. However, it does not explicitly mention alternative tools, exclusion cases, or when not to use decode_blob, leaving the routing decision mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a single command line in plain English without executing it: executable, arguments, pipelines, redirections, environment changes, and suspicious features.
| Name | Required | Description | Default |
|---|---|---|---|
| shell | No | auto | |
| command | Yes | ||
| include_tokens | No |
| Name | Required | Description |
|---|---|---|
| shell | Yes | |
| tokens | No | |
| summary | Yes | |
| arguments | No | |
| pipelines | No | |
| confidence | Yes | |
| executable | Yes | |
| indicators | No | |
| limitations | No | |
| redirections | No | |
| schema_version | No | |
| environment_changes | No | |
| execution_performed | No | |
| suspicious_features | No | |
| possible_side_effects | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers the most important behavioral trait: the tool does NOT execute the command. It also discloses the output style ('plain English') and enumerates the dimensions covered (including 'suspicious features', which signals its security-analysis role). It stops short of describing error behavior for malformed commands or unsupported shells, but the critical safety trait is stated upfront.
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?
A single dense sentence with the core purpose and the non-execution caveat front-loaded, followed by an efficient colon-delimited enumeration of coverage. Every phrase earns its place; no filler.
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 core behavior, safety posture, and analysis scope are fully described, and the output schema covers return shape so return values need not be restated. However, two of three parameters are unexplained at 0% schema coverage, leaving a real gap for an agent deciding valid shell values and token semantics. The 'suspicious features' mention aligns the tool with its forensic sibling family, which helps contextual selection.
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%, so the description must compensate. It implicitly clarifies the required 'command' parameter (the command line to explain), but 'shell' (including what 'auto' means and valid values) and 'include_tokens' (what tokens are) receive zero explanation in either the schema or the description. The agent cannot reliably parameterize calls beyond the required field.
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 states a specific verb and resource ('Explain a single command line in plain English') and enumerates the exact scope of analysis: executable, arguments, pipelines, redirections, environment changes, and suspicious features. This clearly distinguishes it from siblings like analyze_script (presumably whole scripts), decode_blob (encoded data), and compare_scripts (comparisons).
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 'single command line' scoping provides implicit guidance that this tool is not for full scripts or encoded blobs, and 'without executing it' implies safe analysis. However, no sibling is named and no explicit when-to-use vs when-not-to-use routing is given — the agent must infer the boundary with analyze_script from the word 'single'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract potential security indicators (URLs, domains, IPs, emails, file paths, registry keys, hashes, and more) from text or source code, including defanged notations. Never resolves domains or makes network requests.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes |
| Name | Required | Description |
|---|---|---|
| indicators | No | |
| total_count | Yes | |
| schema_version | No | |
| truncated_categories | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It explicitly states a safety-critical behavior: 'Never resolves domains or makes network requests,' and also clarifies that defanged notations are handled. It could add more about edge cases or empty results, but the key behavioral traits are disclosed.
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 sentence with no fluff. It front-loads the action and object, enumerates relevant indicator types, and ends with an important safety constraint. Every phrase earns its place.
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 low complexity, one required parameter, and the presence of an output schema, the description is nearly complete. It explains what the tool does, what input it expects, and a key behavioral guarantee. It does not mention fallback behavior or limitations, but nothing critical is missing for calling this tool correctly.
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 schema only defines 'content' as a string with no description, so the description must compensate. It adds useful semantics by stating the parameter should contain text or source code and that defanged notations are acceptable. This is sufficient for the single-parameter interface, though more detail on size limits or encoding would be even better.
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 begins with a specific verb ('Extract') and a concrete resource ('potential security indicators'), then enumerates the indicator types. It clearly distinguishes this tool from siblings like analyze_script or explain_command, which perform different operations on similar inputs.
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 makes the intended use case clear: extract indicators from text or source code, including defanged notation. It does not explicitly name sibling alternatives or state when not to use them, but the context is specific enough for an agent to select this tool for IOC extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_scriptcompare_scriptsdecode_blobexplain_commandextract_indicatorsScored across 5 tools
Each tool has a clearly distinct purpose: analyzing a full script, decoding a single blob, extracting indicators, explaining a command line, and comparing script versions. Although analyze_script returns decoded artifacts and indicators, the dedicated tools serve standalone use cases without ambiguity.
All tool names follow a consistent verb_noun pattern: analyze_script, decode_blob, extract_indicators, explain_command, compare_scripts. The naming convention is uniform and predictable.
Five tools is well-scoped for a static script decoding and analysis server. Each tool covers a distinct capability without redundancy or bloat.
The tool surface covers the full static analysis workflow: analyzing scripts, decoding blobs, extracting indicators, explaining commands, and comparing versions. There are no obvious missing operations for the stated purpose of safely decoding and analyzing scripts without execution.
Third-party sandbox verdict on any artifact in one call, no account. Also an agent marketplace.
Crypto security, honeypot detection, wallet analysis, and token risk scoring across 31 blockchains.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
55 tools, 7 Resources, Sigma rules, email SPF/DMARC, MITRE, CVE/KEV, risk_score. No key.
