Skip to main content
Glama
KoyoYeager

io.github.KoyoYeager/pystub

by KoyoYeager
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

mcp-pystub

Python exe ビルド（PyInstaller / Nuitka / cx_Freeze）時にスタブ置換可能なパッケージを自動検出し、最小スタブコードを生成する MCP サーバー。

An MCP server that auto-detects stubbable packages for Python exe builds (PyInstaller / Nuitka / cx_Freeze) and generates minimal stub code to reduce executable size.

背景 / Background

Python アプリを exe 化すると、依存ライブラリがモジュールレベルで import する重量パッケージが丸ごと同梱され、exe サイズが膨張する。実際のコードパスで使わないパッケージは最小ダミー（スタブ）で置換すれば大幅なサイズ削減が可能。

When building Python apps into executables, heavy packages imported at module level by dependencies get bundled entirely, bloating the exe size. Replacing unused packages with minimal stubs can significantly reduce size.

実証データ / Verified Results

asammdf プロジェクト — PyInstaller exe ビルド（E2E 動作確認済み）:

exe サイズ

動作

PySide6

スタブなし

431 MB

OK

ロード済み

asammdf.gui スタブ適用

259 MB

OK

排除

削減

-40%（172 MB）

影響なし

asammdf 変換ツール（analyze 結果）:

stubbable:          pandas (59.7 MB), canmatrix (4.0 MB) — 合計 63.7 MB
submodule hints:    asammdf.gui → PySide6 (523 MB) 排除可能 — 50 hints 検出

手動でスタブ化していた 3 パッケージ（pandas, canmatrix, asammdf.gui）を全て自動検出

Related MCP server: AutoDocs MCP Server

機能 / Features

ツール / Tool

説明 / Description

analyze

import グラフを解析しスタブ候補を自動検出。C拡張パッケージの間接排除ヒントも出力 / Auto-detect stubbable packages + submodule stub hints for C-extension elimination

graph

import グラフをノード・エッジで可視化 / Visualize import graph as nodes and edges

check

特定パッケージの使用状況を詳細分析 / Deep analysis of a specific package's usage

generate

パッケージスタブの最小コードを生成 + ビルド手順出力 / Generate minimal stub code + build instructions

generate_submodule

C拡張パッケージを間接排除するサブモジュールスタブを生成 / Generate submodule stubs to indirectly eliminate C-extension packages

判定結果 / Verdicts

判定 / Verdict

意味 / Meaning

stubbable

スタブ化可能。プロジェクトの実行パスで未使用 / Safe to stub. Not used in project's runtime path

nofollow

try/except 保護あり。--nofollow-import-to で除外推奨 / Protected import. Use --nofollow-import-to

required

スタブ化不可。実際に使用されている / Cannot stub. Actually used at runtime

できること / What It Can Do

  • ライブラリ非固定の汎用検出: AST 構造のみで判定。ハードコードなし

  • 関数レベルの使用追跡: mdf.get() は使うが mdf.to_dataframe() は使わない → pandas は stubbable

  • Call と参照の区別: isinstance(x, pd.DataFrame) は stub-safe、pd.DataFrame(data) は実使用

  • クラス継承の検出: class User(BaseModel) → pydantic は required

  • module-level 呼び出し検出: import 時に実行されるコードを追跡

  • try/except 保護の自動検出: 保護された import は nofollow と判定

  • スタブコード自動生成: 参照シンボルのみの最小スタブ + ビルド手順（バックアップ・復元・検証）

  • C 拡張の自動検出: .pyd / .so を含むパッケージは直接スタブ化不可と判定

  • C 拡張の間接排除 (v0.2 new): C拡張パッケージを import しているサブモジュールが未使用なら、そのサブモジュールをスタブ化して C拡張を排除可能。PySide6 (523 MB) → asammdf.gui スタブで exe 40% 削減を実証

  • 復元安全設計 (v0.2 new): バックアップ + バージョン固定 pip + 検証コマンドの 3 重安全策

  • PyInstaller フック情報: 無効化が必要なフックファイルを通知

