Neuledge Context

repository·main·Indexed 43 days ago

https://github.com/neuledge/context

An MCP (Model Context Protocol) server that provides AI agents with fast, private, and offline access to version-specific library documentation using local SQLite databases. It supports building custom documentation packages from Git repositories, local directories, and websites via the `context add` command, and integrates with AI tools including Claude Code, Claude Desktop, Cursor, OpenAI Codex, VS Code (GitHub Copilot), Windsurf, Zed, and Goose.

Tokens
23.2K
Snippets
102
Records
120
Agent score
58%

What's inside Neuledge Context

  1. Exclude specific paths from a source

    main

    If a directory contains material that belongs to a different package, use exclude_paths to prune it.

    • Patterns: Use glob-style patterns (* for a single segment, ** for across segments).
    • Context: Patterns are matched against the path relative to docs_path (or the repository root if docs_path is not set).
    • Best Practice: Prefer narrowing the docs_path if the content is already isolated. Use exclude_paths when a wider docs_path would pull in unwanted sibling content (like a different language or framework).
    source:
      type: git
      url: https://github.com/godotengine/godot-docs
      ref: stable
      exclude_paths:
        - "tutorials/scripting/c_sharp/**"
  2. Package format: SQLite .db schema

    main

    Documentation packages are SQLite databases. To be compatible with the Context Download Server, packages must follow this schema:

    • meta table: Stores key-value pairs for package metadata. Required keys: name, version. Optional keys: description, source_url, source_commit.
    • chunks table: Stores documentation sections. Fields include doc_path, doc_title, section_title, content, tokens, and has_code.
    • chunks_fts virtual table: A Full-Text Search index using fts5 on the chunks table.
    -- Package metadata
    CREATE TABLE meta (
      key TEXT PRIMARY KEY,
      value TEXT
    );
    
    -- Documentation chunks
    CREATE TABLE chunks (
      id INTEGER PRIMARY KEY,
      doc_path TEXT NOT NULL,
      doc_title TEXT NOT NULL,
      section_title TEXT NOT NULL,
      content TEXT NOT NULL,
      tokens INTEGER NOT NULL,
      has_code INTEGER DEFAULT 0
    );
    
    -- Full-text search index
    CREATE VIRTUAL TABLE chunks_fts USING fts5(
      doc_title, section_title, content,
      content='chunks', content_rowid='id',
      tokenize='porter unicode61'
    );
  3. How the Context architecture works

    main

    Context provides an MCP server that acts as a bridge between your AI agent and your local documentation.

    1. Discovery: When you ask about a library, the MCP server first searches the Community Registry.
    2. Installation: It downloads the pre-built documentation package (a SQLite .db file) and stores it in ~/.context/packages/.
    3. Retrieval: Subsequent queries use FTS5 full-text search on the local SQLite database to find relevant sections, applying smart filtering to keep results within the AI's token budget. This ensures high-speed, accurate documentation retrieval (often <10ms).
  4. URL encoding for scoped packages

    main
    When interacting with the API, path parameters like registry, name, and version must be URL-encoded. This is particularly important for scoped packages (e.g., @trpc/server). Clients should use encodeURIComponent() to ensure characters like @ and / are transmitted correctly.
  5. How the Community Registry works

    main

    The Community Registry is a collection of YAML files, where each file is a package definition. A package definition describes where a library's documentation lives and how to build it. A daily automated job processes these files, builds a searchable .db package from each, and publishes it so that context install can fetch it.

    To add a library to the registry, you simply add one YAML file. No code is required.

  6. Run Context via Docker

    main

    Run Context as a containerized HTTP server for multi-client or Kubernetes deployments. The container starts Context with HTTP transport on port 8080, accessible at http://localhost:8080/mcp.

    Build and Run: (Note: Run from the repository root to ensure the monorepo lockfile is available)

    docker build -t context:local -f packages/context/Dockerfile .
    docker run --rm -p 8080:8080 context:local
    # Run from the repository root (required for the monorepo lockfile)
    docker build -t context:local -f packages/context/Dockerfile .
    docker run --rm -p 8080:8080 context:local
  7. Develop the Context project

    main

    Use the following pnpm commands to manage the development workflow of the Context repository:

    • pnpm install: Install dependencies
    • pnpm build: Build the project
    • pnpm test: Run tests
    • pnpm lint: Run linting
    # Install dependencies
    pnpm install
    
    # Build
    pnpm build
    
    # Test
    pnpm test
    
    # Lint
    pnpm lint
  8. Build a package definition locally before submitting a PR

    main

    Before opening a Pull Request to add a new definition, build it locally to ensure it produces the expected content. A healthy build should report a few hundred sections; if it only reports a handful, your docs_path is likely incorrect.

    pnpm install
    pnpm --filter @neuledge/registry registry build <name>
  9. Build custom documentation packages with `context add`

    main

    While the community registry provides many popular libraries, you can use context add to build your own documentation packages from various sources:

    • Git Repository: context add <git-url>
    • Local Directory: context add <path>
    • Specific Version Tag: context add <git-url>/tree/<tag>
    • Website with llms.txt: context add <website-url>

    Once built, you can export and share these packages as portable .db files.

    Exporting a package:

    context add ./my-project --name my-lib --pkg-version 2.0 --save ./packages/

    Installing a shared package:

    context add ./packages/my-lib@2.0.db
    # Build from a git repository
    context add https://github.com/your-company/design-system
    
    # Build from a local directory
    context add ./my-project
    
    # Specific version tag
    context add https://github.com/vercel/next.js/tree/v16.0.0
    
    # Build from a website's llms.txt
    context add https://svelte.dev
    
    # Export a package
    context add ./my-project --name my-lib --pkg-version 2.0 --save ./packages/
    
    # Teammate installs it (no build step needed)
    context add ./packages/my-lib@2.0.db
  10. Contribute package definitions to the registry

    main

    You can contribute new ecosystem definitions by adding YAML files to the registry/ directory. Definitions are organized by package manager:

    • registry/npm/: JavaScript/TypeScript (e.g., Next.js, React)
    • registry/pip/: Python (e.g., FastAPI, Flask, Django)
    • registry/maven/: Java (e.g., Spring Boot, JUnit)

    Supported source types for definitions are git and zip.

  11. Connect Context to VS Code (GitHub Copilot)

    main

    Requires VS Code 1.102+ with GitHub Copilot. Add the following to .vscode/mcp.json in your workspace, then click the Start button that appears in the file to enable Agent mode in Copilot Chat.

    {
      "servers": {
        "context": {
          "type": "stdio",
          "command": "context",
          "args": ["serve"]
        }
      }
    }