Willow MCP Server: Technical & Security Overview

1. Overview

The Willow MCP server implements the open Model Context Protocol (MCP), an OAuth 2.1–based standard that lets AI assistants (Claude, ChatGPT) connect to external systems. It is a hosted ASP.NET Core service that exposes Willow capabilities as MCP “tools.”

Crucially, it introduces no new data store and no new source of truth. Every request is authenticated as the signed-in user, checked against that user’s permissions, and then served by calling the same backend services the Willow App already uses. If a user cannot see something in the Willow App, they cannot see it through MCP.

2. Authentication & identity

Same identity provider, same tokens, same tenant as the Willow App.

3. Authorisation & permissions

The user’s existing fine-grained permissions are enforced — MCP can never exceed them.

Authorisation reuses Willow’s fine-grained access control, the same model that governs the Willow App. Each tool declares the permission it needs (e.g. “view tickets”, “view locations”), evaluated against the authorisation service per request. Enforcement happens at three layers:

• Tool discovery — tools the user lacks permission for are hidden from their tool list entirely.
• Tool invocation — calls are blocked at request time if the required permission is missing.
• Result scoping — query results are filtered to only the sites/locations the user is scoped to. A user with access to three buildings sees data for exactly those three.

4. Tenancy & isolation

One dedicated instance per customer — your tenant boundary is the deployment boundary.

The MCP server is deployed single-tenant: one instance per customer environment, alongside that customer’s own Willow services and authorisation service. It is configured for one Entra tenant and connects only to that customer’s backend. There is no shared multi-customer instance and no cross-customer data path.

It runs as a standard hardened container (non-root user, HTTPS ingress) on Willow’s managed Azure hosting, inside the same environment as the rest of that customer’s platform.

5. Backend data sources

Identical to the Willow App — the same service SDKs, the same APIs.

The MCP server does not query databases directly. It calls the same internal Willow services the Willow App calls, using the same client SDKs, passing the user’s token through:

6. Data handling & PII

An honest account of what is returned and how it is handled.

The MCP server returns the same business data the user could already retrieve in the Willow App — nothing more. That data can include limited personal information where it is part of a record: for example, the name and email of a ticket’s assignee, reporter, or creator, and the signed-in user’s own email when they query their permissions. This is the same contact information already visible on those records in the Willow App.

• No bulk personal-data export. There is no tool to dump user directories, contact lists, or credentials.
• PII is kept out of logs. Identifiers such as email addresses are masked before being written to telemetry/Application Insights; the full value is only ever returned to the authenticated user who already has access to it.
• No secrets returned. Tools surface operational building data, not passwords, keys, or tokens.

7. Write operations & safety

Read-mostly, with explicit confirmation and validation on every change.

The overwhelming majority of tools are read-only. A small number perform writes — creating/updating tickets, adding ticket comments, and creating/updating reports and report notifications. Each write is guarded:

• Explicit confirmation. Write actions require an in-client confirmation prompt (MCP “elicitation”) before they execute, so nothing is changed without the user agreeing.
• Permission-gated. A write needs the matching permission (e.g. “create tickets”); it is not implied by read access.
• Input validation. Requests are validated (required fields, formats, lengths) before reaching the backend.
• Audit trail. Mutations are recorded with the acting user’s identity and the action taken.

8. The connection flow

End to end, the first time a user connects.

1. Add the connector. The user adds the Willow MCP endpoint in their assistant.
2. Sign in with Entra. The assistant redirects to your Entra sign-in; the user authenticates (incl. MFA / Conditional Access as your policies require).
3. Token issued & validated. Entra issues a scoped JWT; the MCP server validates it and confirms the Mcp.Access scope.
4. Permission-scoped session. Available tools and visible data are filtered to that user’s fine-grained permissions.
5. Requests proxied to Willow services. Each query is served by the same backend services as the Willow App; writes require confirmation.

Quick answers for common IT questions