>> mq-mcp
MCP stands for Model Context Protocol. It is a standard for connecting AI models to local tools — a way of giving a language model a set of capabilities that live on your own machine, not in some cloud API you cannot inspect.
mq-mcp started as a question: what does a personal AI infrastructure look like when everything runs locally? Not as a self-hosted LLM experiment, but as a proper bridge — a small, documented, validated server that exposes your machine to an AI model in a way you can read, reason about, and control.
The server exposes 18 tools. They cover the basics you actually need: reading and searching files within the repository, checking git status and diffs, analyzing CSV files, running a local validation script. But also things that are more specific — opening registered repositories in a new terminal window, running repo-signal health checks across multiple codebases, inspecting Guitar Pro files. Every tool is classified by scope and access type in a safety document that the server can expose as a read-only tool call.
The bridge layer connects the MCP server to OpenAI. You write a prompt in the terminal. The bridge forwards it, the model selects the appropriate tool, the tool runs locally, the result comes back, and the model synthesises a response. The whole loop is visible — you can see every tool call in the output.
Bridget is the name for this local presence.
She has a face, a voice, and a consistent system prompt.
The face is an image rendered in the terminal via chafa.
The voice uses macOS say — Swedish, Alva, off by default.
When you ask her who she is, she answers in character.
When you tell her to navigate to a repo, she does it in the current shell.
The goto system is a small piece of engineering that solved a real friction point.
A child process cannot change the parent shell's working directory.
The solution: the bridge outputs a CD: signal,
a shell function intercepts it, and runs cd in the current process.
No new terminal windows. No clipboard. No delay.
Type bridget gå till macos-scripts and the shell moves.
The validation gate is what makes the project maintainable.
A script reads the server source with Python's AST parser,
detects every @mcp.tool() function dynamically,
and checks that each one is documented in the safety map and the README.
Add a tool and forget to document it — the gate breaks.
The discipline is enforced, not remembered.
Local first. No telemetry. Nothing leaves the machine without a visible API call. That is the constraint that makes the project coherent.