pyobfus-mcp

by zhurong2020

Overview Schema Source Related Servers Discussions Admin

check_obfuscation_risks

Scan Python code for patterns that break obfuscation, get risk counts, frameworks detected, and a suggested preset. Optionally verifies dependencies against PyPI to catch hallucinated package names.

Instructions

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. By default the scan honors the project's pyobfus config; set use_project_config=false for the legacy config-free scan.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "check_obfuscation_risks"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`use_project_config`	No
`verify_dependencies_online`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.21Sep 6, 2026

addedInput schema / properties / use_project_config

Added value: +{
+  "default": true,
+  "title": "Use Project Config",
+  "type": "boolean"
+}

Changed1 schema field changedv0.5.14Aug 24, 2026

addedInput schema / properties / verify_dependencies_online

Added value: +{
+  "default": false,
+  "title": "Verify Dependencies Online",
+  "type": "boolean"
+}

First observedv0.1.2May 7, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states that no outbound network calls occur unless verify_dependencies_online=true, it explains the default config-honoring behavior and the legacy fallback, and it describes the returned data. This is unusually transparent for a scan tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, and the core purpose is front-loaded. The caveats about network calls and config behavior earn their place. It could be broken into shorter sentences for easier parsing, but it does not waste words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no annotations, but the description covers the main purpose, parameter semantics, side-effect profile, and output summary (severity counts, frameworks, suggested preset). An output schema is present for exact return structure, so the description need not repeat that detail. This is fully adequate for an agent to decide whether to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates thoroughly. It explains that path points to the Python project, use_project_config controls whether the project's pyobfus config is honored versus the legacy config-free scan, and verify_dependencies_online gates the PyPI check and clarifies the offline default. Every parameter gains meaning beyond its name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Scan') and a clear resource ('a Python project'), then enumerates exactly what patterns are checked (eval/exec, dynamic attribute access, framework reflection, unsafe model loading). It also names distinguishable outputs (severity counts, detected frameworks, suggested preset), which differentiates it sharply from sibling tools like protect_project or 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear sense of when this tool is relevant: before obfuscation, to identify risk patterns and decide a preset. It also explains behavioral brancks like use_project_config and verify_dependencies_online. However, it does not explicitly contrast this tool with siblings or state when to prefer an alternative, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server