Source Code Agent Framework

Updated 7 July 2026

Source Code Agent Frameworks are structured systems that transform software repositories into compliant MCP services through systematic analysis, protocol mapping, and tool orchestration.
The framework employs a directed state graph for multi-agent coordination, enabling automated repository ingestion, conversion, and a reliable Run–Review–Fix repair cycle.
Empirical evaluations reveal up to a 17.8× speedup in converting repositories, demonstrating efficiency in producing deployable services with minimal manual intervention.

Searching arXiv for the requested topic and supporting source-code agent framework papers. I’m retrieving the relevant arXiv records for Code2MCP and closely related source-code agent framework papers. A source code agent framework is an agentic software system that treats source repositories as primary operational substrates for analysis, transformation, execution, repair, and deployment. In the case of Code2MCP, the framework is specialized for automated transformation of GitHub repositories into Model Context Protocol (MCP) services, addressing the tool-integration bottleneck often described as the “ $N \times M$ problem”: legacy integration scales as $C_{legacy} = \Theta(N \cdot M)$ , whereas MCP shifts interoperability toward $C_{MCP} = \Theta(N + M)$ by standardizing tool exposure through Tools, Resources, and Prompts over a JSON-RPC 2.0 client–server specification (Ouyang et al., 7 Sep 2025).

1. Definition and problem setting

Within this line of work, a source code agent framework is not merely a code generator or bug-fixing assistant. It is a structured system that ingests repositories, reasons over project layout and dependencies, executes code in controlled environments, and emits auditable artifacts. Code2MCP defines the task formally: given a repository $\mathcal{R}$ , synthesize an MCP service $\mathcal{E}$ comprising a set of tools $\{t_i\}$ with natural-language descriptions and input/output JSON schemas, example-first documentation, a smoke-test harness, and machine-readable summaries, such that $\mathcal{E}$ is protocol-compliant and instantiable, exposes stable high-value functionality suitable for agent composition, and preserves a minimal necessary edits constraint on the original repository (Ouyang et al., 7 Sep 2025).

That formulation distinguishes repository conversion from generic autonomous software engineering. The target is not unconstrained feature work, but a repeatable repository-to-service compilation pipeline. Code2MCP accordingly treats the main obstacle to MCP adoption as a “last-mile” wrapping problem: existing open-source libraries remain difficult to expose as MCP services because manual adapter construction, dependency setup, testing, and documentation are labor-intensive (Ouyang et al., 7 Sep 2025).

A recurrent misconception is that such frameworks primarily rewrite upstream projects. Code2MCP instead states that the edit set $E$ is empty unless contract reconciliation requires a localized adjustment at adapter boundaries, in which case the change must be evidence-backed and fully auditable. This emphasis makes the framework closer to protocol adaptation than repository refactoring (Ouyang et al., 7 Sep 2025).

2. Protocol mapping and service semantics

Code2MCP is anchored in MCP’s server-side semantics. Functions and classes in a repository are mapped to MCP Tools; where appropriate, file outputs or similar artifacts are surfaced as Resources; reusable guidance for multi-step logic can be packaged as Prompts. The generated mcp_service.py registers these entities against MCP’s JSON-RPC 2.0 interface, while adapter.py implements the boundary layer to the original library and normalizes signatures, types, paths, and, for machine-learning libraries, device placement (Ouyang et al., 7 Sep 2025).

This mapping is not purely syntactic. The framework’s analysis stage identifies candidate APIs, modules, functions, entry points, and “high-value” capabilities, then emits analysis.json and a conversion plan $\pi$ . The resulting service is expected to expose stable, high-value functionality suitable for agent composition rather than an indiscriminate export of internal routines (Ouyang et al., 7 Sep 2025).

The protocol perspective is central to the notion of a source code agent framework in this context. By targeting MCP’s three primitives rather than ad hoc wrappers, Code2MCP positions source repositories as latent tool inventories that can be surfaced for any MCP-capable client or LLM. The paper demonstrates such consumption in Claude-Code, and this suggests a shift from repository-centric reuse to protocol-centric reuse, in which adapter generation becomes the decisive systems problem (Ouyang et al., 7 Sep 2025).

3. Multi-agent orchestration and state-graph architecture

Code2MCP is implemented as a directed state graph, influenced by LangGraph. Nodes represent agents or tools, edges encode transitions, and a shared state object functions as a “data bus” that accumulates artifacts, metadata, decisions, error traces, and provenance across stages. This structure enables conditional logic, bounded retries, and an auditable pipeline (Ouyang et al., 7 Sep 2025).

The framework decomposes responsibility across specialized roles rather than relying on a monolithic agent.

