Itamos MCP Tools

Four tools, plus a sandboxed git, that let an AI agent see and change code the way an engineer does: a map of the project, named parts of every file, and checks before anything is saved. Try them free in a private sandbox, with no account and nothing to install.

Select any part of the diagram for its own page: how it works, which components it depends on and everything it can do.

The problem

AI coding agents fail less from a lack of intelligence than from a lack of perception. Codebases outgrow context windows, so agents search, open whole files and edit text they have only half read. That costs tokens, causes blind edits and broken files, and leaves the agent without a map of how files connect.

Design principles

• Structure before text. The agent sees the map first, then zooms in.
• Coordinates, not line numbers. Folders, files and the parts inside them have short coordinates such as d.a.f.31.17 that stay valid when other parts of a file change.
• Read before write. A tool will not change code the model has not displayed since the last change.
• Checked before saved. Every save is verified first: broken syntax or configuration never reaches disk, and missing connections are saved but reported.
• Few tools, one door. The agent reads and edits through read_file and creates through write_file; the project map works behind them. Few, predictable tools are easier for a model to use correctly.
• The smallest useful answer. Every response is the least text that answers the question, with a way to ask for more.

How the tools work together

A typical bug fix: the agent clones the repository, which is scanned on arrival, opens the project structure, opens the file named in the error by its coordinate, reads that one function, replaces it and saves. If the save fails its checks, it gets the exact error and line and tries again; the broken version never touches disk.

Evidence so far

• In live use with Claude models (Opus and Sonnet), agents use the tools to navigate and change real codebases end to end.
• Locally run open models of 27 to 31 billion parameters found the right file and function in an unfamiliar codebase, but did not complete the fix without guidance. Good tools help; model capability still matters.
• Token savings: at least 97% fewer tokens than the usual shell workflow (grep, cat, run_cmd), measured against the best case where the model fixes the bug in one attempt. Real sessions save more, because the failed attempts common with raw shell access are not counted.
• Test it yourself: try the tools free in the hosted sandbox with your own model and repository, then post your results in Discussions: model, task, tokens, time.
• Found a bug? Open an issue with the steps to reproduce it. Every report makes the tools better.

Limitations and roadmap

• Alpha: behavior and limits may change.
• Temporary by design: sandboxes are emptied after 10 minutes of inactivity.
• No push: results stay inside the sandbox.
• In progress: fs engine. A filesystem engine that works alongside the existing tools and handles project structure on disk automatically: each new file is placed where it belongs in its project, so folders stay organised and the mess never builds up.
• Planned: anonymous usage statistics.

License and contact

Dual licensed. Free under AGPL-3.0: use, modify and share, with source published for modified versions, including network use. Building it into a closed product? A commercial licence removes the AGPL obligations. Contact info@itamos-technologia.com.

Designed and built by Konstantinos Karamperis, founder of Itamos Technologia in Pili, Trikala, Greece: a systems architect with a background in industrial engineering and infrastructure, building AI-native developer tools on AMD hardware with open-source inference stacks. LinkedIn