できないこと・制限事項 / Limitations

  • C 拡張パッケージ（.pyd / .so）は直接スタブ化すると C 拡張が欠落するため required 判定。ただし generate_submodule で間接排除が可能（v0.2 で対応）

  • 動的 import（importlib.import_module(変数)）は静的解析で追跡不可（warnings で通知）

  • PyInstaller カスタムフック: スタブと衝突する場合がありフックの手動無効化が必要

  • 遅延初期化パターン: __init__ で直接呼ばず後のメソッドで使うパッケージは検出精度が下がる（安全側で required に判定）

  • pip 名と import 名の不一致: python-dateutil → dateutil 等のマッピングは未対応

  • ランタイムの条件分岐: if sys.version < (3,11) 内の import は静的解析で判定不可

安全性の設計方針 / Safety Policy

「stubbable と判定したが実は必要だった」は絶対に起こさない設計。判定に迷う場合は required（安全側）に倒す。逆方向の誤判定（本当は stubbable なのに required）は許容する。

解析アルゴリズム / Analysis Algorithm

  1. Import 抽出: ast.parse() で各ファイルの import 文を解析（module-level / function-level / try-except 保護を区別）

  2. Import グラフ構築: エントリーポイントから BFS で依存関係を再帰解決（stdlib / third_party / local を自動分類）

  3. 使用分析: gateway 関数（依存ライブラリ内でパッケージを呼び出す関数）を特定し、プロジェクトコードがそれを呼んでいるか追跡。名前参照のみ（isinstance, 型アノテーション）は stub-safe として除外

  4. Module-level 検出: import 時にパッケージの関数が呼ばれる場合は required に格上げ

  5. サブモジュール間接排除 (v0.2): C拡張パッケージを import しているサブモジュールを特定し、プロジェクトが直接 import していない + re-export シンボルを呼んでいない場合にスタブ化ヒントを出力

インストール / Installation

pip install mcp-pystub

依存パッケージ / Dependencies

  • mcp>=1.0.0 - Model Context Protocol SDK

  • 解析エンジンは Python 標準ライブラリのみ使用（ast, importlib, pathlib）

使い方 / Usage

MCP サーバーとして起動 / Run as MCP server

mcp-pystub

Claude Desktop / Claude Code 設定

{
  "mcpServers": {
    "pystub": {
      "command": "mcp-pystub"
    }
  }
}

ツール使用例 / Tool Examples

analyze

入力 / Input:
  entry_point: "C:/project/converter.py"
  python_path: "C:/project/.venv/Lib/site-packages"

出力 / Output:
  {
    "stubbable": [
      {"package_name": "pandas", "estimated_size_mb": 59.7, "reason": "依存ライブラリ経由でのみ import..."}
    ],
    "required": [
      {"package_name": "numpy", "reason": "プロジェクトコードが直接 import し使用"},
      {"package_name": "PySide6", "estimated_size_mb": 523.2,
       "reason": "C 拡張...ただし asammdf.gui をスタブ化することで間接排除が可能",
       "submodule_stubs": [{"submodule": "asammdf.gui", "target_package": "PySide6"}]}
    ],
    "nofollow": [
      {"package_name": "mpmath"}
    ],
    "submodule_stub_hints": [
      {"submodule": "asammdf.gui", "parent_package": "asammdf",
       "target_package": "PySide6", "imported_symbols": ["plot"]}
    ],
    "analysis_time_ms": 6478
  }

generate

入力 / Input:
  entry_point: "C:/project/converter.py"
  package_name: "pandas"

出力 / Output:
  {
    "files": {
      "pandas/__init__.py": "...",
      "pandas/core/api.py": "class DataFrame: pass\nclass Series: pass\n..."
    },
    "original_file_count": 2980,
    "stub_file_count": 266,
    "stub_total_bytes": 209530,
    "build_instructions": {
      "install_commands": ["pip uninstall -y pandas", "# cp stubs to site-packages"],
      "uninstall_commands": ["pip install pandas"],
      "hook_disable": ["# hook-pandas*.py → .disabled"]
    }
  }

generate_submodule (v0.2 new)