Node	Role	Primary outputs
Download	Repository ingestion	workspace, cloned repo
Analysis	Static analysis and planning	`analysis.json`, plan $\pi$
Environment	Environment configuration	isolated environment, smoke-test result
Generate	Service synthesis	`mcp_service.py`, `adapter.py`, `test_mcp_basic.py`
Run	Execution	logs, stdout/stderr, traces $C_{legacy} = \Theta(N \cdot M)$ 0
Review	Diagnosis and repair	minimal edit $C_{legacy} = \Theta(N \cdot M)$ 1
Finalize	Documentation and integration	`README_MCP.md`, `workflow_summary.json`, `diff_report.md`

All agents read and write shared state, including repository metadata, generated code, test logs, environment details, diff provenance, and documentation. The scheduler enforces stage order and bounded retries: failures in Run route to Review, while successful runs route to Finalize (Ouyang et al., 7 Sep 2025).

This architectural style aligns with a broader tendency in source code agent research to decompose scaffolds into explicit control, tool, and resource layers. A source-code taxonomy of 13 coding-agent scaffolds describes control architecture, tool and environment interface, and resource management as the major axes of variation, and identifies five loop primitives—ReAct, generate-test-repair, plan-execute, multi-attempt retry, and tree search—as composable building blocks rather than exclusive agent types (Rombaut, 3 Apr 2026). Code2MCP belongs to this family but instantiates it in a narrowly specified repository-conversion workflow.

4. Execution-grounded conversion and the Run–Review–Fix loop

The core algorithm is a seven-stage state-driven conversion pipeline: clone the repository, analyze it, create an isolated environment via Conda or venv, synthesize MCP artifacts, execute test_mcp_basic.py, review failures if they occur, and finalize by emitting artifacts, logs, a branch such as main_mcp, and a pull request (Ouyang et al., 7 Sep 2025).

Its key innovation is a closed-loop Run–Review–Fix cycle. Detection signals include smoke-test import failures, runtime errors from test_mcp_basic.py, build and installation failures, stack traces, and captured logs $C_{legacy} = \Theta(N \cdot M)$ 2 containing stdout, stderr, and traceback data. The Review node performs root-cause identification for incorrect imports, missing dependencies, API contract mismatches, and path-resolution errors, then proposes a minimal edit $C_{legacy} = \Theta(N \cdot M)$ 3 localized at the adapter boundary. Fix strategies include adjusting import paths from relative to absolute, adding missing dependencies in environment configuration, reconciling function signatures and schema types, correcting resource paths, and improving initialization order. Each change is recorded in diff_report.md as rationale $C_{legacy} = \Theta(N \cdot M)$ 4 evidence $C_{legacy} = \Theta(N \cdot M)$ 5 diff (Ouyang et al., 7 Sep 2025).

The loop is bounded by $C_{legacy} = \Theta(N \cdot M)$ 6 and prioritizes the highest-likelihood root cause inferred from $C_{legacy} = \Theta(N \cdot M)$ 7. Regeneration then re-synthesizes mcp_service.py, adapter.py, tests, and documentation before the next execution attempt. The framework reports that most failures in evaluation were resolved autonomously within one or two iterations (Ouyang et al., 7 Sep 2025).

This execution-first structure closely resembles execution-grounded verification in AgentForge, where every code change must be tested inside an isolated Docker sandbox and only propagates if the tests pass (Kumar et al., 13 Apr 2026). The resemblance is important: it places source code agent frameworks in a class of systems that use runtime behavior, not only prompt-level reasoning, as the dominant supervision signal.

5. Artifacts, repository integration, and empirical evaluation

Code2MCP emits a deployable MCP package together with a documentation and provenance layer. README_MCP.md contains user-facing entry points, tool descriptions, usage examples, environment instructions, and limitations. workflow_summary.json records a machine-readable summary of analysis outputs, service structure, tools, resources, prompts, environment metadata, and test results. diff_report.md preserves an auditable rationale for any edits. Artifacts are emitted under an mcp_output directory, and the system can programmatically commit generated files to a new branch and open a pull request upstream (Ouyang et al., 7 Sep 2025).

Evaluation covers six repositories spanning scientific computing, NLP, image generation, and search indexing: googleresearch/esm, nbiish/calc, TextBlob/TextBlob, dateutil/dateutil, ankane/searchkick, and OlafenwaMoses/ImageAI. Metrics include end-to-end conversion time, LLM token cost per repository, build and smoke-test pass rates, retry counts, pass/fail outcomes, and robustness under self-repair (Ouyang et al., 7 Sep 2025).

The reported summary result is an average automated conversion time of 8.3 minutes versus approximately 2.4 hours manual, corresponding to an approximately 17.8× speedup, with average LLM token consumption of approximately 31.8k tokens per repository as a one-time cost. The paper further states that bounded retries and Run–Review–Fix improved reliability, and that most failures were resolved autonomously within one or two iterations (Ouyang et al., 7 Sep 2025).

