Use LightHouse in Microsoft Copilot Studio

A Microsoft Copilot Studio agent can use LightHouse’s tools through LightHouse’s hosted MCP server. Published to Microsoft 365 Copilot or Teams, the agent gives your people LightHouse’s agents and knowledge retrieval where they already work. Each person signs in to LightHouse as themselves, so every call runs under their own role and the scopes they approve.

Copilot licences are not used to run Atlantic’s agents. The Copilot Studio agent calls LightHouse’s tools over MCP. The agents and the retrieval behind those tools run on your deployment, on the model providers your organisation has connected to LightHouse. Copilot Studio’s own model decides when to call a tool and phrases the answer; it is never a model backend for an Atlantic agent.

Before you start

• The hosted endpoint is on for your platform. The address below answers only where Atlantic has turned the hosted endpoint on (Availability).
• Your tenant ID: the first label of your portal’s address, beginning t-.
• A Copilot Studio environment in which you can create agents and tools.
• Your data policy allows the connection. Copilot Studio reaches MCP servers through Power Platform connectors, so a Power Platform data policy that blocks custom connectors blocks this one too. Your Power Platform administrator may need to allow it.

Add the server to an agent

1. In Copilot Studio, open the agent and go to Tools.
2. Select Add a tool, then New tool, then Model Context Protocol.
3. Fill in:
   • Server name: LightHouse
   • Server description: what the agent should use it for, for example “Our AI agents, their runs, usage and cost, and search across our knowledge bases. Use it for questions about our agents or our internal knowledge.”
   • Server URL: https://mcp.atlanticagenticlabs.com/t/<tenant id>/mcp
4. Under Authentication, choose OAuth 2.0, then Dynamic discovery.
5. Select Create. Copilot Studio discovers your portal’s OAuth endpoints and registers itself. No client ID or secret is entered, and none is issued.
6. Select Next. In Add tool, choose Create a new connection and sign in when asked (below).
7. Select Add to agent.

Dynamic (with the endpoints entered by hand) works too, if your environment does not offer Dynamic discovery:

Field	Value
Authorization URL	https://<tenant id>.atlanticagenticlabs.com
Token URL template	https://<tenant id>.atlanticagenticlabs.com/api/v1/oauth/token

Manual is not supported: it needs a client secret, and LightHouse issues none. Every client authenticates with PKCE instead.

Each person signs in as themselves

Open the tool’s settings in the agent and check that it uses end user credentials. Each person who uses the agent then signs in to LightHouse once, from a sign-in card in the chat, and every call runs as them. With the maker’s credentials, every user would read LightHouse as the maker; do not publish the agent that way.

Sign in

1. The first time the agent needs LightHouse, it shows a sign-in card. Select it.
2. Your browser opens your portal’s approval page, https://<tenant id>.atlanticagenticlabs.com/oauth/authorize. Sign in through your identity provider if your portal asks you to.
3. Review the request and select Approve. The browser returns to Microsoft, and the agent carries on.

The connection keeps the token in Microsoft’s connection store and renews it while it is in use. After 30 days without renewal, the person signs in again.

• Copilot Studio: the agent's MCP tool
• MCP endpoint: LightHouse, hosted
• Tenant portal: at the tenant's address
• Person: signed in through the identity provider

Discovery and registration

1. Copilot Studio to MCP endpoint: First request, no token
2. MCP endpoint to Copilot Studio: Refused, naming where to sign in. the endpoint's protected-resource document names the portal
3. Copilot Studio to Tenant portal: Register. dynamic registration: an identifier, no secret

Approval

4. Copilot Studio to Tenant portal: Open the approval page. with a PKCE challenge (S256)
5. Tenant portal to Person: Who is asking, where the answer goes, each scope. after sign-in with a second factor
6. Person to Tenant portal: Approve. recorded in the tenant's audit log
7. Tenant portal to Copilot Studio: A single-use code. bound to the client and its redirect
8. Copilot Studio to Tenant portal: Code and verifier for a token. one tenant, one person, the approved scopes

Use

9. Copilot Studio to MCP endpoint: Tool call, with the token. read-only tools
10. MCP endpoint: Checked, then audited. scope and role checked before the tool runs; each knowledge read audited to the person

Copilot Studio discovers the tenant's portal from the endpoint, registers by dynamic client registration without a secret, and opens the portal's approval page for the person. Each tool call then runs as that person, under their role and approved scopes, and is audited.

What you see on the approval page

• Who is asking. Copilot Studio’s answer is sent to Microsoft’s consent service, https://global.consent.azure-apim.net/redirect/.... LightHouse recognises the client by that address and names it Microsoft Copilot Studio, whatever name it registered under.
• Where the answer goes, as an address.
• What it may read, one sentence per scope: telemetry:read, agents:read and knowledge:read. knowledge:read reaches records only if you hold the content_viewer role.

If you decline, Copilot Studio is told access_denied and no connection is made.

Publish to Microsoft 365 Copilot

When the agent works in the Copilot Studio test pane, publish it, then open Channels and add Teams and Microsoft 365 Copilot. Your Microsoft 365 administrator makes the agent available to the people who should have it. Each person still signs in to LightHouse as themselves on first use.

What is audited

The integration changes nothing about what LightHouse records. Each request is checked and recorded exactly as for any other MCP client:

• The approval. Each person’s approval or decline is written to your tenant’s audit log, with the client’s name and the scopes approved.
• Each knowledge read. Every knowledge tool call is audited as a content read by the person who signed in.
• Each refusal. A sign-in refused because the person’s access has been withdrawn is audited.
• The token’s use. Each person’s Settings → Keys → Signed-in tools shows the token, its scopes and when it was last used.

Copilot Studio keeps its own conversation history and analytics under your Microsoft tenant’s settings; LightHouse does not receive them.

Revoke access

A person revokes their own token in Settings → Keys → Signed-in tools; the agent then asks them to sign in again. Withdrawing a person’s access in LightHouse stops their token at once, whatever Copilot Studio holds.

If it does not connect

What you see	What it means
The wizard cannot discover the server	The hosted endpoint is not on for your platform (Availability), or the tenant ID in the address is wrong.
The connection is blocked	A Power Platform data policy blocks the connector. Ask your Power Platform administrator.
The approval page says the request cannot be completed	The sign-in expired, or the address names another tenant. Start it again from the agent.
A tool answers scope_required	The token was not approved for that tool’s scope. Revoke it and sign in again (Scopes, per tool).

See also Connect a client and MCP security.