MCP Use Cases: When an MCP Tool Earns Its Place

Most lists of MCP use cases read like a shopping list of connected apps. An agent needs a specific thing it cannot get on its own, so the useful question is whether a file in its working directory could hold it.

Is an MCP use case just a list of integrations?

No. A use case starts with a need; an app name only points to where that need might be met. Before attaching an app, check what the agent can already read. A repository sits in its working directory, with source files, config and test output in reach without a server.

For example, an agent might need a value from a committed config file. If a server reads that file and returns the same text, the agent gains an extra process and schema but learns nothing the file would not have told it.

That changes when the record lives outside one agent’s directory and a second agent must see an update later. The same app can pass or fail this test: a server helps with a shared record, but adds noise when it only fronts files the agent can open.

Why not give an agent a tool for every need?

Because every extra tool is another choice the agent can get wrong. Typed calls let it state an action outright instead of guessing at shell commands. But each tool also puts a name, description, input schema and code path in front of the model, which must choose among them whenever it acts.

That choice gets harder when tools overlap. A generic file reader and a config reader can return the same file, so the number of choices grows while the information stays the same. One duplicate is tolerable. A pile of near-duplicates turns selection into guesswork.

An MCP tool earns its place when the agent needs something its working directory cannot hold, such as state shared with other agents or a way to reach a person. If the answer sits in a workspace file, keep the file. If a short command produces it, keep the command. That is the test. Only then does a tool have work to do.

Which two needs pass that test?

Shared state and a way to reach a person pass it. AuricIDE serves both through one MCP server called auric-pm, which runs as a child process on stdio. No port. No listener to configure.

Shared project state

That server gives agents a shared record. A file in one agent’s directory cannot serve that role when the next agent works from a different directory and the app needs the same data too. AuricIDE keeps goals, tickets, requirements, test cases, dependencies and history in one SQLite file in the project directory. Every agent CLI that reads the project’s .mcp.json reaches that file through the same server.

complete_task shows what the shared record is for. It marks a ticket done and, when the agent passes a summary, appends that summary to the ticket’s description. The status change lands in the ticket’s history with the source mcp. An agent dispatched later to a dependent ticket can read the summary there instead of digging through a terminal that has scrolled on.

The notes on an MCP memory server cover the wider pattern; this record stays local.

A way to reach a person

The second need appears when a person is not watching the terminal. Take another design case: an agent finishes its part overnight and finds a requirement it cannot resolve. A file cannot ring a doorbell. It works only if someone opens it.

The notify tool writes to an inbox for the whole app, so the message arrives whichever project the person has open. It also survives a restart. A warn or error severity also raises an OS banner while the window is in the background. The tool asks for one line. Detail is optional. A sentence or two at most.

When the agent needs an answer, notify_ask returns an id at once without blocking. The agent can keep working on anything that does not depend on the reply, then read it with notify_answer_get, which reports pending, answered, expired or gone. A later run can pick up the answer if the person reaches the inbox the next morning.

That inbox is kept apart from the project database so it can span projects. A notification can point at a ticket, goal, agent or file through its reference fields, while the full story stays in the shared record. The inbox also determines whether its tools appear. Without a path to it, the server leaves the notify tools out of the tool list instead of registering stubs that do nothing. An agent that sees notify can trust that it reaches someone. If the inbox is unreachable at start, the server logs a warning to stderr, and the project tools keep running.

What does a shared tool cost?

The cost is small. It is a local process and a project directory. Every agent CLI has to start the server, and .mcp.json has to point at the right database. The data sits beside the checkout. Nothing is hosted. On first run, AuricIDE writes a .gitignore into the .auric/ folder so the whole folder stays out of git.

That keeps code and context on the machine, but a clone does not bring the project history along. Moving the file to another machine is a manual step. Nothing merges diverged copies. No single board spans several machines. A single developer on a small project may gain little from either need, so skipping the server can be the right call.

Stdio has another trade-off. There is no auth layer. Any process running under the same user account can call every tool. Which agent may call which tool still needs thought; the agent access control notes cover that wider question.

Should a file be checked before a tool is added?

Yes. Source files, test output, git status and Markdown notes cover what one agent needs inside one session, as long as nobody else has to know. If a file or short command supplies the answer, a server adds a schema and process without helping the next reader.

The question is where the answer must live tomorrow: outside one agent’s directory, or where a person will hear about it. Those cases need a shared tool. The MCP server setup guide covers setup for cases that pass this check, and AuricIDE serves the coordination case.