Two examples illustrate the framework’s operational character. For facebookresearch/esm, the framework abstracts model loading, tokenization, device management, forward execution, and PDB-file writing behind a single high-level MCP Tool such as predict_structure, with outputs such as pdb_file_path and message; this generated service was validated in Claude-Code. For nbiish/calc, an initial ImportError caused by a relative import in adapter.py was corrected by rewriting from . import utils to from calc import utils, after which regeneration and rerunning succeeded in under 90 seconds (Ouyang et al., 7 Sep 2025).

6. Comparative landscape of source code agent frameworks

Code2MCP is explicitly positioned against task-solving agents such as Devin, SWE-agent/SWE-bench, CodeAct, and AutoGPT variants. Its emphasis is a well-defined engineering pipeline—repository to MCP service conversion—rather than general bug fixing or feature implementation. That specialization makes it representative of one branch of source code agent frameworks: standards-aware repository transformation (Ouyang et al., 7 Sep 2025).

Other branches prioritize different objectives. AutoSafeCoder orchestrates a Coding Agent, a Static Analyzer Agent, and a Fuzzing Agent to reduce vulnerabilities in generated Python code through iterative static auditing and mutation-based fuzzing, reporting a 13% absolute reduction in vulnerability rate relative to baseline GPT-4o outputs on SecurityEval (Nunez et al., 2024). SolAgent specializes further, using a dual-loop refinement mechanism for Solidity in which an inner Forge loop targets functional correctness and an outer Slither loop targets security, reaching Pass@1 up to 64.39% on SolEval+ and reducing vulnerabilities by up to 39.77% compared with human-written baselines (Chen et al., 30 Jan 2026). AgenticTCAD shifts the substrate from software repositories to TCAD scripts, but preserves the source-code-agent pattern of generation, execution, evaluation, and optimization through structured JSON-mediated agents (Fan et al., 26 Dec 2025).

Long-horizon repository work introduces another design axis. The Confucius Code Agent uses a unified orchestrator, hierarchical working memory with adaptive context compression, persistent note-taking, modular extensions, and a meta-agent that refines configurations through a build–test–improve loop; on SWE-Bench-Pro it reaches Resolve@1 of 54.3% under identical repositories, model backend, and tool access (Wang et al., 11 Dec 2025). A broader empirical study of seven general-purpose agent frameworks shows moderate overall effectiveness and strong trade-offs among effectiveness, trajectory length, correction attempts, and token cost, with single-agent systems often outperforming multi-agent systems on repair while multi-agent planning sometimes improves completeness (Yin et al., 2 Nov 2025).

These comparisons indicate that “source code agent framework” is not a single architecture but a family of scaffold designs that differ by task definition, execution regime, tool semantics, and state management. Code2MCP contributes a protocol-centered variant in which source code is treated as convertible infrastructure.

7. Limitations, governance, and future directions

Code2MCP is currently optimized for Python repositories. It handles common Python packaging patterns such as requirements.txt and pyproject.toml, but support beyond Python remains limited; the inclusion of ankane/searchkick in Ruby is described as an initial evaluation case rather than evidence of broad multi-language automation (Ouyang et al., 7 Sep 2025). Very large repositories may exceed current LLM context limits, non-standard project structures complicate analysis and mapping, and environment fragility—especially GPU drivers, CUDA versions, or system-library dependencies—can stall the loop. Interactive applications, networked services with side effects, and secrets-dependent code require more sophisticated sandboxing and permission models. Licensing constraints and unsafe functionality exposure are also identified as open risks (Ouyang et al., 7 Sep 2025).

These limitations connect Code2MCP to a broader governance agenda in source code agent systems. ContextCov converts natural-language agent instruction files such as AGENTS.md into executable checks across process, source, and architecture, synthesizing 46,316 checks across 723 repositories with 99.997% syntax validity for executable checks (Sharma, 28 Feb 2026). AgentFlow statically reconstructs framework-induced semantics into an Agent Dependency Graph whose typed nodes include agents, prompts, models, capabilities, memory states, and control policies, enabling Agent BOM generation and prompt-to-tool risk detection; across 5,399 real-world agent programs it uncovers 238 projects with prompt-to-tool risks (Wang et al., 2 Jul 2026). ClawAudit, focused on local LLM agent runtimes, derives a five-category taxonomy from STRIDE and raises held-out recall from 21.7% to 66.8% for Semgrep and from 13.8% to 75.1% for CodeQL on OpenClawBench, albeit with low precision in preliminary live-code auditing (Zhang et al., 19 Jun 2026).

A plausible implication is that repository-conversion frameworks such as Code2MCP will increasingly be evaluated not only by conversion speed or tool usability, but by auditable state management, policy enforcement, security posture, and reproducibility. In that respect, Code2MCP already exhibits several traits that later work treats as defining features of powerful source code agent frameworks: standards-aware conversion, structured orchestration, environment isolation, minimal adapter-boundary edits, autonomous repair, and developer-facing documentation and pull-request integration (Ouyang et al., 7 Sep 2025).