入力 / Input:
  entry_point: "C:/project/converter.py"
  parent_package: "asammdf"
  submodule: "asammdf.gui"

出力 / Output:
  {
    "parent_package": "asammdf",
    "submodule": "asammdf.gui",
    "files": {
      "asammdf/gui/__init__.py": "\"\"\"Auto-generated stub...\"\"\"\ndef plot(*args, **kwargs): ..."
    },
    "eliminated_packages": ["PySide6", "scipy", "lxml"],
    "original_size_bytes": 5907331,
    "stub_size_bytes": 144,
    "build_instructions": {
      "backup_commands": ["cp -r .../asammdf/gui .../asammdf/gui.bak"],
      "install_commands": ["rm -rf .../asammdf/gui", "cp -r _stubs/asammdf/gui/ .../asammdf/gui/"],
      "uninstall_commands": ["mv .../asammdf/gui.bak .../asammdf/gui"],
      "verify_commands": ["python -c \"import asammdf; print('OK')\""]
    }
  }

パフォーマンス / Performance

プロジェクト規模

解析時間

ノード数

軽量 (click)

335ms

73

中規模 (flask)

1,743ms

230

重量級 (pandas)

4,820ms

491

超重量級 (sympy)

6,919ms

681

テスト / Testing

python -m pytest tests/ -v

テスト実績

テスト種別

件数

結果

ユニットテスト（9モジュール）

91

全通過

PyPI ライブラリ大規模テスト（requests, flask, pandas 等）

84

クラッシュ 0

PyInstaller exe ビルド + 動作テスト

22

全 PASS

asammdf E2E（MDF作成→読取→リサンプリング）

1

exe 40% 削減 + 正常動作

復元テスト（バックアップ → 復元 → 検証）

4

全成功

ライセンス / License

MIT

Available Tools

5 tools
analyzeA

プロジェクトのエントリーポイントから import グラフを解析し、 スタブ置換可能なパッケージを自動検出します。

各パッケージは以下のいずれかに判定されます:

  • stubbable: スタブ化可能（プロジェクトの実行パスで未使用）

  • nofollow: try/except 保護あり（--nofollow-import-to で除外推奨）

  • required: スタブ化不可（実際に使用されている）

Args: entry_point: プロジェクトのエントリーポイントファイルパス python_path: site-packages パス（空の場合は現在の環境を自動検出） max_depth: import グラフの最大探索深度（デフォルト: 10）

Returns: stubbable / nofollow / required に分類されたパッケージ一覧

ParametersJSON Schema
NameRequiredDescriptionDefault
entry_pointYes
python_pathNo
max_depthNo

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description fully handles behavioral disclosure: it explains the analysis process and classification logic. However, it omits details like error handling, performance, or whether it modifies files, which would be needed for a perfect score.

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 well-structured with a clear introduction, bullet points for classifications, and an Args/Returns section. It is appropriately sized, though a slightly more concise phrasing could improve it.

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 description is complete for a tool with no output schema: it details the return value (classified package list) and the three possible classifications, providing sufficient context for agent invocation.

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?

The description provides clear semantics for all three parameters in the 'Args' section, explaining their purpose and defaults (e.g., max_depth default 10). This fully compensates for the 0% schema description coverage.

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 clearly states the tool analyzes import graphs from an entry point and detects stubbable packages, with specific classification outcomes. This distinct purpose differentiates it from siblings like 'generate' or 'graph'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage by explaining classifications and recommending exclusions for nofollow packages, but does not explicitly state when to use this tool vs. alternatives or provide context for when not to use it.

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

checkB

特定のパッケージがプロジェクト内でどのように使われているか詳細に分析します。

import チェーン、gateway 関数、プロジェクトからの呼び出し状況を 追跡して判定結果を返します。

Args: entry_point: プロジェクトのエントリーポイントファイルパス package_name: 調査するパッケージ名（例: "pandas"） python_path: site-packages パス（空の場合は現在の環境を自動検出） max_depth: import グラフの最大探索深度（デフォルト: 5）

Returns: パッケージの詳細な使用分析と判定結果

