Skip to main content
Glama
ctx-gen-mcp

ctx-gen-mcp

by liubinmaster

ctx-gen-mcp

Code context wiki generator -- MCP Server + OpenCode plugin for navigable, progressive-disclosure code docs with domain grouping, tags, and dependency graph.

What It Does

Generates a navigable Code Wiki for large projects, so AI coding agents can quickly locate and understand any module without reading the entire codebase.

Instead of dumping flat documentation, ctx-gen produces:

  • INDEX.md -- single entry point with domain table, tag index, and module list

  • Cross-linked wiki pages -- each module has its own .wiki.md with YAML front-matter, summary, dependency links, and detailed content

  • Domain grouping -- modules auto-grouped by directory structure

  • Tag-based lookup -- find modules by language, architecture level, tech feature

  • Dependency graph -- shallow #include/import analysis with cross-links

Related MCP server: mcp-codemap

Progressive Disclosure

The wiki is designed so AI agents read the minimum to locate what they need:

  1. INDEX.md (~50-100 lines) -- scan domains and tags

  2. lookup MCP tool -- find modules by keyword without reading the INDEX

  3. Module wiki page -- full context for one module with cross-links to related modules

  4. Follow links -- Depends: / Used by: links for impact analysis

One-Click Install

# 1. Install the pip package
pip install ctx-gen-mcp

# 2. Run one-click setup (installs skill + agent + MCP config)
ctx-gen-setup

That's it. OpenCode will now have:

  • A ctx-gen skill (loadable via /ctx-gen)

  • A ctx-gen agent (switchable in agent panel)

  • MCP server config in opencode.json

  • AGENTS.md in your project root

Usage

  1. Open your project in OpenCode

  2. Say: "use the ctx-gen skill to generate context wiki"

  3. Or switch to the ctx-gen agent in the agent panel

  4. The agent will: scan -> generate per-module JSON -> validate -> assemble wiki

MCP Tools (any MCP-compatible agent)

The package exposes 4 deterministic MCP tools:

Tool

What it does

scan_skeleton

Scan repo -> skeleton with domains, tags, dependency graph

lookup

Find modules by tag/domain/keyword (no need to read full INDEX)

validate_coverage

Check all modules have context, detect stale ones

assemble_docs

Build wiki INDEX.md + cross-linked .wiki.md pages

CLI

# Run MCP server directly (for testing)
ctx-gen-server

# Or:
python -m ctx_gen_mcp.server

# Re-run setup (e.g. after moving project)
ctx-gen-setup --project-dir /path/to/project

# Install globally (all projects)
ctx-gen-setup --global

# Uninstall
ctx-gen-setup --uninstall

Output

After running, you'll have:

.ctx-cache/
  skeleton.json             # repo structure with domains/tags/deps (deterministic)
  ctx/
    <module_id>.json       # per-module structured context
docs/
  wiki/
    INDEX.md               # single entry point
    domains/
      <domain>/
        <module>.wiki.md   # cross-linked per-module wiki page

Add these to .gitignore:

.ctx-cache/
docs/wiki/

Architecture

Core Insight: Separate Deterministic from LLM Operations

Operation

Who does it

Why

Repo scanning + domain grouping

scan_skeleton (deterministic)

Glob + regex never hallucinates

Module lookup by tag/keyword

lookup (deterministic)

String matching is exact

Per-module description

LLM (via Agent)

Needs semantic understanding

Coverage validation

validate_coverage (deterministic)

Hash comparison is exact

Wiki assembly

assemble_docs (deterministic)

Template + cross-link generation

Domain Grouping (Hybrid Strategy)

  1. Directory-based first: src/engine/ -> domain "engine"

  2. If a domain has >10 modules, flagged for potential LLM subdivision

  3. Domains are reflected in the output directory structure

Tag Inference (Automatic)

Tags are inferred from file names, directory names, and shallow content analysis:

Dimension

Examples

Detection Method

Language

cpp, python, c

File extension statistics

Architecture

kernel-mode, user-mode, shared-lib

Filename + content keywords

Tech feature

driver, crypto, network, async, ipc

Filename + content keywords

Build target

static-lib, shared-lib, exe

Build system analysis

Dependency Detection (Shallow)

Only direct #include, import, require statements are analyzed. This covers ~80% of real dependencies with zero parser overhead.

Requirements

  • Python >= 3.10

  • OpenCode >= 1.0 (for skill/agent support)

  • Or any MCP-compatible agent (Claude Code, etc.)

License

MIT

Available Tools

3 tools
assemble_docsC

Assemble all per-module JSON context files into progressive-disclosure MD docs.

Args: project_dir: Path to the project root. ctx_dir: Path to the ctx/ directory with per-module JSONs. out_docs: Output directory for MD docs. project_name: Optional project name (default: inferred from project_dir).

Returns: Dict with: main_doc, module_docs[], errors[].

Inputs: project_dir (required), ctx_dir (required), out_docs (required), project_name.

scan_skeletonA

Scan a code repository and return a deterministic module skeleton.

Args: project_dir: Absolute path to the project root directory. depth: Directory depth for auto-detecting modules (default 2). code_only: If True, only include code files (default True).

Returns: A dict with: root_path, total_modules, total_files, total_lines, modules[].

Inputs: project_dir (required), depth, code_only.

validate_coverageA

Validate that every module has a generated context JSON, and detect stale ones.

Args: project_dir: Path to the project root. ctx_dir: Path to the ctx/ output directory. check_stale: If True, detect modules whose source has changed (default True).

Returns: Dict with: total_modules, generated, coverage_pct, missing_ids[], stale_ids[], unknown_fields_summary{}.

Inputs: project_dir (required), ctx_dir (required), check_stale.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 3 tools

    Disambiguation5/5

    Each tool targets a distinct phase in the documentation generation workflow—scanning, assembling, and validating—with no functional overlap.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern (assemble_docs, scan_skeleton, validate_coverage) with clear action and object.

    Tool Count5/5

    Three tools are well-scoped for a context generation server, covering the essential operations without excess or deficiency.

    Completeness4/5

    The tool surface covers the core workflow (scan, assemble, validate), but lacks a tool to manage or regenerate specific context files manually.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers