Skip to main content

Using MCP

EngineersIntegratorsOperationsLeadership
In one minute

An AI assistant on its own knows a great deal about the world and nothing at all about your plant. The Model Context Protocol, usually shortened to MCP, is the standard way to fix that: it lets an assistant call tools that fetch real data, in a form any assistant can use.

DataHub publishes 38 tools across two MCP servers. Point an assistant at them and a question like "what did the export compressor do overnight, and was anything raised against it?" stops being unanswerable. The access rules do not change: an MCP call is checked exactly like any other request.

What MCP is​

MCP is a small open standard that says how an AI assistant asks a system what it can do, and then does it. Nothing more exotic than that.

A system that wants to be usable by AI publishes an MCP server: a list of named tools, each with typed arguments and a description written for the model to read. An assistant, the client, connects, reads the list, and calls the ones it needs. Because the list is described rather than hard-coded, the assistant works out for itself which tool answers the question in front of it.

The reason this matters is arithmetic. Before a shared protocol, every combination of assistant and system needed its own integration, so five assistants and eight systems meant forty pieces of software that all had to be maintained by somebody. With one protocol, each system is served once and each assistant speaks it once.

One protocol instead of one integration per pairAny client that speaks MCP can use any system that serves it. The system’s owner writes the server once.Before: bespoke each timeWith a shared protocolAssistantAgentCopilotDataHubCMMSHistorian3 clients × 3 systems = 9 integrations to write and maintainadd a fourth system and you write three moreMCPAssistantAgentCopilotDataHubCMMSHistorian3 clients + 3 systems = 6 connections, none of them bespokeadd a fourth system and it serves every client on day oneDataHub sits on the right-hand side: it publishes its tools once, and an assistant, an agentyou wrote or a coding tool all reach them the same way, with nothing written for any one of them.
The left panel is the state everyone was in before the protocol existed, and the reason so few AI pilots ever reached real data. The right panel is why an assistant can be useful on day one against a system nobody wrote it for.

The vocabulary, so the rest of this page reads cleanly:

TermWhat it means here
ClientThe thing the person talks to: a desktop assistant, a coding tool, the console's own assistant, or an agent you wrote
ServerThe system exposing capabilities. DataHub is one; your maintenance system might be another
ToolOne named capability, such as event_filter, with typed arguments and a description the model reads
TransportHow they talk. DataHub's servers speak ordinary HTTP, with your normal token in the Authorization header

Why it matters now​

Three things arrived at roughly the same time, and only the combination is interesting.

Models became reliable at using tools. Choosing the right call, filling in its arguments correctly and reacting sensibly to what comes back used to fail often enough to be a curiosity. It now works well enough to build on.

Access to real data stopped being bespoke. MCP, published as an open standard in late 2024, was adopted quickly and broadly, so the plumbing question, how do we let this thing see our data, has one answer instead of one per vendor.

Which moves the bottleneck. When the model is good and the connection is standard, the thing that decides whether an assistant is useful is whether the data it reaches has any meaning attached. An assistant connected to a tag list can fetch numbers it cannot interpret. The same assistant connected to a model of your operation can follow a signal to the equipment, the equipment to what it feeds, and the failure to what it will cost.

That is the strategic reading of MCP for an industrial operator: it makes the connection cheap, and therefore makes the context the scarce part. Why that compounds →

The one-line version for a leadership meeting

MCP is a standard plug. It does not make your data meaningful, it makes meaningful data reachable, which is why the work on this site, naming, modelling, connecting, is what decides how much you get from AI.

What DataHub exposes​

Two servers, each at a /mcp address on the service that owns it. Every tool is named <domain>_<action>, so the listing reads the same to you and to the model.

The API server publishes 37 tools in seven families:

FamilyToolsWhat it lets an assistant do
Data sets5List, search, create, update and delete data sets
Resources7Search and fetch equipment and other things, create and update them, walk outward to a neighbourhood, or hunt for the nearest thing of a given kind
Relationships5List and create relationship types, connect two existing things, delete an edge
Time series9Find series, read the latest value, fetch history between two timestamps, append a datapoint
Events6Search, filter, read, create, update and delete events
Labels3List and manage the labels that classify things
Units2Look up units of measure, so a number arrives with its dimension

Three are worth knowing by name, because they are what make an answer good rather than merely fast:

  • resource_fetch_related returns a thing's neighbourhood in one call rather than making the assistant crawl edge by edge. This is the tool that turns "what does this affect?" into a single question.
  • resource_fetch_nearest asks the sharper version: not "what surrounds this" but "where is the nearest thing of this kind", breadth-first outward until it has found enough of them. This is how an assistant gets from a pump to the series measuring it without knowing your modelling conventions.
  • event_filter answers anything time-bounded or exact. Search is for when the assistant only has words to go on.

The second server: statistics as a tool​

The analysis service publishes its own /mcp with a single tool, analysis_related_series. Given one series and a window, it walks the graph outward to find physically related candidates, tests each pair statistically and returns them ranked: how strongly they move together, which one leads, whether the link survives removing shared trends, and whether it holds across the whole window or rides one burst.

