MCP integration surface
Integration-layer projects for operators asking how assistants should reach real systems. MCP provides the protocol gravity; editor and CLI tools show where those integrations surface. The tradeoff is reach versus governance: useful tool access can become operational risk if connectors are not inspectable.
lane decision read
operator question
How should assistants reach files, APIs, tools, and internal systems without bespoke glue?
decision rule
Use this lane when integration reuse and permission boundaries matter more than a single client experience.
avoid when
Avoid this lane if the team cannot define permissions, audit paths, and failure handling for assistant tool access.
compare by
Compare by connector reuse, permission clarity, client support, and auditability.
tradeoff
Protocol reach can scale quickly, but connector governance and failure modes must keep pace.
ordered operator lane
Curated tools with metrics artifact signals
frontend-only composition
Model Context Protocol
MCPMCP Servermodelcontextprotocol/servers
signal
MCP is worth tracking as integration infrastructure, not as another assistant feature. It turns tool access into a reusable contract question: what can the assistant reach, through which server, with what audit path? The upside is shared connector gravity across clients. The risk is reach without governance: connector sprawl, vague permissions, and teams normalizing tool use before they can inspect failures.
workflow fit
Best for teams standardizing how assistants reach tools, files, APIs, and internal systems.
watch out
Connector reach can outpace governance; inspect permissions, user intent, and failure modes before broad adoption.
Continue
CNTIDE Integrationcontinuedev/continue
signal
Continue is strongest when adoption friction matters more than direct repo operation. It keeps AI in the editor, which helps teams experiment without asking every developer to change their command-line workflow. Compare it against CLI agents when the question is control and reproducibility; compare it against closed editor assistants when provider choice and inspectable configuration matter.
workflow fit
Best for developers who want AI context inside existing VS Code or JetBrains habits without changing the daily workspace.
watch out
Can feel less deterministic than CLI workflows when a team needs command-level reproducibility or repo-wide automation.
Codex CLI
CDXAI Coding CLIopenai/codex
signal
Use Codex CLI as the reference question for CLI-native agents: can the tool turn intent into inspectable patches while keeping git, tests, and review discipline visible? It fits operators who are comfortable letting an agent touch the repo directly. It is weaker when a team needs guided onboarding, centralized policy, or non-technical workflow ownership.
workflow fit
Best for local repository operators who want agent help inside a terminal-first edit, test, and review loop.
watch out
Less friendly for teams that need visual onboarding, centralized task routing, or policy controls before agents touch code.