MAPI-local-medium: a local MCP server that gives a model memory, tools, and boundaries

MAPI-local-medium is a local MCP server. Its job is simple: sit between the language model and the user's work environment. The model does not get direct access to the computer, files, or a database. It gets a list of tools exposed by the server through MCP.

Every tool use goes through a defined interface. That distinction matters. We are not saying: "AI has access to my computer." We are saying: "AI can perform a few explicit operations within a limited scope."

ChatGPT / MCP client
        |
        | MCP / JSON-RPC
        v
MAPI-local-medium
        |
        +-- project memory
        +-- memory search
        +-- create new entries
        +-- read specific entries
        +-- links between entries
        +-- project timeline
        +-- controlled work operations

A normal chatbot lives mostly inside one conversation. As long as the context stays in the chat window, things somehow work. When the conversation ends, you are back to manual notes, copied decisions, and the classic: "I know I wrote this somewhere before."

An MCP server changes that arrangement. The model can use an external work environment. It can ask about earlier decisions, read the current project state, save the result of its work, and return to it in the next session.

That does not turn the model into a self-sufficient engineer. But it turns it into something far more useful than a standalone text generator: an assistant working against the state of a project.

The most important part of MAPI-local-medium is project memory. This is not memory of the "the user likes coffee" kind. It is technical memory: decisions, statuses, test results, risks, implementation context, and things that require later revalidation.

That allows the model to ask more specific questions than just "what do you remember?": what was the last decision, does this feature already exist, what was tested, what conflicts with something else, and what still needs revalidation.

MAPI-local-medium exposes a simple set of memory tools to the model. Together they form a practical agent loop: check context, do the task, save the result.

find_memories       - searches memory entries
get_memory          - fetches a specific entry by ID
get_memory_links    - shows connections for a given entry
create_memory       - stores a new entry
recall_memory       - recalls an entry as relevant context

It is a small set, but enough for a surprisingly large number of tasks. Good agent infrastructure does not need to look like a spaceship cockpit. It should be predictable, testable, and useful.

A model should not begin by guessing. That is why session bootstrap matters: the first call returns the basic working context, active project, operating rules, available tools, and hints about where to look next.

1. Restore the session context.
2. Check available tool areas.
3. Search for the needed memory entries.
4. Only then perform the task.

A memory store by itself is not enough if the model does not know it should use it. Without bootstrap, memory is a library without a catalog. The knowledge is there, but using it turns into archaeology with a weak flashlight.

One common mistake when building agents is exposing too many tools at once. In theory it sounds great: give the model everything. In practice you get a tool monster.

A better pattern is a small list of core tools plus logical work areas. The model does not need the entire dashboard at once. First it chooses the area, then the action.

restore / bootstrap context
find_memories
get_memory
get_memory_links
create_memory
recall_memory
open_workshop
run_workshop_action

More advanced functions can sit behind workshops: memory, timeline, conflicts, memory quality, semantic search, files, or administration. That reduces chaos and makes access control easier.

Beyond plain memory entries, a project timeline is useful. This is not just a technical log. A log says: "an operation was executed." A timeline says: "something meaningful happened in the project."

Links between entries do the second part of the job. One entry can support another, conflict with it, document an implementation, or describe a fix. That means memory stops being a flat list of notes. It starts working like a project knowledge graph.

MAPI-local-medium can be extended with file or workspace operations, but that should be done carefully. A good rule is: the model may act only inside a defined directory and only through described tools.

The model can read and write only in a defined working directory.
It should not have access to the whole disk.
It should not see secrets.
Risky operations are hidden or available only in an admin profile.
Read first, write second.

That is the difference between "AI has access to my computer" and "AI can use a few safe tools inside a specific directory." The first sounds like the beginning of a security incident. The second sounds like engineering.

Not every client and not every mode of work should see the same tools. One set makes sense for a simple user, another for an operator, and another for an administrator.

basic:
- memory search
- read entries
- create entries

operator:
- timeline
- conflicts
- memory quality
- linking

admin:
- files
- SQL
- migrations
- diagnostic tools

An agent does not need the keys to the whole kingdom. It needs the right key for the right door. This fits well with the earlier article on the MCP semi-agent.

Once connected to such a server, the model can work in a repeatable loop. The point is not that the model "knows everything by itself." The point is that it has a procedure, tools, and durable context.

1. The MCP client connects to the local server.
2. The model bootstraps context.
3. The model searches relevant memory entries.
4. It fetches details and links if needed.
5. It performs the task.
6. It saves the important result as a new memory entry.
7. Significant events are written to the timeline.

Without MCP, a model responds from the chat. With MCP and memory, it can work against the state of the project. That is a practical difference, not marketing glitter.

Even a simple local MCP server lets you build an agent that can remember project decisions, check whether something was already done, save work results, read earlier agreements, and organize documentation.

That still does not replace an engineer, tester, or operator. But it changes the way you work with the model. Instead of one conversation, you get a work environment.

You do not need a huge platform at the start. A minimal version can include a local MCP server, SQLite or a simple file-backed store, tools for searching and storing memory, session bootstrap, and limited access to the working directory.

Only later is it worth adding semantic search, memory freshness status, revalidation, conflicts, a relation graph, automatic memory cleanup, and quality reports.

The biggest mistake is starting with architecture that is too large. The second biggest is giving the model too many tools. The third is confusing memory with a pile of random notes.

MAPI-local-medium gives the model three things:

memory,
tools,
boundaries.

Memory lets it return to earlier decisions. Tools let it do more than write answers. Boundaries keep the whole system from turning into a drunk admin-level sprite.

That is the core of a practical AI agent: not one magic prompt, but a small, well-described workshop where the model has access to context, performs concrete operations, and knows where its permissions end.

You can read more on the MAPI-local-medium page, and find the code in the repository at github.com/cabo0m/MAPI-local-medium.