Should Australian MSPs Build Their Automation Stack on MCP?

Last Updated: 14 November 2026

What Sherweb just did

Sherweb has launched a Model Context Protocol server that connects AI assistants and automation tools directly to the cloud distributor's platform data, for a partner network of more than 7,500 managed service providers. Through compatible AI tools, an MSP can retrieve subscription, pricing, usage and billing information without logging into the partner portal.

The build was shaped by 15 partners in an early-access program that began in summer 2026, and the use cases named at launch are renewals, quoting, reporting and billing analysis. The examples are deliberately modest. A finance lead can ask for a specific client's charge breakdown. A sales rep can pull current pricing across multiple SKUs. Nobody is letting an agent sign contracts.

That modesty is the signal. When a distributor ships an MCP server, the protocol has moved from developer experiment to channel product. The question for an Australian MSP is no longer whether MCP is real. It is whether you build your automation on it, and what that commits you to.

What MCP is now, in one paragraph

The Model Context Protocol is an open standard for exposing tools, data and prompts to a model in a structured way, so that any compliant client can drive any compliant server. The 2026-07-28 specification is the current one, and it changed more than the version number: a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, an extensions framework and hardened authorization. Transports are stdio for local servers and streamable HTTP for remote ones.

The practical consequence is that a tool integration is now written once and consumed by Claude, ChatGPT, Codex, Cursor or your own agent. That is why the ecosystem grew the way it did, and why a distributor like Sherweb could ship one server and reach thousands of partners at once. A third-party catalogue already lists 28 MCP servers aimed at MSP platforms, covering PSA, RMM, documentation and backup systems.

Read that diagram twice, because the middle box is the part most MSPs underestimate. An MCP server is not a passive API wrapper. It controls tool descriptions, resources and tool results, all of which enter the model's trusted context. Whoever operates that server can influence what your agent believes.

Why the channel cares

An MSP's margin has always come from labour arbitrage: standardise the work, do it from a low-cost pool, charge for the outcome. AI compresses the labour, which compresses the arbitrage. The replacement is tool arbitrage: own the automation layer that sits between your clients' systems and their outcomes, and charge for the workflow rather than the ticket.

MCP is the cheapest way to build that layer because the connectors already exist. Instead of writing a bespoke integration for each PSA, RMM and backup platform, you point an agent at an MCP server and describe the job in plain language. Quoting, renewal preparation, licence true-ups and billing reconciliation are the first jobs that pay, because they are rule-bound, high volume and measured on numbers the MSP already tracks.

There is a commercial risk worth naming. The same protocol that lets you reach a distributor's data also lets the distributor reach your clients. Sherweb's server is a channel play: it makes the portal stickier and makes AI-assisted quoting a feature of buying through Sherweb. If your differentiation is that you know the client's estate better than the distributor does, MCP raises the value of the data you hold and lowers the value of the portal you log into.

The risks that matter

Every MCP server you connect is a new trust boundary, and the threat model is specific enough that OWASP now maintains an MCP security cheat sheet. Three risks cover most of it. Tool poisoning is a malicious or compromised server describing a tool in a way that steers the model, for example an instruction hidden in a tool description that tells the agent to read a credential file. Indirect prompt injection arrives through tool results, so a hostile document or ticket body can carry instructions the model treats as data. The confused deputy problem is an agent holding broad credentials and being talked into using them on behalf of someone who should not have them.

Then there is the rug pull, which is particular to this ecosystem: a server is benign at install and changes its behaviour in a later version. Version pinning and re-review on update are the controls, and almost nobody does them yet.

The design rule that follows is boring and effective. Give each MCP server its own credential with the narrowest scope that still does the job. Put the server behind a gateway you control, so you can log every call and revoke a connector without touching the agent. Treat tool output as untrusted input, which means the agent never executes an instruction that arrived inside a ticket, an email or a web page. And start read-only.

Tier one is read-only: query subscription and billing data, pull device inventory, read ticket history. Tier two drafts and proposes: prepare a quote, draft a renewal email, write a change plan, but never send or commit. Tier three acts with approval: create the ticket, apply the licence change, schedule the backup job, with a human approving each action and every action logged. Most MSPs should live in tiers one and two for a year before touching tier three, and the reason is not caution for its own sake. It is that tier three is where an error becomes a client-facing incident.

The local stack, on one DGX Spark

The sovereignty argument for an Australian MSP is straightforward. If the model runs in your rack and the MCP servers run beside it, client data does not cross a border and does not enter a vendor's training or logging pipeline. That matters more than it used to, given the APRA expectations for third-party and supply-chain risk and the government's own preference for IRAP-assessed infrastructure.

A single DGX Spark carries 128GB of unified memory, which is enough for a capable open-weight model plus an MCP gateway and a logging store. That is not a frontier model, and it will be weaker than a hosted frontier model at long multi-step tool chains. For read-only queries, document drafting and quoting, the gap is small enough that the jurisdictional gain wins. For tier three actions, use a stronger model and keep the gateway and the logs local, so the credentials and the audit trail stay under your control even when inference does not.

This is the pattern worth building toward: a local control plane, a model you can swap, and connectors that are individually revocable. It also gives you something to sell. An MSP that can show a client the exact call log of every automated action, held in Australian infrastructure, has a procurement answer that a US-hosted agent platform cannot give.

What to build first

Start with the job that has the clearest number attached and the lowest blast radius. For most MSPs that is renewal preparation: pull subscription and usage data, compare against contract terms, draft the renewal summary, and let a human send it. It is high volume, rule-bound and measured in hours per renewal, and it exercises the read and draft tiers without touching a client system.

Then add the gateway and the logging before you add the second connector. The temptation is to wire up PSA, RMM, backup and billing in one sprint, which produces a system nobody can audit. One connector, one credential, one log stream, then the next.

Finally, write down the escalation rule. If the agent is unsure, it stops and asks. If a tool returns something that looks like an instruction, it flags it. If a call would change a client's environment, it waits for a human. Those three sentences are the difference between an automation stack and an incident report.

Frequently asked questions

What is an MCP server?

A Model Context Protocol server exposes tools, data and prompts to AI clients in a standard format, so any compliant agent can use it without a bespoke integration. Servers run locally over stdio or remotely over streamable HTTP.

What did Sherweb launch?

Sherweb launched an MCP server that lets its partner network of more than 7,500 MSPs query subscription, pricing, usage and billing data through AI assistants and automation tools. It was developed with 15 partners in an early-access program that began in summer 2026, with quoting, renewals, reporting and billing analysis as the first use cases.

Is MCP safe for managed service providers?

It can be, with controls. Every server is a trust boundary, so scope each credential narrowly, route calls through a gateway you control, log every call, treat tool output as untrusted input and start read-only. OWASP publishes an MCP security cheat sheet covering tool poisoning, prompt injection and confused deputy risks.

Can I run MCP servers against a local model?

Yes. A single DGX Spark with 128GB of unified memory can host a capable open-weight model plus an MCP gateway and logging. Local inference is strong enough for read-only queries and drafting, and for higher-risk actions you can pair a local gateway and logs with a stronger hosted model.

Where should an Australian MSP start with MCP automation?

With renewal preparation: pull subscription and usage data, compare against contract terms, draft the summary and have a human send it. It is high volume, rule-bound, measured in hours per renewal, and it stays inside the read and draft tiers.

About the author

AJ Awan is the founder of Flowtivity, an AI consultancy based on the Gold Coast. He is a former EY management consultant and a TOGAF certified enterprise architect, and he builds agent systems for Australian businesses that need them to run in production rather than in a demo.