AI for Niagara Tridium

What the MCP Boundary Is Actually Made Of

MCP is a JSON-RPC 2.0 protocol. The client and server negotiate capabilities during the initialize exchange, and the server then advertises three separate primitives: tools, which the model can decide to call on its own; resources, which the client reads on request; and prompts, which a person selects deliberately. Which primitive a capability lands in is a design decision with consequences. Exposing a station inventory as a resource the client fetches when asked is a narrower exposure than exposing it as a tool the model invokes whenever it judges the inventory relevant.

Tool annotations such as readOnlyHint and destructiveHint travel with the tool definition, but they are advisory metadata for the client to display and reason about. Nothing in the protocol prevents a server whose tool is labeled read-only from writing. Enforcement has to sit below the protocol, in the code path of the tool and in the credentials the server actually holds. A server process that only ever possesses read credentials cannot be talked into a write, whatever the model decides to call and whatever a compromised client sends.

Transport choice moves the boundary. Running the server over stdio as a subprocess of a desktop assistant puts the trust boundary at the workstation and the person logged into it. Running it over streamable HTTP so several clients share one server means the server now needs authentication, per-caller identity, and origin validation, because tool calls arrive over a network the operator does not control. The MCP guidance to validate the Origin header and bind local servers to the loopback interface exists because a browser page can otherwise reach a server listening on localhost.

• Prefer narrow input schemas to general ones. A tool that takes a station identifier and a point path constrains what can be asked of it. A tool that accepts a free-form query string inherits every capability of the query language behind it, including the parts nobody meant to expose.
• One capability per tool, named for exactly what it does. The model selects tools from names and descriptions, so two similarly described tools get confused with each other, and the fix is naming, not a larger model.
• Validate arguments server-side against an allowlist, not with schema validation alone. JSON Schema confirms that a station identifier is a string; it does not confirm that this caller is allowed to read that station.
• Cap and paginate results inside the tool, and return the cap in the response. A query matching ten thousand rows should return a bounded page plus a total, so the model can say the list was truncated instead of treating one page as the whole.
• Return failures as structured tool errors rather than letting exceptions surface as raw text. A model that receives a typed error can correct the call; a model that receives a stack trace tends to report it as a finding about the building.

Grounding, Citations, and Permission-Aware Retrieval

Retrieval quality is set by chunking and metadata, not by the model. A sequence of operations split across a chunk boundary loses the setpoint row that gave the paragraph its meaning, and a chunk stored without its document title, revision, and site cannot be cited in a way a technician can verify. A citation that names only a filename is close to useless when the file is a 200 page manual; the citation has to resolve to the passage that was actually retrieved, and to the revision it came from.

Permission filtering belongs in the retrieval query, not in a pass over the results afterward. Once a passage is in the context window the model can restate its content without reproducing the citation, so removing a citation does not remove the information. The retrieval identity should be the identity of the person asking, resolved against your existing directory or SSO groups, rather than a service account holding the union of everyone's access with filtering applied later.

An index built once drifts away from the documents it represents. A revised SOP leaves its previous embedding in the index unless the document is re-indexed on change, and the agent will keep citing a superseded procedure with complete confidence, because from its side nothing looks wrong. Withdrawn documents matter as much as edited ones: stale vectors outlive the files they came from. Where two sources genuinely disagree, such as a general manual and a site-specific note, precedence has to be stated explicitly in metadata, or the answer blends them into something that matches neither.

• Store document title, revision, effective date, site, and access group as chunk metadata. That metadata is what makes both the permission filter and a verifiable citation possible.
• Re-index on document change and delete chunks for withdrawn documents on the same code path, so removal is not a separate process someone has to remember to run.
• Resolve the asking user's groups at query time and filter inside the vector or keyword search, not after the passages have been retrieved.
• Keep a fixed evaluation set of questions with known answers and known source documents, and re-run it after every index rebuild, prompt change, or model change. Without it, a regression is invisible until a technician acts on a wrong answer.
• Score "that is not in the documents I can see" as a correct answer when it is correct. An agent that never abstains is not more useful, it is less honest.
• Prefer an extractive quote with a link to the passage over a paraphrase for anything a technician is expected to act on.

Context Limits and Why the Tool Set Decides Answer Quality

No station of any real size fits in a context window, and the ones that would fit should not be loaded that way. Filling context degrades retrieval within it, because relevant details compete for attention with thousands of irrelevant ones, and the whole payload is re-sent on every turn, so latency and cost scale with the padding rather than with the question. The working design is a small set of tools that each return a narrow slice on demand. The practical consequence is that the ceiling on answer quality is the tool set, not the model.