This is the same relationship analysis behind the console's Analyze tab, and it matters more for an agent than for a person. Asked "what is driving this?", an assistant with only raw numbers will estimate, and estimate confidently. With this tool it can answer from the statistics instead.

The full tool list, with arguments and return shapes, is in the developer documentation.

The security property that matters​

This is the part worth reading even if somebody else will do the connecting.

An MCP call is an ordinary authenticated requestThere is no agent door and no agent key. The same token, the same checks, in the same order.a questionMCP call, carrying your token37 toolsYouAgentor assistantBefore any tool runssignature and issuerDATAHUB_ACCESS roleorganization → tenantdata set grantsresource_fetch_relatedtimeseries_fetch_datapointsevent_filterthe answer, plus the ids, timestamps and values behind itA read-only agent is simply one holding a read-only token, which is why scoping an agent isthe same administrative act as scoping any other service account, in the same place.
Nothing in this path was added for agents. The gate is the same one the console and every REST client pass through, in the same order, and it is the same on both servers, which is why an agent's reach is decided entirely by whose token it holds.
  • There is no separate door and no agent key. Every MCP request carries an ordinary OAuth2 token from your identity provider. Each endpoint sits on the same security chain as everything else its service serves.
  • An agent inherits the permissions of whoever it acts for. If it should read but not write, issue it a token that can read but not write. There is no second permission model to keep aligned with the first.
  • Tenant comes from the token's organization claim, so an assistant cannot reach another tenant's data even by asking for an id it happens to know. Organizations →
  • Scoping an assistant is scoping a service account. Create one in your identity provider, grant its groups read on the data sets it should see, and it can see nothing else. Service accounts →
The approval step is yours to build

A server executes what it is asked. It cannot stop mid-call to ask a person to confirm a write or a delete, so if an assistant should pause for a human before it changes anything, that gate belongs in the agent you build, not in the platform. The simplest version is also the strongest: an assistant with no business writing gets a token that cannot write. Guardrails in practice →

Connecting an assistant​

Decide whose eyes it looks through

A person's own login is right for a desktop assistant they use themselves. A service account is right for anything that runs unattended, because its access can be scoped and revoked without touching a person's account.

Grant it read on the data sets it should see

Membership of the read group for each data set, and nothing wider. Grants take effect within about a minute. Data set permissions →

Point the client at the servers

Any MCP client that speaks HTTP and can attach a bearer token will work. The two servers are two entries, with the same token in both:

{
  "mcpServers": {
    "datahub": {
      "type": "http",
      "url": "https://your-datahub-host/mcp",
      "headers": { "Authorization": "Bearer ${DATAHUB_TOKEN}" }
    },
    "datahub-analysis": {
      "type": "http",
      "url": "https://your-analysis-host/mcp",
      "headers": { "Authorization": "Bearer ${DATAHUB_TOKEN}" }
    }
  }
}

Tokens are short-lived. For anything long-running, refresh through your identity provider and update the header rather than pinning a token into a file.

Ask something that needs the model

Not "what is the pressure on P-101", which any historian could answer. Ask "what feeds P-101, and did anything happen upstream of it last night?" If the answer names the upstream equipment and the event, the connection and the model are both doing their job.

Check what it did, not just what it said

A good answer cites the ids, timestamps and values it used. Spot-check two of them in the console. Do this on the first few answers and you will calibrate quickly on where the model is thin.

The console assistant: MCP with nothing to set up​

The console's own assistant is a client of the API's server, which makes it the easiest way to see what an AI assistant can do with your data before anybody wires anything up.

It is deliberately stricter than a general client:

  • Read-only, by an allowlist. It is offered a named subset of the read-only tools and nothing else. The filter is default-deny: anything not on the list, including a tool added to the API later, is treated as mutating and never offered. A mutating call is refused again at the point of execution, so the property holds even if the model asks for one.
  • It answers about your tenant, not about the world. Asked "anything unusual this weekend?", it reads events and datapoints in your own data rather than answering from general knowledge, and it says so plainly when the tools return nothing.
  • It bounds itself. Up to six model-to-tool round trips per question, oversized tool results truncated with a note telling the model to narrow its query, and a capped conversation history.
  • It can hand you the console. Alongside the data tools it offers navigation tools, so an answer can arrive with a button that opens the events, resources, insights or Analyze view, already filtered to what it just looked up.
  • Three switches must agree before it appears at all: enabled in the deployment, enabled for your tenant, and the signed-in user holds the DATAHUB_CHAT role. How that is controlled →

What MCP does not do​

It does notWhich means
Add context you never modelledAn assistant reaching an unmodelled tag list gets numbers without meaning, faster. The protocol carries what is there. Building your model →
Ask permission before it writesA server has no way to interrupt a call for a human decision. Put that gate in the agent, or issue a read-only token
Widen what a user can seeThe token decides. An assistant used by a person sees exactly what that person sees, no more
Cache anythingEvery call is authorised afresh, so a revoked grant stops working within about a minute rather than at the next sign-in
Replace the APIFor a fixed integration that runs the same way every day, write it against the API. MCP is for the case where the sequence of calls is decided at the time by a model
External references
Go deeper