| FMRS | 60 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 10 / 20 | 12 / 20 |
|---|
| Security and permissions | 9 / 20 | 18 / 20 |
|---|
| Maintenance | 12 / 20 | 16 / 20 |
|---|
| Documentation | 16 / 20 | 18 / 20 |
|---|
| Setup experience | 13 / 20 | 15 / 20 |
|---|
| Best for | - 1C:Enterprise projects with CF, EDT, or MDO source formats
- Large configurations with 20K+ files that cannot fit into a single session context
- Deterministic codebase questions, e.g. finding an HTTP service and its methods or how a document posting routine works
- Teams that want to save context and tokens and avoid maintaining RAG infrastructure
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Scenarios needing a complete dependency graph of all configuration objects (requires a pre-indexed RAG/graph MCP)
- Semantic/embedding search over object descriptions
- Vague, non-deterministic questions like 'how does budgeting work in ERP' or 'how do cellular warehouses work in UT', which need full RAG or a strong model to turn them into strict queries
- Treating it as an official 1C product: it is not maintained by 1C
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Read 1C source directories (BSL files, XML/MDO descriptions, metadata)
- Write and manage SQLite index files on the host
- Read and modify the projects.json registry next to the server directory (mutating operations require a password)
- Execute agent-submitted Python scripts inside a sandbox
- Optional access to an LLM endpoint (OpenAI-compatible OpenRouter, Ollama, vLLM, or the Anthropic API), only when llm_query is configured
- Optional use of Git on the host to read the source repository (enables git_search)
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - Agent-submitted Python scripts are executed in a sandbox whose real strength determines the host's exposure surface
- A .git directory in the sources automatically enables git grep full-text search over all files, which may surface 'raw' XML/MDO and text content developers did not expect to expose
- When llm_query is configured, script content or code fragments may be sent to an external LLM endpoint
- The registry password protects mutating operations to stop the AI acting without confirmation, but it is not strong encryption or isolation
- Indexing is slow on HDDs or network shares, and indexes persist code content read from disk
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Code, Kilo Code, Roo Code, Cursor | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 6 | 0 |
|---|