The characteristic failure mode is a question no tool can answer. The model does not stop; it reshapes the question until an available tool fits, then answers from whatever adjacent data it could reach, fluently. The diagnostic is the tool-call trace, and it separates two problems that look identical from the outside. If the trace shows the model bending the question to fit an existing tool, that is a missing tool, and no prompt change will fix it. If the trace shows the right tool returning the right data and the summary still misstating it, that is a prompt or model problem, and adding tools will not help.

Long sessions decay in a way that is easy to miss. As a conversation grows, earlier turns get summarized or dropped, and a constraint stated once at the beginning stops being present in the context that produces turn forty. Scope constraints that matter, such as which site is in play and what the agent is permitted to do, belong in the system instructions and repeated in tool results, not in conversation history.

• Return counts and aggregates by default, with a separate drill-down tool for detail, rather than returning rows because rows happened to be available.
• Include units, timestamps with explicit offsets, and quality or reliability flags in every result. A number without units is where a wrong conclusion starts, and a stale value that looks current is worse than a gap.
• Distinguish an empty result from a failed one in the response body. "No alarms matched" and "the query did not run" have to look different to the model, or an outage reads as good news.
• Log every tool call with its arguments, result size, and duration. That trace is the first artifact to read when an answer looks wrong, and the only one that separates a missing tool from a bad summary.

Escalation Paths, Approval Binding, and Replay Safety

A message delivered is not a decision made. Delivery receipts on SMS and WhatsApp confirm that a handset accepted the message, not that a person read it, understood it, or is awake. An escalation therefore needs an explicit acknowledgment step and a timeout that moves to the next name on the roster, otherwise an escalation sent to somebody mid-flight becomes, silently, no escalation at all.

Messaging channels also impose constraints that shape the design. The WhatsApp Business Platform only lets a business open a conversation outside the 24 hour customer service window using a message template approved in advance, so escalation text is a registered template with variables rather than free prose composed at the moment. Inbound SMS proves control of a handset, not the identity of a person, and sender information on these channels is not a credential. The practical pattern is that the notification carries the context and a link, while the approval itself happens in an authenticated view where the approver is actually identified.

Approval only means something if it is bound to the exact action proposed. An approval token should reference the specific call and its arguments, be single use, and expire, so that consent given for one action cannot be replayed against a different one that arrives later. Any call that changes state should carry an idempotency key, so a network retry is deduplicated at the server instead of repeated at the equipment. Without both, a slow connection and a resent request are indistinguishable from a deliberate second command.

• Give every escalation a correlation ID that ties the trigger, the evidence retrieved, the proposed action, the approver, the decision, and the result into one record that can be replayed later.
• Bind the approval to a hash of the proposed call and its arguments, and void it if either changes between proposal and execution.
• Define an acknowledgment timeout, a next in line, and quiet-hours rules that state what is worth waking someone for and what waits until morning.
• Make refusal first class. Recording "no" has to be as easy and as auditable as recording "yes", or people approve things to clear the notification.
• Deduplicate and rate-limit before escalating. One root cause can generate a burst of alarms, and an agent that pages a person for each of them teaches that person to ignore it.

When an Agent Is the Wrong Tool

If a question has one correct answer computable from a query, write the query. A threshold, a scheduled report, or a rule is deterministic, testable, cheap to run, and produces the same output for the same input every time, which is what you want for anything that has to be defended afterward. Language model output varies between runs on identical input. That variance is acceptable in a summary a person reads and unacceptable in a decision that has to be reproducible.

Volume decides whether the agent work pays for itself. Building and maintaining a triage loop is justified where alarm and ticket volume exceeds what people can actually read; a site producing a handful of alarms a week does not need one, and a person will beat it on both speed and accuracy. The same test applies to a knowledge agent: it needs a corpus that contains the answers. If your standards and sequences live in three people's heads, the work to do first is writing them down, and that work has value whether or not an agent ever reads the result.

Agents earn their place where the input is unstructured, where the path branches on judgment, and where an answer requires joining sources that were never designed to be joined. A ticket written in prose, a manual, a commissioning note, and a point history are four different shapes of information, and reconciling them is the part that resists being written as a rule. That is a different problem from evaluating a threshold, and it is worth being clear about which one you have before anyone builds anything.

• Use a rule or a threshold when the condition can be expressed over known points, and keep it as a rule even after an agent exists.
• Use a scheduled report when what you want is the same view on the same cadence with no interpretation step.
• Use search when what you want is to find the document, not to have an answer synthesized from several documents.
• Use an agent when the useful output is a judgment across unstructured sources, and when a person will still review it before anything happens.