Tool System

Design Philosophy

Each tool is entirely self-contained: configuration, schema, and implementation live in one file. No separate config needed. Drop the file in the right folder, restart the process, and the tool auto-registers on startup.

Dynamic Loading

Only three essential tools stay permanently loaded:

• web_tool
• invokeother_tool
• getcontext_tool

All other tools exist as one-line hints in working memory (tool name plus a simple description). When MIRA needs a capability, it calls invokeother_tool to load the full definition on demand.

Token Efficiency

With roughly 15 available tools at 150-400 tokens each, that's 2,250-6,000 tokens not wasted per turn when tools aren't needed.

Loaded tools auto-unload after 5 turns unused (configurable via idle_threshold). There's also a fallback mode that loads everything for one turn if MIRA gets stuck.

Available Tools

Extensibility

Adding a new tool is straightforward:

1. Give Claude Code (or your editor) context about what you want
2. Drop the new tool file in tools/implementations/
3. Restart the MIRA process
4. The tool auto-registers on startup

There's a HOW_TO_BUILD_A_TOOL.md guide in the repo written specifically to give an LLM the context needed to zero-shot a working tool.

Tool Data Storage

Tools can store their own data using the self.user_data_path property, which provides a user-specific directory. For simple data, use JSON. For complex data, SQLite. Or use self.db for the main database.

User isolation is handled at the architecture level, not in individual tool code.