AI Council and TeaRAGs-MCP: what each one does

In short

AI Council is a platform for development teams, cloud or self-hosted. It parses your repositories into a code graph on its own: stack, structure, dependencies and cycles, calls, data layer, architecture, DDD, patterns, style, code smells and ISO 25010 quality. On top of the graph sits the project knowledge base: decisions, notes, diagrams and changelogs. Each entry is anchored to a place in the code and to a branch, and reaches the agent when it touches that file. Conventions live separately: rules at three scopes (code entities, paths, the whole project) with MUST/SHOULD levels, states, and checks before an edit and against the diff. Around this sit review with publishing to the MR, tickets, tasks, and companies with roles and licensing. Static analysis does not use a model, but without a model that is all you get: review, knowledge review, AI chat and workspaces run through a host worker, a bridge and the vendor's CLI/OAuth. The model lives on the host, not inside the Council stack.

There are two ways to work with Council. On a developer's machine, Claude Code or Codex connects to it via MCP and hooks: project rules arrive with every message, file context on Read/Edit/Bash, and a checklist at the end of the turn. In a workspace, the task runs on a VM in an isolated sysbox container, can live for days, and a person drives it from the web UI: from analysis and diff to commit, push and MR.

TeaRAGs is a local "Codebase Intelligence" MCP server for AI agents. It indexes the repository on the user's machine and answers with a profile of the code across five layers rather than with "similar lines": what it does (semantic and hybrid search over AST chunks in Qdrant), how it connects (call and import graph in DuckDB), how it evolved (git trajectory: churn, bug-fix rate, ownership, age), whether it is laid out well (architecture detectors: stable dependencies, leaks through facades, silent coupling, shotgun surgery, main sequence) and how the project names things (a naming lexicon and verdicts on new names). It has review_changes, a five-section diff review, background auto-update, working-tree delta, and a Claude Code plugin with skills and rules. MIT license.

Of the projects we compared, it is the closest to Council in features: it also builds a graph, reads git history, judges architecture and reviews changes. But it is local and doesn't keep a knowledge base, conventions, a review service that publishes to MRs, tasks or a team model.

1. Understanding the code

2. Knowledge and rules

3. Requirements and tasks

4. Verification and models

5. Platform

Bottom line

Of the projects we compared, TeaRAGs is the closest to Council in features. It also builds a graph, reads git history, judges architecture, checks names and reviews changes. But it is local and doesn't keep what Council keeps on top of the graph: a knowledge base of decisions, authoritative conventions, a review service that publishes to MRs, tasks on a VM, and a team with permissions.

Where TeaRAGs is stronger:

• five layers in one local server, where the value is in the combination rather than the count: semantics, codegraph, git, architecture, lexicon (each is a pragmatic signal, not necessarily best in class);
• architecture detectors that Council doesn't have in explicit form: an SDP check, silent coupling, shotgun surgery as a separate metric, role-pair norms and a what-if restructure. Council has Martin's metrics (instability, abstractness, distance from the main sequence), detectors for cycles, layer violations, god/hub components and scattered_functionality by co-change, but not these specific detectors, and it doesn't recompute metrics on a virtual graph;
• review_changes: diff-scoped detectors, preExisting, remedy, the introduced=0, partial=false gate;
• the naming lexicon and ontology report: verdicts on new names that neither types nor tests catch;
• temporal co-change with a null hypothesis and multiple-comparison correction;
• working-tree reads from the base index plus a delta, without re-indexing;
• SearchConfidence, presets and a reranker;
• a compact surface for the agent: 28 MCP tools, 9 resources (two for Qdrant collections and seven tea-rags://schema/* references), prime with live index state at session start, and search cascade as a tool selection policy. Council has 61 tools and broader coverage, but no MCP resources and no separate prime digest: its reference lives in tool schemas, a skill and hooks, and "knowledge base first, then code" is enforced by the gate;
• MIT, fully local, Ollama by default.

Where Council is stronger:

• Knowledge anchored to code and branches, not just to an index. An entry lives on a branch, reaches the agent when it touches the file, and goes back for re-checking when the code under it changes; the reviewer must provide a quote, the outcome is a label, and entries move on branch merge. TeaRAGs builds an architecture report and a lexicon, but has no knowledge base of decisions and rationale.
• Conventions are authoritative rules, not observed norms. Three scopes (entities; paths, including files that don't exist yet; project), MUST/SHOULD, draft/retired/deleted states, checks before an edit and against the diff. Hooks deliver rules with every message and file context on Read/Edit/Bash; the KB gate blocks reading code until the agent has queried the knowledge base. TeaRAGs' role-pair norms and lexicon are observed, and you can't edit them as rules.
• Code and knowledge review as a service, not a local gate. A verdict for every file, a second pass, publishing to the MR without duplicates (GitHub/GitLab/Bitbucket). A separate knowledge review checks a claim against its AST position, requires a verbatim quote, and keeps a log and calibration. TeaRAGs' review_changes is a deterministic pre-commit gate in one repository, with no MR and no knowledge.
• Tasks on a VM, tickets, MRs, team. A task in a sysbox container lives for days and a person drives it from the UI: analysis, diff, commit, push, MR. Jira/GitHub/Redmine tickets parsed into knowledge; companies, members, roles (including per project), permissions, license and seats. TeaRAGs is a local single-user server without tasks, roles or licensing.
• Broader quality and history layers. DDD bounded contexts, patterns, style, code smells, ISO 25010, SonarQube, architecture_as_of and versioned edges. TeaRAGs is stronger on specific architecture detectors (SDP, silent coupling, shotgun surgery, norms, what-if), but not on these layers.
• Shared graph across repositories. One project can include several repositories with a shared graph; ask_question returns excerpts with FQNs, not a model's paraphrase. TeaRAGs keeps a project registry with one collection per project and no shared graph across repositories.
• Platform observability and self-healing. Telemetry for every MCP call and hook without PII, repeated agent searches as a signal, about 22 Prometheus rules, System Health, tracing; Temporal reconciliation, orphaned data cleanup, backups with restore checks, retention. TeaRAGs has drift monitors and get_index_metrics, but not per-call observability or platform self-healing.
• The model isn't a key inside the stack. Static analysis runs without a model; review, knowledge review, AI chat and workspaces go through the host worker, bridge and vendor CLI/OAuth. TeaRAGs uses local Ollama embeddings and deterministic review, which is a real strength for running locally. Deep model-based review with publishing to MRs is Council's axis.

Can they work together? Yes, they are different layers. TeaRAGs provides a local profile of the code and a deterministic pre-commit gate; Council provides knowledge, rules, model-based review with publishing to MRs, tasks and team features. Both are MCP servers, and one agent can connect to both. They overlap on architecture and review: TeaRAGs judges introduced edges and names deterministically, Council reviews the change with a model and publishes findings. A sensible setup: TeaRAGs as a fast pre-commit filter, Council for deep review and knowledge. There is no built-in integration.