Skip to main content
Glama
zhurong2020

pyobfus-mcp

by zhurong2020
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
use_project_configNo
verify_dependencies_onlineNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.21
    • addedInput schema / properties / use_project_config
      Added value: +{
+  "default": true,
+  "title": "Use Project Config",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv0.5.14
    • addedInput schema / properties / verify_dependencies_online
      Added value: +{
+  "default": false,
+  "title": "Verify Dependencies Online",
+  "type": "boolean"
+}
  3. First observedv0.1.2

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.

Install Server

Other Tools