Сервер MCP, предоставляющий агента ИИ Frama-C: EVA абстрактная интерпретация, WP дедуктивная доказательство, инъекция аннотации ACSL и изолированные песочницы для пробных аннотаций Вон.

Сервер предназначен для управления агентом, а не человеком. MCP Клиент испаряет его и говорит с ним через stdio, поэтому нет команды для человека. печатать. Она построена вокруг итеративной петли: предложить аннотацию, доказать ее, Читайте, почему гол не закрыли, затем пересматривайте. Состояние сессии вытекает из Эта петля, а не от использования оболочки, так как один проект остается загруженным через звонки, песочницы адресованы по имени, а квитанции с доказательствами сравниваются только внутри пробежку.

Проводите его в Claude Code, Claude Desktop или любой MCP-клиент. Английский. Подключите агента и Быстрые модели. check Субкоманда существует для CI и является Единственная часть предназначена для управления вручную.

Архитектура

Сервер имеет два необходимых компонента:

Rust MCP сервер: разоблачает инструменты через MCP stdio, переводит запросы Серверный протокол Frama-C и лениво запускает основной процесс Frama-C на сервере. Первая проектная операция.

• [[Т1]] Плагин Frama-C: предоставляет пользовательские запросы для доступа к AST,

frama-c-mcp

An MCP server that gives an AI agent Frama-C: EVA abstract interpretation, WP deductive proof, ACSL annotation injection, and isolated sandboxes for trying annotations out.

The server is designed to be driven by an agent rather than by a person. An MCP client spawns it and speaks to it over stdio, so there is no command for a human to type. It is built around an iterative loop: propose an annotation, prove it, read why the goal did not close, then revise. The session state follows from that loop rather than from shell use, since one project stays loaded across calls, sandboxes are addressed by name, and proof receipts compare only within a run.

Wire it into Claude Code, Claude Desktop, or any MCP client, then prompt in English. See Connect an agent and Prompt patterns. A check subcommand exists for CI and is the only part intended to be run by hand.

Architecture

┌──────────┐  MCP over stdio   ┌────────────────┐  Unix socket  ┌─────────────────┐
│ AI agent │◄─────────────────►│ frama-c-mcp    │◄─────────────►│ Frama-C main    │
└──────────┘                   │ Rust server    │               │ + ast-utils     │
                               └───────┬────────┘               └─────────────────┘
                                       │ Unix socket per sandbox
                                       ▼
                               ┌──────────────────┐
                               │ Frama-C sandbox  │
                               │ + ast-utils      │
                               │  per experiment  │
                               └──────────────────┘

The server has two required components:

• Rust MCP server: exposes the tools over MCP stdio, translates requests into Frama-C’s server protocol, and lazily starts the main Frama-C process on the first project operation.
• ast-utils Frama-C plugin: provides the custom requests for AST access, dependency extraction, ACSL injection, sandboxing, and WP configuration. Build and install it in the same opam switch as Frama-C.

create_sandbox extracts a function together with its type, callee, and global dependencies into a temporary C file, then starts a separate Frama-C process. An agent can iterate on annotations there without mutating the main project; verified sandbox annotations are merged back explicitly.

Session model

The server holds one project: reload_project or the first check loads it, and later calls operate on that AST. Sandboxes are separate processes, addressed as experiment_id:function.

The preprocessor surface is nostdinc, include_paths, isystem_paths, defines, force_includes, and machdep, applied in that order. Each value is written without its compiler flag. nostdinc drops the preprocessor’s default system directories and isystem_paths are searched after include_paths; pair