I've been using Claude Code on a business task (~150 functions) and kept hitting the same problem: the agent would confidently refactor a function called from 12 places, or or merge code into files I'd rather keep untouched.

So I built Winkers — a tree-sitter based MCP server that gives the agent a structured project map in one call before it writes anything. map() → zones, hotspot functions, constraints (~500 tokens). Optional semantic layer (one Claude API call) adds business constraints and conventions that aren't visible from code structure alone — the "why" behind the architecture.

Early results are encouraging: 1. Haiku + map ≈ Sonnet without map, at 2-3x lower cost. The graph compensates for the weaker model's lack of exploration. 2. More context ≠ better results. Forcing the full function list (~9K tokens) performed worse than the focused map (~500 tokens). Constraints got lost in noise. 3. The real design problem isn't building the graph — it's finding the right balance between MCP strictness and agent autonomy.

There are several code graph MCP servers already (CodeGraphContext, codebase-memory-mcp). What I think is missing across all tools is the steering layer: how much context to give, when to give it, and when to let the agent figure things out on its own.

That balance determines two things: whether the code agents produce actually holds up over time, or quietly turns into a patchwork of brittle fixes that pass tests but resist any change.

I've been using Claude Code on a business task (~150 functions) and kept hitting the same problem: the agent would confidently refactor a function called from 12 places, or merge code into files I'd rather keep untouched.

So I built Winkers — a tree-sitter based MCP server that gives the agent a structured project map in one call before it writes anything. map() → zones, hotspot functions, constraints (~500 tokens). Optional semantic layer (one Claude API call) adds business constraints and conventions that aren't visible from code structure alone — the "why" behind the architecture.

Early results are encouraging: 1. Haiku + map ≈ Sonnet without map, at 2-3x lower cost. The graph compensates for the weaker model's lack of exploration. 2. More context ≠ better results. Forcing the full function list (~9K tokens) performed worse than the focused map (~500 tokens). Constraints got lost in noise. 3. The real design problem isn't building the graph — it's finding the right balance between MCP strictness and agent autonomy.

There are several code graph MCP servers already (CodeGraphContext, codebase-memory-mcp).

To be clear — Winkers doesn't compete with CodeGraphContext or codebase-memory-mcp. What I think is missing across all tools is the steering layer: how much context to give, when to give it, and when to let the agent figure things out on its own. That balance determines two things: whether the code agents produce actually holds up over time, or quietly turns into a patchwork of brittle fixes that pass tests but resist any change.