pyobfus-mcp
This MCP server exposes pyobfus (a Python obfuscator) capabilities to AI coding agents (Claude, Cursor, Windsurf, Zed, etc.), enabling obfuscation workflow management directly from agent conversations.
check_obfuscation_risks: Scan a Python project for patterns that could break obfuscation (e.g.,eval/exec, dynamic attribute access, framework reflection). Returns severity counts, detected frameworks (FastAPI, Django, Flask, Pydantic, Click, SQLAlchemy), and a suggested preset.generate_pyobfus_config: Auto-detect frameworks in a project and generate a ready-to-usepyobfus.yamlconfiguration file with the appropriate preset applied. Can return the YAML as text or write it directly to disk.unmap_stack_trace: Translate obfuscated identifiers in a production stack trace back to their original names using amapping.jsonfile produced during obfuscation, enabling debugging of obfuscated code.list_presets: Enumerate all available pyobfus presets grouped by tier — community, framework-aware, and Pro.explain_preset: Get a detailed description of a named preset, including excluded names/patterns, parameter name preservation settings, and docstring handling behavior.
Provides a preset for Django projects, automatically detecting Django and generating configuration to obfuscate Django code while properly handling dispatch methods, decorators, ORM fields, and migrations.
Provides a preset for FastAPI projects, automatically detecting FastAPI and generating configuration to obfuscate FastAPI code while preserving endpoint handlers, dependency injection, and Pydantic models.
Provides a preset for Flask projects, automatically detecting Flask and generating configuration to obfuscate Flask code while preserving route decorators, blueprints, and other framework-specific patterns.
Provides a preset for Pydantic projects, automatically detecting Pydantic and generating configuration to obfuscate Pydantic models while preserving field validators and serialization methods.
Provides a preset for SQLAlchemy projects, automatically detecting SQLAlchemy and generating configuration to obfuscate ORM models while preserving column definitions, relationships, and query methods.
pyobfus — the Python obfuscator
pyobfus (pronounced as "Python obfuscator") is a modern, AST-based python-obfuscator / code-obfuscator for developers who need to obfuscate before shipping while keeping failures diagnosable. Framework-aware presets, reverse stack-trace mapping, and a machine-readable JSON CLI let Claude Code, Cursor, GitHub Copilot, Codex, CodeBuddy, and any MCP-compatible AI agent help debug obfuscated stack traces. A transparent, open-source alternative to PyArmor.
A Python code obfuscator built with AST-based transformations. Supports Python 3.9 through 3.14. Provides reliable name mangling, string encoding, control-flow flattening, AES-256 string encryption, and — unique to pyobfus — a reverse-mapping workflow that lets you (or your AI coding assistant) debug obfuscated stack traces without giving up the protection.
🔒 Pro Edition available — 6 patent-targeted protection mechanisms (Selective Opacity, forensic watermarking, Runtime String Vault, and more) layered on top of the free AST obfuscator, $45 one-time, no subscription. See Pro Edition below.
🔎 What's new in v0.5.21 —
pyobfus --check --sarif PATHexports the pre-flight risk scan as a SARIF 2.1.0 report for GitHub Code Scanning (a pure projection — detection, severity and exit codes are unchanged). Plus two bug fixes: cross-file directory mode no longer silently drops content-level transforms and Pro presets, and--levelno longer downgrades a preset'sprolevel to community output.
🔔 Starring this repo doesn't notify you about new releases — GitHub only sends release notifications to people who explicitly Watch it. Click Watch → Custom → Releases (top of this page) to get a heads-up the moment a new version ships, without the noise of every commit/issue.
🔌 Companion MCP server: pyobfus-mcp
This repository ships two installable packages:
Package | What it is | Install |
The Python obfuscator (CLI + library). |
| |
A Model Context Protocol (MCP) server that exposes pyobfus's tools to AI coding agents. |
|
The MCP server lives in pyobfus_mcp/ and is built on the official Model Context Protocol Python SDK (FastMCP). It registers eight MCP tools so Claude Desktop, Claude Code, Cursor, Windsurf, Zed, and Codex can call pyobfus directly from agent conversations — no shelling out:
MCP tool | Implementation | Purpose |
| One-call, self-verifying pipeline: scan → preset → obfuscate → byte-compile + import-smoke-test the output → return | |
| Pre-flight risk scan; pass | |
| Auto-detect framework → write a working | |
| Reverse obfuscated identifiers in a production stack trace | |
| Enumerate community / framework / Pro presets | |
| Describe what a named preset changes | |
| Analyze a project and recommend community vs Pro tier, with reasoning | |
| Return structured guidance for starting the 5-day Pro trial |
The server is registered in the official MCP Registry under io.github.zhurong2020/pyobfus-mcp. The transport is stdio. See pyobfus_mcp/README.md for per-client configuration snippets.
🧩 Claude Code skill / plugin
This repo is also a Claude Code plugin marketplace. The pyobfus-protect skill teaches an agent the full "protect Python before shipping — obfuscate and verify it still runs" workflow (MCP-first, CLI fallback):
/plugin marketplace add zhurong2020/pyobfus
/plugin install pyobfus@pyobfusSee skills/ for the skill and install details. (This is distinct from templates/ai-integration/, which are copy-in rule files for your project.)
🧑💻 VS Code extension
pyobfus is also on the VS Code Marketplace (publisher zhurong2020) — the first obfuscation-focused extension in this category, since no competitor (PyArmor, Nuitka, Sourcedefender) has one. Inline obfuscation-risk diagnostics (pyobfus --check findings rendered via VS Code's native DiagnosticCollection API — squiggles + Problems panel, no separate linter to configure), a "Reverse Stack Trace" command, a status bar item showing your current tier with a one-click menu (Check Workspace / Generate Config / Start Trial / Unlock Pro), a "Generate pyobfus.yaml" command, and right-click "Obfuscate with pyobfus" from the Explorer or editor. Source and design rationale in vscode-extension/ and docs/VSCODE_EXTENSION_PLAN.md.
🤖 AI-native features
pyobfus --check src/— config-aware pre-flight risk scan: detectseval/exec, dynamic attribute access, framework reflection points, and declared dependencies that do not exist on public PyPI before you obfuscate. It honors the same explicit/discovered config and presets as a build; findings from excluded files are reported separately without affecting the primary result. Use--no-configfor the legacy unfiltered scan and--offlineto skip PyPI lookups. JSON includeseffective_config,excluded_findings, and anai_hinttelling your AI assistant what to run next. Add--sarif pyobfus.sarifto also emit a SARIF 2.1.0 report for GitHub Code Scanning (seedocs/SARIF_CODE_SCANNING.md).pyobfus --init src/— zero-config onboarding: scans the project, detects FastAPI/Django/Pydantic/Click/SQLAlchemy, and writes a ready-to-usepyobfus.yaml.pyobfus --unmap --trace error.log --mapping mapping.json— reverse obfuscated identifiers in a production stack trace so you can debug (or hand the trace to an AI assistant) without reversing the obfuscation itself.pyobfus … --save-mapping mapping.json --trace-marker— stamp each obfuscated file with a# pyobfus:obfuscatedheader (id + mapping filename + the exact--unmapcommand) so an AI agent that lands in an obfuscated file from a traceback immediately knows it's pyobfus output and how to reverse the names.pyobfus … --provenance-manifest provenance.json— write a local JSON manifest (input/output hashes, config hash, pyobfus version, git commit when available, mapping digest, CycloneDX-compatible component relationships, and a self-consistency integrity digest — not a cryptographic signature) for offline build provenance. Seedocs/PROVENANCE_MANIFEST.md.pyobfus --verify-provenance-manifest provenance.json --json— validate the manifest structure, CycloneDX-compatible relationships, and local integrity digest before archiving or shipping it.pyobfus … --dry-run --json— preview a versionedplanobject before anything is written: the effective configuration, which files are selected or excluded (and why), and the artifacts a build would produce, each taggedship/retain-internal/optional. Relative labels only (no source, secrets, or absolute paths); it is a preview, not a saved apply file.pyobfus … --verify-syntax— opt-in post-build check: compiles every generated.pyin memory (no import, no execution, no__pycache__) and reportssyntax_validin JSON. A failure blocks delivery; it makes no runtime-correctness claim.Release provenance — pyobfus and pyobfus-mcp are published through PyPI Trusted Publishing with PEP 740 attestations; see
docs/RELEASE_PROVENANCE_VERIFICATION.mdfor verification commands and the current snapshot.Framework-aware presets —
--preset fastapi | django | flask | pydantic | click | sqlalchemy | mlwith built-in exclusions for dispatch methods, decorators, ORM fields, migrations, model-serving wrappers, and dependency-injection parameters.Compatibility cookbooks — pair pyobfus with real delivery pipelines: import-hook / encrypted-file (SOURCEdefender
.pye), compiled packaging (Nuitka / Cython), and ML model-serving.pyobfus --checkalso emitscompatibility_advisoryfindings for these. Seedocs/IMPORT_HOOK_COOKBOOK.md,docs/COMPILED_PACKAGING_COOKBOOK.md, anddocs/MODEL_SERVING_COOKBOOK.md. For a hardened Python 3.14+ deployment that uses anti-debug protection,--checkalso flags PEP 768 remote-debug exposure (which must be disabled at interpreter startup, not by the obfuscator) — seedocs/REMOTE_DEBUG_HARDENING.md.Global
--json— every CLI mode (obfuscate,--check,--unmap,--init) emits the same structured schema with anai_hintfield, ready for Claude Code, Cursor, Windsurf, and MCP servers to consume.
Related MCP server: MCP Python Toolbox
Features
✅ Free Edition
The following features are fully implemented and available in the current version:
Cross-File Obfuscation: Consistent name obfuscation across multiple files
Automatic import statement rewriting
__all__list updates with obfuscated namesGlobal symbol table with collision detection
Two-phase obfuscation pipeline (Scan → Transform)
Preview mode with
--dry-runflag
Name Mangling: Rename variables, functions, classes, and class attributes to obfuscated names (I0, I1, I2...)
Comment Removal: Strip comments and docstrings
String Encoding: Base64 encoding for string literals with automatic decoder injection
Numeric / Constant Obfuscation (
--numeric-obfuscation): replace integer and float literals with value-preserving opaque expressions (int → XOR/add/sub identities, float →float.fromhex) so the original constants no longer appear in the shipped sourceAI Provenance Stripping (
--strip-ai-artifacts): remove AI-generation markers (e.g.Generated by Claude,Co-Authored-By: Claude) from docstrings and attribution dunders, so AI-assisted code doesn't ship with "this was AI-generated" fingerprintsIncremental Builds (
--incremental): skip a directory rebuild when every input file and the config are unchanged since the last successful build (cache at<output>/.pyobfus-cache/), useful in CI pipelines that cache artifactsParameter Preservation: Preserve function parameter names for keyword argument compatibility (
--preserve-param-names)Multi-file Support: Obfuscate entire projects with preserved import relationships
File Filtering: Exclude files using glob patterns (test files, config files, etc.)
Configuration Files: YAML-based configuration for repeatable builds
Selective Obfuscation: Preserve specific names (builtins, magic methods, custom exclusions)
Configuration Presets:
--preset safe | balanced | aggressivefor quick obfuscation-strength tradeoffs, plus framework-aware presets —--preset fastapi | django | flask | pydantic | click | sqlalchemy | ml— with built-in exclusions for dispatch methods, decorators, ORM fields, migrations, and dependency-injection parameters.--list-presetsshows them allPre-flight Risk Scanning (
--check): detectseval/exec, dynamic attribute access, and framework reflection points before you obfuscate; add--sarif PATHto export findings as SARIF 2.1.0 for GitHub Code ScanningReverse Stack-Trace Mapping (
--unmap): reverse obfuscated identifiers in a production stack trace, so you (or an AI coding assistant) can debug without un-obfuscating the shipped codeBuild Provenance (
--provenance-manifest, v0.5.5+): local JSON manifest of an obfuscation run — input/output file hashes, config hash, pyobfus version, git commit when available, mapping digest, and CycloneDX-compatible component relationships — for offline build provenance, no network callsProvenance Validation (
--verify-provenance-manifest): validates manifest shape, CycloneDX-compatible relationships, and the local integrity digest; JSON output is available for CI/agent useStructured Dry-Run Plan (
--dry-run --json, v0.5.19+): versionedplanobject — effective config, selected/excluded files with reasons, and artifacts taggedship/retain-internal/optional; relative labels only, preview-only (not applyable)Syntax-Only Output Verification (
--verify-syntax, v0.5.19+): after a build, compiles generated Python in memory — no import, no execution, no__pycache__— and reportssyntax_validin JSON; a failure blocks delivery and it makes no runtime-correctness claimRelease Attestations: PyPI Integrity API / PEP 740 runbook for verifying pyobfus and pyobfus-mcp release artifacts
🔒 Pro Edition
The following advanced features are available with a Pro license:
String Encryption
AES-256 encryption for strings
Runtime decryption with injected decoder
Automatic key generation
Anti-Debugging
Debugger detection checks injected into functions
Four detection methods (v0.5.11):
sys.gettrace()(Python-level tracers/debuggers), TracerPid via/proc/self/status(native debuggers on Linux — gdb, strace), WinAPIIsDebuggerPresent()(native debuggers on Windows), and a timing-skew check (catches single-stepping regardless of platform)Default OFF to protect AI-debuggability; opt-in via
--anti-debugHeuristic, not a security boundary — documented in the CHANGELOG
Control Flow Flattening
State machine transformation for if/else/elif
For/while loop flattening
Nested structure support
CLI:
--control-flow
Dead Code Injection
Insertion of unreachable code paths
Four strategies: after-return, false branches, opaque predicates, decoy functions
CLI:
--dead-code
License Embedding
Embed expiration dates:
--expire 2025-12-31Machine binding:
--bind-machineRun count limits:
--max-runs 100Offline verification - no external dependencies
Runtime Policy (v0.5.9)
Refuse to import outside a build-time platform allowlist — a pure-Python generalization of PyArmor BCC's platform restrictions
OS allowlist:
--requires-os Linux,DarwinMinimum Python version:
--requires-python-min 3.10CPU architecture allowlist:
--requires-arch x86_64,arm64Any combination composes; each check is independent
Embedded Encrypted Data (v0.5.10)
AES-256-GCM encrypt a resource file at build time and embed it base85-encoded in the output — closes the Nuitka Commercial "Protect Data Files" / PyArmor
--bind-datagapCLI:
--embed-data path/to/resource.binGenerates a
get_embedded_data()accessor that decrypts on call, not at import
Configuration Presets
--preset trial- 30-day time-limited version--preset commercial- Maximum protection with machine binding--preset library- For pip-distributable libraries--preset maximum- Highest security with all protections--list-presets- View all presets
Patent-targeted mechanisms (CN 202610712171X, introduced v0.5.0)
Six mechanisms, available both as the pyobfus_pro API and — as of v0.5.1 —
as opt-in pyobfus build flags (single-file / --no-cross-file mode):
--selective-opacity, --seal-code, --vault, --scrub-traceback,
--fingerprint <buyer-id>, --expire-hard <date>. v0.5.3 adds
--period <N> (run-counter limit), --opacity-config <opacity.toml>
(pattern-driven L3 encryption by original qualname), and --bind-device /
--bind-device-id <id> (device-locked L3 encryption). v0.5.4 extends
--bind-device to Runtime String Vault keys too — previously only the
Selective Opacity L3 layer was device-locked, so vault secrets decrypted on
any machine; now each vault key is independently re-derived at runtime from
the bound device.
Selective Opacity — per-symbol protection layers (transparent / ai-readable / obfuscated / AES-256-GCM encrypted with lazy
__code__materialization).Forensic watermarking — per-buyer deterministic key derivation for piracy traceback.
License binding combo — device / expiry / run-count binding woven into the AES-GCM decryption path (no separate patchable license check).
@seal_code— build-time bytecode integrity hash; runtime in-memory-patch detection.--scrub-traceback— production traceback encryption (RSA-2048 + AES-256-GCM); reverse error IDs with the newpyobfus-unscrubCLI.Runtime String Vault — encrypted KV namespace for runtime secrets with lazy per-entry decryption.
Requires Python ≥ 3.9 as of v0.5.0 (3.8 dropped, EOL 2024-10).
See CURRENT_PLAN_ZH.md for the current project plan and priorities.
Try Pro Features FREE
Try all Pro features for 5 days - no registration or credit card required!
# Start your free trial
pyobfus-trial start
# Check trial status
pyobfus-trial status
# Use Pro features during trial
pyobfus input.py -o output.py --level proWhat's included in the trial:
Control flow flattening (
--control-flow)AES-256 string encryption (
--string-encryption)Anti-debugging protection (
--anti-debug)Dead code injection (
--dead-code)License embedding (
--expire,--bind-machine,--max-runs)Configuration presets (
--preset trial/commercial/library/maximum)
After your trial, purchase a license to continue using Pro features.
The trial runs on the honor system. It stores its state in an unsigned file in your home directory, and
pyobfus/trial.pyis readable Apache-2.0 source — so it is a convenience control, not a security boundary, and we document it as such rather than claiming protection it cannot deliver. See SECURITY.md. Note that the Community Edition has no file or line limits and needs no trial at all — the trial gates only the Pro mechanisms.
Purchase Professional Edition
Pro Edition Features:
🔀 Control Flow Flattening
🧩 Dead Code Injection
🔐 AES-256 String Encryption
📦 Import Obfuscation - runtime
importlibimports with encrypted import strings🛡️ Anti-Debugging Checks
📅 License Embedding - Expiration, machine binding, run limits
⚡ Configuration Presets - One-command setup
🔄 Lifetime Updates
💻 Up to 3 devices per license
📧 Priority Email Support
Price: $45.00 USD (one-time payment)
Payment methods: credit/debit card, Apple Pay, and WeChat Pay (微信支付) for buyers in China, plus the other options Stripe shows for your region at checkout. Alipay (支付宝) is being enabled.
How to Purchase
Visit our purchase page: pyobfus.github.io/purchase for detailed information and secure checkout.
Quick purchase: 🚀 Buy Now - Direct checkout link (Instant delivery • 30-day money-back guarantee)
3-Step Purchase Process:
Complete Secure Checkout (Stripe)
Click the buy link above or visit the purchase page
Enter your email (for license delivery)
Complete payment securely via Stripe
Receive License Key
License key delivered to your email within minutes
Format:
PYOB-XXXX-XXXX-XXXX-XXXXCheck Spam/Junk folder if not in inbox
Activate License
pip install --upgrade pyobfus pyobfus-license register PYOB-XXXX-XXXX-XXXX-XXXX pyobfus-license statusStart Using Pro Features
# Quick start with presets pyobfus src/ -o dist/ --preset commercial # Maximum protection pyobfus src/ -o dist/ --preset trial # 30-day trial version pyobfus src/ -o dist/ --preset library # For pip distribution # Individual features pyobfus input.py -o output.py --string-encryption pyobfus input.py -o output.py --import-obfuscation pyobfus input.py -o output.py --anti-debug pyobfus input.py -o output.py --control-flow pyobfus input.py -o output.py --dead-code # License restrictions pyobfus src/ -o dist/ --expire 2025-12-31 --bind-machine --max-runs 100 # All Pro features pyobfus input.py -o output.py --string-encryption --import-obfuscation --anti-debug --control-flow --dead-code
Support: For license activation, billing, or account questions, email zhurong0525@gmail.com with your license key. For bug reports or usage questions, please open a GitHub issue or start a discussion — that way the answer is there for the next person who hits the same thing.
Legal & Policies
By purchasing pyobfus Professional Edition, you agree to our:
Terms of Service & EULA - License agreement and usage terms
Refund Policy - 30-day money-back guarantee, no questions asked
Privacy Policy - GDPR compliant, we protect your data
Quick Start
Installation
From PyPI (recommended):
pip install pyobfusFrom source (for development):
git clone https://github.com/zhurong2020/pyobfus.git
cd pyobfus
pip install -e .Basic Usage
# Obfuscate a single file
pyobfus input.py -o output.py
# Obfuscate a directory (cross-file mode - default in v0.2.0+)
pyobfus src/ -o dist/
# Preview obfuscation without writing files (v0.2.0+)
pyobfus src/ -o dist/ --dry-run
# Machine-readable plan: effective config, included/excluded files, artifacts
pyobfus src/ -o dist/ --dry-run --json
# Write output, then compile every generated .py in memory (no import/execution)
pyobfus src/ -o dist/ --verify-syntax --json
# Legacy single-file mode (v0.2.0+)
pyobfus src/ -o dist/ --no-cross-file
# With configuration file
pyobfus src/ -o dist/ --config pyobfus.yaml
# Preserve parameter names for keyword arguments (v0.1.6+)
pyobfus src/ -o dist/ --preserve-param-names
# Verbose output with progress indicators (v0.2.0+)
pyobfus src/ -o dist/ --verboseExample
Before obfuscation:
def calculate_risk(age, score):
"""Calculate risk factor."""
risk_factor = 0.1
if score > 100:
risk_factor = 0.5
return age * risk_factor
patient_age = 55
patient_score = 150
risk = calculate_risk(patient_age, patient_score)
print(f"Risk score: {risk}")After obfuscation:
def I0(I1, I2):
I3 = 0.1
if I2 > 100:
I3 = 0.5
return I1 * I3
I4 = 55
I5 = 150
I6 = I0(I4, I5)
print(f'Risk score: {I6}')Note: Variable names (I0, I1, etc.) may vary slightly depending on code structure, but functionality is preserved.
Configuration
Quick Start with Templates
Generate a configuration template for your project type:
# For Django projects
pyobfus --init-config django
# For Flask projects
pyobfus --init-config flask
# For Python libraries
pyobfus --init-config library
# For general projects
pyobfus --init-config generalThis creates a pyobfus.yaml file with sensible defaults for your project type.
Validate Configuration
Check your configuration file for errors before use:
pyobfus --validate-config pyobfus.yamlThe validator checks for:
YAML syntax errors
Invalid configuration options
Common typos (e.g.,
exclude_pattern->exclude_patterns)Pro features used with community level
Auto-Discovery
When you run pyobfus without -c, it automatically searches for:
pyobfus.yamlpyobfus.yml.pyobfus.yaml.pyobfus.yml
Manual Configuration
Create pyobfus.yaml:
obfuscation:
level: community
exclude_patterns:
- "test_*.py"
- "**/tests/**"
- "__init__.py"
exclude_names:
- "logger"
- "config"
- "main"
remove_docstrings: true
remove_comments: trueexclude_names Behavior
The exclude_names option preserves specified names from being renamed during obfuscation:
obfuscation:
exclude_names:
- MyPublicClass # Name preserved, but strings inside are still encoded
- exported_function # Name preserved for external callersImportant: exclude_names only affects name obfuscation, not string encoding:
# Original
SECRET_KEY = "admin-password-123"
# With exclude_names: [SECRET_KEY] and string_encoding: true
SECRET_KEY = _decode_str('YWRtaW4tcGFzc3dvcmQtMTIz')
# ✅ Name 'SECRET_KEY' is preserved
# ✅ String content is still encoded (Base64)Use cases:
Preserve names for public APIs that external code imports
Keep class/function names for debugging while still protecting string content
Maintain compatibility with external frameworks expecting specific names
File Filtering
Exclude patterns support glob syntax:
test_*.py- Exclude files starting with "test_"**/tests/**- Exclude all files in "tests" directories**/__init__.py- Exclude all__init__.pyfilessetup.py- Exclude specific files
See pyobfus.yaml.example for more configuration examples.
Architecture
pyobfus uses Python's ast module for syntax-aware transformations:
Parser: Parse Python source to AST
Analyzer: Build symbol table with scope analysis
Transformers: Apply obfuscation techniques (name mangling, string encoding, etc.)
Generator: Generate obfuscated Python code
This approach ensures:
Syntactically correct output
Proper handling of Python scoping rules
Support for modern Python features (f-strings, walrus operator, etc.)
Development
Setup
git clone https://github.com/zhurong2020/pyobfus.git
cd pyobfus
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install -e ".[dev]"Testing
# Run unit tests
pytest tests/ -v
# With coverage
pytest tests/ -v --cov=pyobfus --cov-report=html
# Run integration tests
pytest integration_tests/ -vIntegration Testing Framework (v0.1.6+): Test pyobfus on real-world code without uploading to PyPI. See INTEGRATION_TESTING.md for details.
Code Quality
# Format code
black pyobfus/
# Type checking
mypy pyobfus/
# Linting
ruff check pyobfus/Use Cases
Protecting Proprietary Algorithms
Obfuscate sensitive business logic before distributing Python applications.
Educational Purposes
Demonstrate code protection concepts and obfuscation techniques.
Intellectual Property Protection
Add an additional layer of protection for commercial Python software.
Limitations
Current Limitations
Keyword Arguments (✅ Resolved in v0.1.6): By default, parameter names are obfuscated, which breaks keyword arguments. Solution: Use the
--preserve-param-namesflag to preserve parameter names while still obfuscating function bodies.Example:
# Before obfuscation def process(data_path, output_dir): temp_file = data_path + ".tmp" return temp_file result = process(data_path='./data', output_dir='./output') # ✅ Works # After obfuscation (default behavior) def I0(I1, I2): I3 = I1 + ".tmp" return I3 result = process(data_path='./data', output_dir='./output') # ❌ TypeError! # After obfuscation (with --preserve-param-names) def I0(data_path, output_dir): I3 = data_path + ".tmp" return I3 result = I0(data_path='./data', output_dir='./output') # ✅ Works!When to use
--preserve-param-names:Public API functions/libraries where keyword arguments are used by clients
Functions with many parameters where keyword arguments improve readability
Code that relies heavily on keyword-only arguments (
def func(*, kwonly))
Trade-off: Parameter names reveal some information about the function's interface, but function bodies and local variables are still fully obfuscated.
Cross-file imports: ✅ Resolved in v0.2.0 with full cross-file obfuscation support
Dynamic code:
eval(),exec()with obfuscated code may require adjustmentsDebugging: Obfuscated code is harder to debug (by design)
Performance: Some obfuscation techniques may impact runtime performance
Recommendations
Test obfuscated code thoroughly before deployment
Keep original source in version control
Use configuration files for reproducible builds
For public APIs, use
--preserve-param-namesto maintain keyword argument compatibilityConsider combining with other protection methods (compilation, etc.)
Technical Details
Python Support: 3.9, 3.10, 3.11, 3.12, 3.13, 3.14 — including free-threaded 3.14 builds (
python3.14t, verified: full test suite + a real seal/scrub-traceback obfuscate→execute→decrypt round trip)Naming Scheme: Index-based (I0, I1, I2...) - simple and effective
Architecture: Modular transformer pipeline with two-phase cross-file obfuscation
Testing: 1,000+ tests, 90% coverage, multi-OS CI/CD (Python 3.9-3.14 × Ubuntu / macOS / Windows)
Frequently Asked Questions
Is pyobfus Right for Me?
Use pyobfus if you:
Need to protect proprietary algorithms before distributing Python applications
Want a tool that "just works" without DLL conflicts or native dependencies
Prefer transparent pricing without hidden trial limitations
Support open-source software with optional paid features
How do I obfuscate Python code?
# Install
pip install pyobfus
# Obfuscate a single file
pyobfus script.py -o script_obf.py
# Obfuscate an entire project
pyobfus src/ -o dist/
# Preview without writing files
pyobfus src/ -o dist/ --dry-run
# Preview a structured, non-applicable protection plan for an AI/CI consumer
pyobfus src/ -o dist/ --dry-run --json--verify-syntax is an opt-in post-build check: it compiles generated Python
source in memory, creates no __pycache__, and reports syntax_valid in JSON.
It does not import or execute the project and is not a runtime compatibility
guarantee.
How do I obfuscate Python before selling or delivering it?
Run pyobfus --check first, build into a separate output directory, and keep
the optional mapping.json outside the customer artifact. Ship the transformed
tree, then run your normal tests or packaging step against that exact output.
The PyInstaller,
compiled-packaging, and
import-hook cookbooks cover common delivery
formats.
How do I debug an obfuscated crash with an AI assistant?
Build with --save-mapping mapping.json. When a production traceback arrives,
run pyobfus --unmap --trace error.log --mapping mapping.json; the restored
identifiers can then be read by you, Claude Code, Cursor, Copilot, or another AI
assistant without giving the customer your private mapping file.
Is there an MCP server for Python obfuscation?
Yes. uvx pyobfus-mcp exposes eight local tools for risk scanning, config
generation, project protection, verification, preset guidance, and traceback
mapping. Source paths are validated locally and pyobfus does not upload project
code or require an API key.
Will my code still work after obfuscation?
pyobfus is designed to preserve program behavior for supported Python syntax and framework patterns, and its compatibility matrix is covered by automated tests. Obfuscation is still a source transformation: run your own test suite and verify the built artifact, especially when the project relies on dynamic imports, reflection, or generated code.
Does obfuscated code run slower?
Minimal impact:
Name mangling: Zero runtime cost (just renamed identifiers)
String encoding (Base64): ~0.1ms per string at startup
String encryption (AES-256, Pro): ~0.5ms per string at startup
Can I obfuscate Django/Flask projects?
Yes! Use our built-in templates:
# Django
pyobfus --init-config django
# Flask
pyobfus --init-config flask
# Then run obfuscation
pyobfus src/ -o dist/ -c pyobfus.yamlWhat Python versions are supported?
pyobfus supports Python 3.9 through 3.14. Build and test the obfuscated artifact with the Python version used in production; cross-interpreter portability can depend on syntax, dependencies, and enabled transformations.
PyArmor vs pyobfus: Which should I choose?
Feature | pyobfus | PyArmor |
Price | $45 (Pro, one-time) | $89 (Pro, one-time) |
Free tier project size | No file or line limits | Trial caps out around 935-940 lines/file (measured 2026-05-09) |
Open source | Yes (Core: Apache 2.0, Pro: Proprietary) | No |
Native dependencies | None (pure Python output) | Requires runtime library |
Python 3.9-3.14 support | Yes | Yes |
Choose pyobfus if: You want transparent pricing, open-source trust, and simpler deployment without native dependencies.
See our detailed comparison for more information.
Can I use pyobfus alongside PyArmor or Nuitka?
Yes — and for many projects this is the most cost-effective approach. Use pyobfus as your always-on default layer (every module gets AST mangling + mapping for AI-debug compatibility), then stack PyArmor Pro's bytecode encryption or Nuitka's native compilation on the small set of modules that genuinely need stronger protection. The comparison now also covers why bytecode encryption should be treated as a stronger speed bump, not as irreversible cryptographic protection for client-side Python. See Layered Deployment Strategy in COMPARISON.md for the full reasoning.
Can I ship a single-file executable, like with Nuitka?
Yes, at a fraction of Nuitka Commercial's cost: obfuscate first, then bundle the obfuscated output with the free PyInstaller. The two tools solve different problems (name mangling vs. bundling a Python interpreter into one file) and compose cleanly — see the PyInstaller Cookbook for a full worked example, including verification that the original identifier names never reach the compiled binary and that pyobfus --unmap still reverses a traceback captured from the bundled exe.
What if obfuscation breaks my code?
Use
--dry-runto preview changes before writing filesUse
--preserve-param-namesif you rely on keyword argumentsAdd exclusions in
pyobfus.yamlfor names that must stay unchangedReport issues on GitHub - we fix bugs quickly!
Can obfuscated code be reversed?
Name mangling removes the original identifiers from the emitted source and raises the cost of analysis, but it is not cryptographically irreversible: a determined analyst may infer names and behavior from context. Keep the optional mapping file private when you need reliable reverse mapping. For stronger protection, use Pro features:
AES-256 encryption for strings
Anti-debugging checks to prevent analysis
Security Note: String Encryption Limitations
Important: String encryption (AES-256) is designed as a deterrent against casual reverse engineering, not as cryptographic security.
Because obfuscated code must decrypt strings at runtime, the encryption key is necessarily embedded in the output. A determined attacker with access to the obfuscated code can:
Locate the embedded key
Extract and decrypt all strings
This is a fundamental limitation of ALL client-side obfuscators (including PyArmor, Nuitka, etc.) - true cryptographic security would require server-side decryption, which is impractical for most use cases.
What string encryption DOES provide:
✅ Prevents casual
stringsorgrepsearches from revealing sensitive text✅ Increases effort required for reverse engineering
✅ Deters non-technical users from extracting information
✅ Adds a layer of protection combined with other techniques
What string encryption does NOT provide:
❌ Protection against determined reverse engineers
❌ Cryptographic security for secrets (use environment variables or secret management instead)
❌ DRM-level protection
Recommendation: For sensitive credentials (API keys, passwords), use environment variables or external secret management systems rather than embedding them in code.
How is pyobfus different from Cython/Nuitka?
Tool | Approach | Output |
pyobfus | AST transformation |
|
Cython | Compile to C |
|
Nuitka | Compile to executable | Binary (platform-specific) |
Choose pyobfus if: You need cross-platform .py files without compilation overhead.
Documentation
For Users
Installation & Quick Start - Get started in minutes
Configuration Guide - YAML configuration and file filtering
Examples - Working code examples demonstrating features
Use Cases - Real-world application scenarios
For Developers
Project Structure - Codebase architecture and development workflow
Contributing Guide - How to contribute code and documentation
Current Plan - Current project status and priorities
Changelog - Version history and release notes
Community & Support
GitHub Issues - Bug reports and feature requests
GitHub Discussions - Questions, ideas, and community help
Security Policy - How to report security vulnerabilities
Legal & License
Dual License Model (see
LICENSE-NOTICE.md):pyobfus (Core): Apache 2.0 - Free and open source
pyobfus_pro (Pro): Proprietary - Requires paid license
Support the Project
If you find pyobfus helpful, consider supporting its development:
Your support helps maintain and improve pyobfus. Thank you!
Citation
If you use pyobfus in academic work or want to reference it, please cite the archived release. The concept DOI below always resolves to the latest version:
APA
Zhu, R. (2026). pyobfus: An AST-based Python obfuscator with reverse stack-trace mapping for AI-assisted development. Zenodo. https://doi.org/10.5281/zenodo.20846053
BibTeX
@software{zhu_pyobfus,
author = {Zhu, Rong},
title = {pyobfus: An AST-based Python obfuscator with reverse stack-trace mapping for AI-assisted development},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.20846053},
url = {https://doi.org/10.5281/zenodo.20846053}
}Machine-readable metadata is in CITATION.cff (GitHub's "Cite this repository" widget reads it).
Acknowledgments
Inspired by Opy's AST-based approach
Clean room implementation - no code copying
Available Tools
8 toolscheck_obfuscation_risksA
Scan a Python project for patterns that may break obfuscation (eval/exec, dynamic attribute access, framework reflection, unsafe model loading). Returns severity counts, detected frameworks (FastAPI/Django/Flask/Pydantic/Click/SQLAlchemy/ML), and a suggested preset. Also locates requirements*.txt / pyproject.toml and, only if verify_dependencies_online=true, checks each declared dependency against public PyPI to flag AI-hallucinated ('slopsquatting') package names -- off by default, this tool makes no outbound network calls unless you opt in.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| verify_dependencies_online | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by explicitly warning that the tool makes no outbound network calls unless verify_dependencies_online=true and that the dependency check is off by default. It also discloses the kinds of results and analysis performed. It does not explicitly state that it does not modify the project, but 'Scan' and the return-oriented language strongly imply a read-only 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 dense but every clause earns its place: the scan subject, the checks performed, the outputs, and the network-call policy. The most important facts are front-loaded and the opt-in network caveat closes the description effectively without verbosity.
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 what the tool scans, what results it returns, where dependency files are found, and the optional network-check condition. Combined with the provided output schema and simple two-parameter input schema, nothing necessary for an agent to select and invoke the tool correctly is missing.
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. The verify_dependencies_online parameter is clearly explained, including its default and network implications, while path is implied as the target Python project path. This is enough to call the tool correctly.
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 opens with a specific verb and resource: 'Scan a Python project' and immediately lists concrete risk patterns (eval/exec, dynamic attribute access, framework reflection, unsafe model loading). It goes on to state the exact outputs and is clearly distinct from its siblings, which protect, generate configs, or handle stack traces rather than analyze obfuscation risk.
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 clear this is a project-scanning/risk-assessment tool and explains when the optional dependency verification applies. It does not explicitly name alternatives or spell out when not to use it, but the context and sibling names make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_presetA
Describe what a named preset changes: exclude names count, exclude patterns, preserve_param_names, docstring handling. For Pro presets, returns full pro_unlock metadata (trial command, checkout URL, price, money-back guarantee).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by specifying that Pro presets return 'full pro_unlock metadata (trial command, checkout URL, price, money-back guarantee)', which goes beyond the bare tool name. It does not explicitly state read-only behavior, but the term 'explain' and the nature of the described outputs make non-mutation apparent.
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 two sentences with no filler. The first sentence front-loads the primary purpose and key covered aspects, while the second adds a meaningful conditional detail about Pro presets. Every word 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 description covers the core purpose, key features, and special behavior for Pro presets, which is sufficient given a single simple parameter and the presence of an output schema. It could mention a usage workflow (e.g., 'use after list_presets') but is not incomplete without it.
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 identifies the sole 'name' parameter as a preset name through the phrase 'named preset' and adds meaning by distinguishing Pro presets. However, it does not provide explicit parameter documentation, such as example names or format, leaving some room for interpretation.
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 'Describe' and the resource 'a named preset', and lists specific aspects ('exclude names count, exclude patterns, preserve_param_names, docstring handling') that differentiate it from siblings like list_presets. It is immediately clear what this tool accomplishes.
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 provides enough context to infer the tool is used for explaining preset details, and the presence of list_presets implies an alternative for listing. However, there is no explicit 'when to use' or 'when not to use' guidance, nor a direct reference to sibling tools, leaving it to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_pyobfus_configA
Generate a pyobfus.yaml for a Python project. Auto-detects frameworks and applies the matching preset. By default returns the YAML text without writing to disk; set write=true to persist.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| write | No | ||
| preset_override | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that it auto-detects frameworks and the default vs. write behavior, which is important for a generation tool, though it doesn't specify error handling or file overwrite policy.
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 two concise sentences, front-loading the purpose and then providing key behavioral details without unnecessary words.
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?
While the description covers the main action and default behavior, it omits details on the 'preset_override' parameter and error scenarios, making it adequate but not thorough for a tool with auto-detection logic.
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 description only explains the 'write' parameter; 'path' and 'preset_override' are not described despite 0% schema coverage, leaving the agent unclear on expected values and semantics.
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 generates a pyobfus.yaml for a Python project, which is specific and distinguishes it from siblings like protect_project or recommend_tier.
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 explains the default behavior (returns YAML text) and when to use the write parameter, but does not explicitly state when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_presetsA
List every pyobfus preset available, grouped by tier (community / framework-aware / Pro).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the listing behavior and the grouping structure via 'grouped by tier'. The verb 'List' implies a read-only operation, and since an output schema exists, the return format need not be detailed further.
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 front-loads the verb 'List' and directly states the scope and grouping. No wasted words.
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 list tool with no params and an output schema, the description fully answers what the tool does. It covers the listing and the grouping, and there are no preconditions or side effects to mention.
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 are zero parameters, so schema coverage is trivially 100%. The description adds no parameter information because none is needed; the baseline for 0 params is 4, and there is nothing to compensate for.
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 lists every pyobfus preset and groups them by tier (community / framework-aware / Pro). This is a specific verb+resource+scope, and it differentiates from siblings like explain_preset and recommend_tier.
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 the use case of discovering all available presets, which is clear enough from 'List every'. It does not explicitly name alternatives or exclusions, but the context of sibling tools (e.g., explain_preset) makes it obvious when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
protect_projectA
One call to protect a Python project end-to-end AND verify it still works: scans risks, picks a framework-aware preset, obfuscates, then byte-compiles + import-smoke-tests the output in isolated subprocesses and returns verified:true/false. Writes a private de-obfuscation mapping alongside (not inside) the output. Use this when the user wants to 'protect/obfuscate before shipping' and expects a green check, not just a transform.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| preset | No | ||
| verify | No | ||
| timeout | No | ||
| output_dir | No | dist | |
| verify_cmd | No | ||
| save_mapping | No | ||
| trace_marker | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the entire workflow: scans risks, picks a preset, obfuscates, byte-compiles, runs import-smoke-tests in isolated subprocesses, and returns verified:true/false. It also mentions writing a private de-obfuscation mapping alongside the output. It does not specify permissions or failure modes, which is a minor gap, but overall it provides substantial behavioral context.
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 sentences long with no filler. The first sentence is a dense, front-loaded summary of the entire workflow. The second adds a key behavioral detail (mapping placement). The third provides concise usage guidance. Every sentence 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 tool's complexity (8 params, 1 required, output schema present) and 0% schema coverage, the description covers the core workflow and usage well. It explains the main steps and expected outcome. It does not detail the output schema or all parameter behaviors, but the output schema likely handles return value documentation. Slight gap in parameter descriptions, but overall complete enough for an AI to determine appropriate 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?
Schema coverage is 0%, so the description must compensate. It provides high-level context for some parameters (e.g., 'path' as project path, 'preset' as framework-aware, 'verify' as the verification step, 'save_mapping' for the mapping file), but it does not explicitly detail all 8 parameters. For example, 'timeout', 'output_dir', 'verify_cmd', and 'trace_marker' are only briefly implied. This is minimally adequate but not thorough.
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: 'protect a Python project end-to-end AND verify it still works'. It distinguishes itself from sibling tools by emphasizing it is a combined protect+verify operation that 'returns verified:true/false', not just a transform. The context of sibling tools like check_obfuscation_risks and generate_pyobfus_config reinforces that this is a higher-level, end-to-end tool.
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 when to use: 'Use this when the user wants to protect/obfuscate before shipping and expects a green check, not just a transform.' While it doesn't name specific alternatives, the sibling list implies that other tools are for more granular steps (e.g., risk scanning or preset generation). The guidance is clear but could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_tierB
Analyze a Python project and recommend pyobfus tier (community vs Pro) with reasons. Combines a preflight scan with a sensitive-string-literal heuristic. Returns free_action and pro_action with concrete next-step commands.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it combines a preflight scan with a sensitive-string-literal heuristic and returns concrete actions. No annotations exist, so description carries the burden; it could mention if it modifies anything or prerequisites.
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?
Three concise sentences, front-loaded with purpose, method, and output. Efficient but could be more structured.
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?
Covers purpose, method, and output types (free_action, pro_action), but lacks usage guidelines and parameter details. Adequate for a simple tool with one parameter.
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 sole parameter 'path' has no description in the schema (0% coverage) and the tool description only implies it's the project path without explicit semantics or format details.
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?
Clearly states it analyzes a Python project and recommends a tier (community vs Pro) with reasons, using a heuristic. However, it does not explicitly differentiate from sibling tools like check_obfuscation_risks.
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?
Implies usage when a tier recommendation is needed, but no explicit when-not or alternatives to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_pro_trialA
Return structured guidance for starting the 5-day pyobfus Pro trial. Does NOT invoke the side effect — the user runs pyobfus-trial start in their shell. Detects whether a trial is already active and surfaces the appropriate next step plus post-trial purchase URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys behavioral traits: it returns structured guidance, does not invoke side effects, detects active trials, and surfaces next steps plus purchase URL. This is transparent and leaves no ambiguity about what the tool does or does not do.
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 wasted words. The first sentence states purpose and critical side-effect disclaimer; the second adds behavioral detail. Highly efficient 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 zero parameters, no annotations, and the presence of an output schema, the description is complete. It covers purpose, non-side-effect nature, detection capability, and what guidance is returned. No missing information for an agent to correctly select and invoke this tool.
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 tool has zero parameters and schema coverage is 100%, so baseline is 4. The description does not need to add parameter information; it implicitly covers the lack of parameters by describing the tool's function without mentioning inputs.
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: return structured guidance for starting the 5-day Pro trial. It specifies the resource ('pyobfus Pro trial') and action ('return structured guidance'), and distinguishes itself from sibling tools by noting it does not invoke the side effect.
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?
Provides explicit when-to-use guidance: it is for guidance only, not for actual trial activation, as the user must run `pyobfus-trial start` in their shell. It also mentions detecting active trial status, which helps an agent decide whether to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unmap_stack_traceA
Reverse obfuscated identifiers in a stack trace using a pyobfus mapping.json. Accepts the trace as plain text and the path to a mapping file produced by --save-mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| trace | Yes | ||
| mapping_path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden for behavioral transparency. It does not disclose whether the tool is read-only, requires any permissions, has side effects, or error handling behavior. The description only states the action and inputs, leaving gaps about what happens internally or under failure conditions.
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 concise, consisting of two sentences that deliver all necessary information without fluff. It is front-loaded with the action and efficiently explains inputs.
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 has two simple parameters and an output schema, the description is fairly complete. It explains the purpose, inputs, and the origin of the mapping file. It could briefly mention what the output looks like (e.g., unmapped trace), but the output schema handles that. Overall, it provides sufficient context for a tool of this 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 description coverage, the description effectively compensates by naming both parameters and providing context: 'trace' is described as 'plain text', and 'mapping_path' is described as 'the path to a mapping file produced by --save-mapping.' This adds meaningful usage guidance beyond the bare schema titles.
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: 'Reverse obfuscated identifiers in a stack trace using a pyobfus mapping.json.' It specifies the verb (reverse), resource (stack trace), and method (mapping file), which distinguishes it from sibling tools like check_obfuscation_risks and generate_pyobfus_config.
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 by stating what it does and what inputs are needed (trace as plain text, mapping file path). However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. Given the sibling tools, usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v0.5.14- Changed
check_obfuscation_risks1 field changed- added
Input schema / properties / verify_dependencies_onlineAdded value: +{ + "default": false, + "title": "Verify Dependencies Online", + "type": "boolean" +}
2 tool updates
v0.5.7- Added
explain_preset - Added
list_presets
2 tool updates
v0.5.6- Added
generate_pyobfus_config - Removed
list_presets
2 tool updates
- Removed
explain_preset - Removed
generate_pyobfus_config
1 tool update
v0.5.4- Added
protect_project
2 tool updates
v0.4.1- Added
recommend_tier - Added
start_pro_trial
TDQS
Most tools have clearly distinct purposes, but check_obfuscation_risks and recommend_tier both analyze a project and could be confused, and generate_pyobfus_config overlaps slightly in framework detection. Detailed descriptions help disambiguate in most cases.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., protect_project, list_presets, explain_preset). There are no mixed conventions or vague verbs.
Eight tools is well-scoped for a specialized server. Each tool serves a distinct role in the pyobfus workflow—scanning, configuring, protecting, explaining presets, unmapping traces, and trial guidance—without redundancy.
The tool set covers the core lifecycle: risk analysis, config generation, full protection with verification, preset exploration, stack trace unmapping, and trial guidance. However, it lacks a tool to apply a custom generated config directly, and has no standalone verification or mapping management tools, which are minor gaps.
Maintenance
Related MCP Connectors
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
Related MCP Servers
- AlicenseAqualityCmaintenanceModel Context Protocol server for fetching web content and processing images. This allows Claude Desktop (or any MCP client) to fetch web content and handle images appropriately.11,24741MIT
- AlicenseNot gradedqualityCmaintenanceA Model Context Protocol server that enables AI assistants like Claude to perform Python development tasks through file operations, code analysis, project management, and safe code execution.9MIT
- AlicenseNot gradedqualityDmaintenanceA custom Model Context Protocol server that gives Claude Desktop and other LLMs access to file system operations and command execution capabilities through standardized tool interfaces.23Apache 2.0
- FlicenseBqualityDmaintenanceA Model Context Protocol server that enables Claude users to access specialized OpenAI agents (web search, file search, computer actions) and a multi-agent orchestrator through the MCP protocol.410-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhurong2020/pyobfus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server