Introduction

I outlined a setup using Serena MCP to connect Obsidian instructions to local LLM or GitHub Copilot completion and agent execution in VS Code.

The goals are repository-aware completion, fewer hallucinations, and keeping code local. This article describes a proposal and examples.

Background and Goal

The original note states the goals:

  • serena MCPでlocal LLM、github copilotの精度を向上させる
  • obsidianをベースにserenaでinstructionsを生成、ローカルLLMもしくはGithub copilotをベースにしてオートコンプリート、エージェントを活用できるようにローカルマシンに構築する。VSCODEでも利用する

The proposed flow passes Obsidian instructions and repository context to completion and execution tools. It covers both local LLMs and GitHub Copilot.

Serena MCP: Enhancing Local LLM and GitHub Copilot Accuracy

Serena MCP would read code, comments, and documentation to give the model project-specific context.

The candidates are Qwen-Coder-v3, Gemma-3, and an Ollama-hosted model. The design leaves the model replaceable.

Key Features

FeatureWhat It DoesPractical Example
Local LLM Fine-TuningTrains a model on your repository’s code, comments, and documentation.A Python project with 10k lines of code gets a model that understands project-specific naming conventions.
GitHub Copilot Accuracy BoostUses the fine-tuned model as a secondary suggestion engine, filtering Copilot’s output.Copilot suggests a generic def foo(): but Serena MCP replaces it with def calculate_total_price(items): after matching repository patterns.
Obsidian-Based Instruction GenerationGenerates Markdown instructions that guide the LLM or Copilot.An Obsidian note titled “Add unit tests” automatically creates a prompt: “Write pytest tests for calculate_total_price.”
Auto-Complete & Agent IntegrationProvides context-aware auto-completion and a lightweight agent that can execute code snippets.While typing in VS Code, Serena MCP completes df. to df.groupby() based on pandas usage in the repo.
VS Code ExtensionInstalls a side-panel that displays Serena-generated instructions and suggestions.A developer sees a “Suggested refactor” button that, when clicked, runs the agent to rename variables.

The table lists intended features and examples. Obsidian-Based Instruction Generation connects planning to Auto-Complete & Agent Integration.

How It Works

The proposed flow has five stages. Training values and execution examples below illustrate the proposal; they are not measured results.

  1. Repository Analysis: scan code, comments, and documentation and build a knowledge graph of function signatures, class hierarchies, and common patterns.

  2. Fine-Tuning: train a local LLM on the extracted data. The note gives an example of Qwen-Coder-v3 trained for 4 epochs on a 16-GB GPU, reducing test-set perplexity from 35 to 22.

  3. Instruction Generation: In Obsidian, a user writes a high-level goal: “Implement pagination for the API.” Serena MCP translates this into a detailed prompt:

      ## Task: Add pagination to the API endpoint `/items`
- Use FastAPI
- Return 20 items per page
- Include `next_page` and `prev_page` links

  4. Auto-Complete & Agent: When the developer types return inside the endpoint function, Serena MCP’s auto-complete suggests return paginate_items(items, page, per_page=20). The agent can execute a test harness:

      $ serena agent run tests/test_pagination.py
PASS

  5. VS Code Integration: show instructions, code suggestions, agent status, and access to the local inference API in a sidebar.

High-level Obsidian instructions would guide the detailed prompts and agent actions.

Benefits

BenefitWhy It Matters
Higher AccuracyFine-tuned models reduce irrelevant suggestions by 30-40% compared to vanilla Copilot.
PrivacyAll inference happens locally; no code leaves the machine.
SpeedLocal inference delivers sub-second responses, even on modest hardware.
CustomizabilityUsers can swap LLMs (Qwen-Coder-v3, Gemma-3, Ollama) without changing the workflow.
Unified InterfaceObsidian for planning, VS Code for coding, Serena for execution – all in one ecosystem.

The table lists expected benefits. Privacy and Unified Interface matter most to me: keeping code local and connecting planning to implementation.

Example setup commands 

  # 1. Install Serena MCP
pip install serena-mcp

# 2. Initialize your project
serena init

# 3. Choose an LLM
serena llm install qwen-coder-v3

# 4. Fine-tune
serena llm fine-tune

# 5. Install VS Code extension
code --install-extension serena.mcp

# 6. Open Obsidian, create an instruction note, and sync

Related notes propose a broader development platform for LLM integration.

  • Reproducibility and Evidence: MLflow, SBOM, signing, and Feast for preserving how outputs were produced
  • Data and Retrieval Foundation: Trino, Iceberg, lakeFS/Nessie/Polaris, Qdrant, and pgvector for broader cross-document search
  • Observability and Runtime: Prometheus/Grafana/Loki with OpenTelemetry, and Podman Quadlets as the practical runtime path with k3s as a future expansion
  • Development Productivity: Devcontainer, pre-commit, Devbox/Nix flakes, and Playwright/k6 for reproducible environments

What Is Still Missing

Several implementation details remain open.

The proposal has no concrete Serena MCP config, editor settings, or Obsidian-to-VS Code synchronization details. The example commands alone are not a reproducible setup.

I would separate the minimal setup from the extensions:

  • A minimal setup: Serena MCP + local LLM + Obsidian + VS Code
  • An extended setup: Podman, MLflow, Qdrant, Trino, Iceberg, and observability

The proposed workflow

The note connects repository analysis, fine-tuning, instruction generation, autocomplete, agent execution, and VS Code integration in one proposed workflow. It is a design to test in a small implementation.

Future Work

Next I would implement Serena MCP configuration, Obsidian instruction-generation rules, and VS Code loading, then separate how the local LLM and GitHub Copilot use them.

After that, I would add only the necessary Podman, MLflow, Qdrant, and observability components.