MCP servers and agent access for your business systems

What an MCP server does for a business

Most businesses already let staff paste data into ChatGPT or Claude by hand: an order number, a customer record, a stock count. An MCP server removes that step. It exposes a defined set of tools, each one a specific, typed action such as "look up order status" or "check stock on hand", so an assistant calls the business's own systems directly instead of working from a pasted screenshot.

Model Context Protocol, the open standard behind this, was published by Anthropic in late 2024 and picked up quickly by OpenAI, Google and the major agent frameworks that followed. For an IT or operations manager, the practical effect is that connecting Claude, ChatGPT or an internal agent to a CRM, ERP or document store becomes one integration built to a shared standard, rather than a bespoke project every time a new assistant needs access.

National Digital builds and operates remote MCP servers that AI agents can connect to without a key or an account, and has one listed in the official MCP Registry. A well-built server turns agent-ready data into something an assistant can call safely. National Digital builds AI agent tools whose every answer names the data version it came from and carries the publisher's licence and attribution, so an agent can cite what it used. That matters once an agent's answer feeds into a decision someone has to stand behind.

Building a custom MCP server

The steps to build a custom MCP server run from the tool list to a staging test with a real assistant.

The tool definitions are the easy part. Most of the engineering effort in a custom MCP server goes into the layer underneath: matching each caller's access to the permissions they already hold in the source system, rather than handing the assistant one broad service account. A server that works cleanly in a demo against a personal API key becomes a different problem once it has to enforce the same row-level access a staff member has in the CRM or ERP it is querying.

publicdata.au is a working example of the pattern. The server lists 12 tools, and the pages built on top of it register a further 10 tools through WebMCP, so an agent working in a browser can query the same data the server exposes. National Digital defines each AI agent tool once and generates every surface that exposes it, with a gate that fails the deploy when a copy drifts and a test that requires identical answers from each surface. The same consistency matters inside a business: a tool for checking stock or raising a ticket should answer identically whether it is called from a chat assistant, a browser extension or an internal script, which is the standard that ticket triage automation and similar internal workflows need to meet.

Securing an MCP server once systems are exposed

Exposing internal systems to an AI assistant widens the attack surface, and the cost of getting that wrong is real. The average self-reported cost of cybercrime per report for Australian businesses reached $80,850 (Australian Signals Directorate, 2025) in FY2024-25. A production MCP server needs the same controls as any other API: scoped OAuth tokens rather than a shared key, rate limits per caller, and logging that survives long enough to investigate an incident. Read-only tools should sit apart from anything that writes data, and a write action worth automating is usually worth a human approval step first.

The same discipline applies to public data as to an internal system. The MCP server for public data behind surgerywaits.au lists 4, and still needs versioning and clear citations so an agent's answer traces back to a release date, not just a number. Weighing an MCP server against a chat assistant with no tools at all is also worth framing against deterministic automation vs AI, since a tool call is deterministic by design while the assistant deciding when to use it is not.