ParametersJSON Schema
NameRequiredDescriptionDefault
entry_pointYes
package_nameYes
python_pathNo
max_depthNo

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions tracking imports and returning analysis, but it does not discuss side effects, permissions, rate limits, or any constraints. The description is minimal beyond the basic purpose.

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 concise and well-structured with a clear purpose followed by an Args block that lists each parameter. It avoids unnecessary fluff, though the Japanese text could be slightly shorter. The front-loading of the core purpose is good.

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

Completeness3/5

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

The description covers the tool's functionality and parameter meanings adequately. However, it lacks details about the return format beyond 'detailed analysis and judgment'. Given no output schema and no annotations, more completeness would be beneficial, especially regarding expected output structure.

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

Parameters4/5

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

Despite 0% schema description coverage, the description adds meaningful context for all four parameters: entry_point (project entry file), package_name (package to investigate), python_path (site-packages path, auto-detect if empty), and max_depth (max search depth, default 5). This significantly aids the agent in understanding parameter usage.

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

Purpose4/5

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

The description clearly states that the tool analyzes how a specific package is used in a project, tracking import chains, gateway functions, and call status. It uses a specific verb ('analyze') and resource ('package'), and while the sibling 'analyze' exists, the description narrows focus to package usage, providing decent differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description only explains what the tool does but does not provide guidance on when to use it versus alternatives like analyze, generate, etc. It lacks any 'when not to use' or context for selection, leaving the agent without decision support.

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

generateA

stubbable パッケージの最小スタブコードを生成します。

analyzer が特定した参照シンボルに基づき、import が通る最小限の ダミーモジュール（クラス定義 + 関数スタブ）を生成します。 ファイルの書き出しは行わず、{パス: コード} の辞書を返します。

Args: entry_point: プロジェクトのエントリーポイントファイルパス package_name: スタブ化するパッケージ名（例: "pandas"） python_path: site-packages パス（空の場合は現在の環境を自動検出）

Returns: files: {相対パス: コード内容} の辞書 referenced_symbols: 各モジュールで参照されるシンボル一覧 stub_total_bytes: スタブの合計サイズ

ParametersJSON Schema
NameRequiredDescriptionDefault
entry_pointYes
package_nameYes
python_pathNo

TDQS

A3.8/5.0
Behavior4/5

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

Discloses key behaviors: generates based on symbol references, writes no files, returns a dictionary. With no annotations, description carries full burden and does so adequately, though could mention error handling.

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?

Moderate length with a logical structure: purpose, process, return format, parameters. No extraneous text, but could be slightly more concise.

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

Completeness4/5

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

Covers purpose, process, parameters, and return values. Without output schema, it lists return keys (files, referenced_symbols, stub_total_bytes), providing sufficient context for a generate 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 has 0% description coverage; the description provides clear explanations for all three parameters in an 'Args' section, fully compensating for missing schema descriptions.

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

Purpose4/5

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

Clearly states it generates minimal stub code for a stubbable package, specifying verb and resource. However, does not explicitly differentiate from sibling tool 'generate_submodule', leaving some ambiguity about scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'analyze' or 'generate_submodule'. The description is purely functional, lacking context for selection.

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

generate_submoduleA

C拡張パッケージを間接排除するためのサブモジュールスタブを生成します。

PySide6 のような C拡張パッケージは直接スタブ化できませんが、 そのパッケージを import しているサブモジュール（例: asammdf.gui）を スタブ化することで間接的に排除できます。

analyze ツールの結果に含まれる submodule_stub_hints の情報を元に このツールを使用してください。

復元失敗を防ぐため、バックアップ・バージョン固定・検証ステップを 含むビルド手順を生成します。

Args: entry_point: プロジェクトのエントリーポイントファイルパス parent_package: サブモジュールが属するパッケージ名（例: "asammdf"） submodule: スタブ化するサブモジュール（例: "asammdf.gui"） python_path: site-packages パス（空の場合は現在の環境を自動検出）

Returns: files: {相対パス: コード内容} の辞書 eliminated_packages: 排除されるパッケージ一覧 build_instructions: バックアップ・適用・復元・検証の手順

