For IT administrators

Last updated: 7 October 2026

This page is for the person who approves software on developer machines or administers your GitHub organisation's Copilot policies. It describes what TSE-Assistant installs, what leaves the machine, how to verify the installer, and the one entry your GitHub organisation may need so Visual Studio is allowed to start it. The longer account of our data handling is on the Security page.

1. What is installed on a developer machine

One signed Windows installer puts a local MCP server on the developer's machine and wires it into the IDE. The server is a Node.js process started by the IDE over standard input/output (stdio) and stopped when the IDE closes. It opens no listening port and has no remote endpoint; nothing on your network can reach it, and it cannot be reached from the internet.

Item	Value
Server ID (every IDE config, every registry entry)	`tse-assistant`
Transport	`stdio` — started by the IDE, no port, no URL
Command	`<install folder>\node\node.exe <install folder>\agent\apps\agent\dist\index.js`
Install folder	`%LOCALAPPDATA%\Programs\TSE-Assistant` by default, or the folder chosen at install (a dev VM typically uses a data drive, e.g. `K:\TSE-Assistant`)
IDE wiring	`%USERPROFILE%\.mcp.json` (Visual Studio), VS Code's `mcp.json`, Cursor's `mcp.json`, `CLAUDE.md` — all written by the installer, all pointing at the command above
Local data	The metadata index of the environment and the agent's settings, under `%USERPROFILE%\.tse-assistant` and the install folder — on the machine only

2. What leaves the machine

The server talks to three things and nothing else.

The IDE, over stdio. Tool results — search hits, object metadata, X++ source the developer asks for — go to the IDE, and from there to the AI model the IDE uses (GitHub Copilot, Cursor, Claude) under your agreement with that provider. That traffic is the IDE's own and does not pass through us.
TSE's control plane, over HTTPS (Azure, UK South). Registration, the seat's licence check-in, the served guideline packs, and one audit record per tool call: the tool name, the seat, the time, a SHA-256 fingerprint of the arguments and the size of the response — for tools that change something, the names of the objects changed. Never arguments, code, field values or record keys; an automated test fails our build if source text appears in an emitted record. Full detail on the Security page, sections 1 and 6.
Optional, only if your company switches it on: the published index (metadata, never source) for consultant and super-user seats, and Microsoft standard-code reviews that run on the developer's own machine and return a plain-language explanation. Both are described on the Security page, sections 2 and 5.

3. How to verify the installer

The installer and the files it places are signed through Microsoft Trusted Signing with a public-trust certificate issued to TSE IT SOLUTIONS LIMITED (United Kingdom). Right-click the .exe → Properties → Digital Signatures: the signer is TSE IT SOLUTIONS LIMITED and the signature reads "OK". The installer is downloaded from the company dashboard, over HTTPS, and every release is listed on the Release notes page.

4. Data protection

Company accounts are covered by our Data Processing Agreement; the processors we use are on the Sub-processors page, and the Privacy notice describes personal data. Everything we store is in the United Kingdom unless the sub-processor page says otherwise. Security questions: security@tse-assistant.com.

5. GitHub Copilot Business and Enterprise: the MCP allow list

GitHub lets an organisation restrict which MCP servers Copilot may run. Under Organisation settings → Copilot → Policies, "Restrict MCP access to registry servers" is either Allow all or Registry only, the latter with an "MCP registry URL" the organisation hosts itself (Azure API Center, or any registry that serves the MCP registry API). With Registry only in force, Visual Studio 2026 shows the server greyed out in the Copilot Tools panel with "Disabled due to registry policies", and the developer's assistant answers without it. A server added at solution level is checked the same way, so there is nothing a developer can do locally. Your organisation owner either adds the entry below to the registry, or sets the policy to Allow all.

How Visual Studio decides (we read it from the client, version 18.10, because the documentation does not say): it fetches <registry URL>/v0.1/servers?version=latest and follows nextCursor through every page; for each entry it takes name exactly as written and accepts a local server only when the entry has at least one item under packages (an entry with a placeholder remotes URL instead matches nothing local). The developer's .mcp.json key must equal that name, case-insensitively. Microsoft's own servers (NuGet, Microsoft Learn, Azure MCP) are not exempt: whatever registry you set must list everything you allow.

The registry entry — the name must be exactly tse-assistant, and it must carry a package:

{
  "name": "tse-assistant",
  "description": "Local MCP server for Dynamics 365 F&O development: X++ metadata, code and guidelines.",
  "version": "<the installed version, e.g. 1.2.37>",
  "websiteUrl": "https://tse-assistant.com/for-it-admins.html",
  "packages": [
    { "registryType": "installer", "registryBaseUrl": "https://tse-assistant.com",
      "identifier": "https://tse-assistant.com/#start", "version": "<the same version>",
      "runtimeHint": "node", "transport": { "type": "stdio" } }
  ]
}

The transport is stdio — a local process the IDE starts from the install folder (section 1); there is no remote endpoint. In Azure API Center, add the server with this name and a description, and give it a package rather than a URL. Nothing changes on the developer's machine afterwards: the entry the installer wrote starts working at the next IDE start. Older Copilot builds (Visual Studio 2022 at the time of writing) do not yet enforce the policy; expect them to with an update, so the entry is worth adding before it bites.

No registry of your own? We serve one that lists exactly this entry, kept at the published version: https://tse-assistant.com/mcp-registry (the base URL goes in the policy box; the client appends /v0.1/servers itself). Because the client exempts nothing, pointing the policy at it allows only TSE-Assistant — Microsoft's servers included would be off — so it suits an organisation that uses no other MCP server, and nothing else.

6. The request a developer can send

Copy this to your GitHub organisation owner:

We use TSE-Assistant, a local MCP server for Dynamics 365 F&O development, on our dev VMs
with Visual Studio. Under the organisation's Copilot MCP policy ("Registry only") it shows as
"Disabled due to registry policies". Could you add it to the organisation's MCP registry?

  Server name/ID: tse-assistant   (exactly - the client matches the config key against it)
  Entry: must include a "packages" item (Visual Studio only matches a local server from one;
         an entry with a placeholder URL does not work) - the exact JSON is in section 5 of
         https://tse-assistant.com/for-it-admins.html
  Type: stdio — runs locally on the VM, started by the IDE; no remote endpoint;
        the source stays on the machine
  Publisher: TSE IT SOLUTIONS LIMITED, https://tse-assistant.com

Alternatively, setting "Restrict MCP access to registry servers" to "Allow all" also unblocks it.

7. Other IDEs

Cursor, Claude Code and Claude Desktop read the same local server through their own configuration files and are not subject to the GitHub Copilot policy. VS Code with a Copilot Business or Enterprise seat follows the same organisation policy as Visual Studio.

Keep one tse-assistant definition per machine: the user-level .mcp.json the installer writes. Do not add a solution-level definition with the same name (<solution>\.mcp.json or <solution>\.vs\mcp.json): Visual Studio 2022 routes tool calls to the solution-level one, and it remembers that definition in the solution's hidden .vs folder even after the file is deleted. The symptom is a server that lists all its tools while every tool call answers with nothing, on one solution only. The fix is to close Visual Studio, rename that solution's .vs folder, and reopen the solution.