Agentic Workflow Automation in .NET with MCP
August 19, 2026 · PanaceaLogics Team
Most agent projects spend their first month on plumbing. Not on prompts, not on the model, but on the same question asked repeatedly: how does this thing reach the invoice system, the document store, the ticket queue?
The Model Context Protocol is a standard answer to that question. It is worth understanding not because it is new, but because it changes what you have to rebuild each time.
The problem MCP is actually solving
Before a protocol existed, every integration was bespoke twice over. You wrote the tool definitions the way one framework expected them, then wrote them again when you moved to a different host or model. Swap the assistant, rewrite the wiring.
MCP puts a defined boundary in the middle. You build a server that exposes capabilities, and any compliant client can use it. The server is a normal piece of software you own, deploy and version. What talks to it becomes a detail rather than an architectural commitment.
For a .NET estate that matters more than it sounds. Your integration work stops being tied to whichever AI product you happened to start with.
What a server exposes
Three things, and the distinction is worth getting right early:
- Tools are actions. Create a ticket, post a journal entry, trigger a rebuild. These change something and need the same care as any write endpoint.
- Resources are readable context. A document, a record, a query result. Retrieval rather than action.
- Prompts are reusable instruction templates the host can offer to a user.
Teams tend to make everything a tool. Splitting reads out as resources makes the permission story clearer and stops the model treating a lookup as an action with consequences.
In .NET, a server is mostly code you already have
This is the part worth internalising: an MCP server over a .NET estate is usually a thin layer over existing services. The business logic is written. What you are adding is a description of it that a model can reason about, plus the boundary that keeps it honest.
Which means the quality of your existing code decides the quality of the server. Well-named services with clear inputs expose cleanly. A god class with fifteen optional parameters does not.
Two rules carry over from building production agents in .NET, and they matter more here because a server may be reachable by more than one client:
Narrow beats flexible. GetOverdueInvoices(accountNumber) behaves predictably. A general query tool invites the model to construct requests nobody anticipated.
Descriptions are the interface. The text describing a tool is what the model reasons over. Vague or overlapping descriptions produce wrong tool selection, which looks like a model problem and almost never is.
Authorization does not come for free
A protocol standardises how a client talks to your server. It does not decide who is allowed to do what. That is still yours.
The failure to avoid: a server running under one service account with broad rights, reachable by an assistant that any employee can prompt. That is a privilege escalation route with a chat interface in front of it.
The user’s identity has to flow through to the call, and your existing authorization has to run exactly as it would for a normal request. Retrieval needs permission trimming at query time, not filtering afterwards. If your systems cannot answer “what may this specific person see” at the point of query, that is the first piece of work, before any agent.
Which workflows are worth it
Not many, at first. The ones that repay the effort usually share a shape:
| Good fit | Poor fit |
|---|---|
| Spans three or more systems | Lives entirely in one app |
| Rules change with context | Rules are fixed and simple |
| A human decides, tooling gathers | Fully deterministic end to end |
| Runs often enough to matter | A handful of times a month |
If a process is deterministic and lives in one system, a scheduled job or a Power Automate flow will be cheaper to build and far cheaper to run. We say that on first calls regularly.
What we would build first
Start with a read-only server. Expose the retrieval a team already does by hand, permission-trimmed, and let people use it for a fortnight. You learn what questions get asked, which is the information you need before designing anything that writes.
Then add one write tool with an idempotency key and a human approving the action. The agent prepares, a person confirms in one click, and the approval is logged with who and when. You keep most of the time saved and none of the exposure, and you accumulate the evidence needed to justify removing the checkpoint later.
Instrument from the first day: every call, its arguments, the identity behind it, the result. Six months on, someone will ask why the system did a particular thing, and that log is the whole of your answer.
The honest summary
MCP does not make agents smarter. It makes integration reusable, which is where the cost actually sits. The teams getting value are the ones whose services, permissions and logging were in reasonable order beforehand, because a protocol inherits every weakness of the estate underneath it.
We build agentic automation in .NET, wired into SharePoint, Dynamics 365 and Salesforce with the permissions you already have. See our AI agents and copilots service, or get in touch.