ParametersJSON Schema
NameRequiredDescriptionDefault
entry_pointYes
parent_packageYes
submoduleYes
python_pathNo

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool generates build instructions including backup and verification to prevent recovery failure, but does not detail side effects, permissions, or error handling.

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 well-structured with a clear purpose statement, usage context, parameter list, and return description. It is appropriately sized, though some redundancy exists.

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

Completeness3/5

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

Given the complexity (4 parameters, no output schema, no annotations), the description covers purpose, usage context, and return format adequately. However, it omits error conditions, prerequisites, and differentiation from sibling tools.

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

Parameters3/5

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

The input schema has 0% description coverage, and the description compensates by briefly explaining each parameter with examples. However, the explanations are not exhaustive and lack constraints or validation details.

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

Purpose4/5

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

The description clearly states that the tool generates a submodule stub for indirectly excluding C extension packages that cannot be directly stubbed. It specifies the use case and resource, but does not explicitly differentiate from the sibling 'generate' tool.

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 instructs to use this tool based on 'submodule_stub_hints' from the 'analyze' tool, providing clear context. However, it lacks explicit exclusion criteria or alternatives for when not to use it.

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

graphA

エントリーポイントからの import グラフを構築して可視化します。

全モジュールの依存関係をノードとエッジで返します。 各ノードは stdlib / third_party / local / builtin / unresolvable に分類されます。

Args: entry_point: プロジェクトのエントリーポイントファイルパス python_path: site-packages パス（空の場合は現在の環境を自動検出） max_depth: 最大探索深度（デフォルト: 5）

Returns: ノード・エッジ・統計情報を含むグラフデータ

ParametersJSON Schema
NameRequiredDescriptionDefault
entry_pointYes
python_pathNo
max_depthNo

TDQS

A3.8/5.0
Behavior3/5

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

The description discloses that it returns nodes classified by module type and includes statistics, which is helpful. However, it does not mention whether the tool is read-only, any side effects, authentication needs, or performance characteristics. With no annotations provided, the description carries the full burden but falls short of full transparency.

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 structured with an overview, then Args and Returns sections. It is relatively concise, though the opening line could be more direct. Overall, it is well-organized and not verbose.

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

Completeness4/5

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

For a tool with three parameters and no output schema, the description provides a reasonable overview of what the tool does and returns (nodes, edges, statistics). It could be more detailed about the exact fields in the output, but it is sufficient for an agent to understand the tool's basic functionality.

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?

The input schema provides only titles and types with no descriptions (0% coverage). The description compensates fully by explaining each parameter: entry_point is the project entry point file path, python_path is for site-packages (auto-detected if empty), and max_depth is maximum depth with a default of 5. This adds significant meaning beyond the schema.

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 clearly states the tool constructs and visualizes an import graph from an entry point, returning dependency relationships as nodes and edges. It distinguishes itself from sibling tools (analyze, check, generate, generate_submodule) by focusing on dependency graph construction and visualization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus its siblings (analyze, check, generate, generate_submodule). It lacks explicit usage context, making it harder for an agent to decide which tool to invoke.

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. 5 tool updatesv0.2.0
    • First observedanalyze
    • First observedcheck
    • First observedgenerate
    • First observedgenerate_submodule
    • First observedgraph
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: analyze classifies packages, check dives into specific usage, generate produces stubs, generate_submodule handles C extension submodules, and graph visualizes imports. No overlap.

Naming Consistency5/5

All tool names follow a consistent pattern: lowercase English verbs (analyze, check, generate, graph) with one compound (generate_submodule) that follows the verb_noun convention. No mixing of styles.

Tool Count5/5

5 tools is well-scoped for the domain of import analysis and stub generation, covering detection, inspection, generation (both regular and submodule), and visualization without unnecessary tools.

Completeness4/5

The tool set covers the core workflow: detection, detailed analysis, stub generation for both regular and C extension packages, and visualization. Missing a tool to actually write stubs to disk or apply them, but this can be done externally.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/KoyoYeager/mcp-pystub'

If you have feedback or need assistance with the MCP directory API, please join our Discord server