Use LightHouse in ChatGPT and OpenAI

View as Markdown

ChatGPT, Codex and applications built on OpenAI’s APIs connect to LightHouse™ as a remote MCP server and call LightHouse’s tools for agents and their runs, usage and cost, and knowledge retrieval from the organisation’s own sources. Each call runs as the person who signed in, or as the machine key that made it, under that identity’s LightHouse role.

Model use. ChatGPT and Codex call LightHouse’s tools over MCP. The agents and the retrieval behind those tools run on the organisation’s deployment, on the model providers connected to LightHouse. OpenAI’s model answers in the ChatGPT or Codex conversation only. A ChatGPT subscription does not run Atlantic agents and is not a model backend for them.

OpenAI product	Connection	Credential
ChatGPT	A custom MCP server	OAuth, at the hosted endpoint
Codex	`config.toml`	OAuth at the hosted endpoint, or a machine key at the portal’s endpoint
An application on the Responses API	The remote MCP tool	An OAuth token at the hosted endpoint, or a machine key at the portal’s endpoint
An application on the OpenAI Agents SDK	`MCPServerStreamableHttp` or `HostedMCPTool`	A machine key at the portal’s endpoint, or an OAuth token

Requirements

Requirement	Detail
Hosted endpoint enabled	Required for every route that signs in with OAuth. The address answers only where Atlantic has enabled the hosted endpoint (Availability).
Tenant ID	The first label of the portal’s address, beginning `t-`.
Machine key (machine-key routes only)	A `viewer` key from Settings → Keys and the tenant’s Access service token (Authentication).

The hosted endpoint, used throughout this page:

https://mcp.atlanticagenticlabs.com/t/<tenant id>/mcp

ChatGPT

LightHouse is added to ChatGPT on the web as a custom MCP server. The ChatGPT workspace’s permissions and security settings apply. If the option to add a custom MCP server is not available, the ChatGPT workspace administrator must enable it.

Add the server

Go to Plugins in ChatGPT (https://chatgpt.com/plugins).
Select +, then Add custom MCP server.
Enter the name LightHouse and a description of what ChatGPT uses it for, for example “Our AI agents, their runs, usage and cost, and search across our knowledge bases.”
Under Connection, enter the hosted endpoint’s address as the Server URL, with the tenant ID in place of <tenant id>.
Under authentication, choose OAuth.

Result: ChatGPT discovers the portal’s OAuth endpoints and registers itself. No client ID or secret is entered or issued.
Review the risk warning and select I understand and want to continue.
Select Create as a plugin, and sign in when prompted (Sign in).

ChatGPT opens the portal’s approval page, https://<tenant id>.atlanticagenticlabs.com/oauth/authorize. If the portal requires it, sign in through the identity provider.
Review the request and select Approve.

Result: the browser returns to ChatGPT and the plugin is connected.

ChatGPT stores the token on OpenAI’s servers and renews it while the plugin is in use. Calls to LightHouse are made from OpenAI’s servers. The person’s browser does not call LightHouse.

ChatGPT: a custom MCP server
MCP endpoint: LightHouse, hosted
Tenant portal: at the tenant's address
Person: signed in through the identity provider

Discovery and registration

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

Approval

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

Use

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

ChatGPT 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.

Approval page

The approval page shows:

The client. ChatGPT’s answer is sent to https://chatgpt.com/connector_platform_oauth_redirect. ChatGPT uses that address because LightHouse names its issuer in every authorisation response (RFC 9207) and ChatGPT checks the issuer against the portal’s address. A connection made through an address under https://chatgpt.com/connector/oauth/ is also recognised. LightHouse recognises the client by that address, names it ChatGPT regardless of the name it registered under, and states that the sign-in is kept on OpenAI’s servers. A client that calls itself ChatGPT but uses any other address is shown with the line stating that LightHouse cannot confirm which application it is.
The return address for the answer.
The scopes, one sentence for each scope the client requested: telemetry:read, agents:read, knowledge:read or billing:read. knowledge:read returns records only to a person who holds the content_viewer role, and billing:read only to a person who holds client_admin.

If the person declines, ChatGPT receives access_denied and no connection is made.

Tools

Enter a question, for example “Which of our agents failed most often this week?” Each LightHouse tool that reads is marked read only (readOnlyHint). ChatGPT asks for confirmation only before an action that writes. The tools available to a delegated token read data only. No tool approves, pays, deploys or changes a limit (Read only, deliberately).

Codex

The Codex CLI, the IDE extension and the ChatGPT desktop app share one configuration file, .codex/config.toml in the user’s home directory.

With OAuth

Add the hosted endpoint to .codex/config.toml:

[mcp_servers.lighthouse]
url = "https://mcp.atlanticagenticlabs.com/t/<tenant id>/mcp"

Run codex mcp login lighthouse.

Result: the browser opens the portal’s approval page.
Confirm that the page shows the expected client and return address, then approve.

Result: Codex stores the token.

Approve the request only if the person approving it started the sign-in from Codex immediately beforehand.

With a machine key

Connect to the portal’s endpoint and read the key and the Access service token from environment variables (AAL_KEY, CF_ACCESS_CLIENT_ID, CF_ACCESS_CLIENT_SECRET; With a machine key):

[mcp_servers.lighthouse]
url = "https://<tenant id>.atlanticagenticlabs.com/mcp"
bearer_token_env_var = "AAL_KEY"
env_http_headers = { "CF-Access-Client-Id" = "CF_ACCESS_CLIENT_ID", "CF-Access-Client-Secret" = "CF_ACCESS_CLIENT_SECRET" }

The file names environment variables and holds no secret values. To offer Codex a subset of tools, add enabled_tools = ["agents", "runs"].

For developers

The Responses API remote MCP tool

With the remote MCP tool, OpenAI’s servers connect to the MCP server, list its tools and call them during a Responses API request. The application does not need an MCP client. The credential is sent to OpenAI with each request and passed from there to LightHouse.

For a person, use the hosted endpoint with a delegated token (lhat-) in authorization, sent with every request. The API does not store the token. The application obtains the token in the same way as any MCP client: register a client, send the person to their portal’s approval page with a PKCE challenge, and redeem the code (Signing in with OAuth). Refresh the token when it expires.

curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6-astra",
    "input": "Which of our agents failed most often this week?",
    "tools": [
      {
        "type": "mcp",
        "server_label": "lighthouse",
        "server_url": "https://mcp.atlanticagenticlabs.com/t/<tenant id>/mcp",
        "authorization": "'"$LIGHTHOUSE_TOKEN"'"
      }
    ]
  }'

For an unattended application, use the portal’s endpoint with a machine key and the Access service token in headers:

import os

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="Summarise this week's failed runs.",
    tools=[
        {
            "type": "mcp",
            "server_label": "lighthouse",
            "server_url": f"https://{os.environ['AAL_TENANT']}.atlanticagenticlabs.com/mcp",
            "headers": {
                "Authorization": f"Bearer {os.environ['AAL_KEY']}",
                "CF-Access-Client-Id": os.environ["CF_ACCESS_CLIENT_ID"],
                "CF-Access-Client-Secret": os.environ["CF_ACCESS_CLIENT_SECRET"],
            },
            "allowed_tools": ["agents", "runs", "usage"],
        },
    ],
)

print(response.output_text)

Approvals. require_approval defaults to "always". The response then carries an mcp_approval_request item, and the application continues with an mcp_approval_response input ("approve": true and the request’s id) and previous_response_id. The tools available to a machine key or a delegated token read data only. With the tools restricted by allowed_tools, "never" is an acceptable setting.
Tool selection. Restrict the tools with allowed_tools.
Response. The server’s tools are listed in an mcp_list_tools item and each call in an mcp_call item, with its output or error. A LightHouse refusal, such as scope_required, is returned as the call’s error.
Key. Issue the application its own labelled viewer key, so that it can be revoked independently of other credentials.

The OpenAI Agents SDK

An agent built on the OpenAI Agents SDK (Python) connects to MCP servers in one of two ways.

From the application’s own process, with MCPServerStreamableHttp. The agent connects from where it runs and can therefore reach the portal’s endpoint with a machine key:

import asyncio
import os

from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp

async def main() -> None:
    async with MCPServerStreamableHttp(
        name="lighthouse",
        params={
            "url": f"https://{os.environ['AAL_TENANT']}.atlanticagenticlabs.com/mcp",
            "headers": {
                "Authorization": f"Bearer {os.environ['AAL_KEY']}",
                "CF-Access-Client-Id": os.environ["CF_ACCESS_CLIENT_ID"],
                "CF-Access-Client-Secret": os.environ["CF_ACCESS_CLIENT_SECRET"],
            },
        },
        cache_tools_list=True,
    ) as server:
        agent = Agent(
            name="Operations",
            instructions="Use the LightHouse tools to answer questions about our agents.",
            mcp_servers=[server],
        )
        result = await Runner.run(agent, "Summarise this week's failed runs.")
        print(result.final_output)

asyncio.run(main())

Through the Responses API, with HostedMCPTool. OpenAI’s servers make the calls, as for the remote MCP tool. The tool is passed in the agent’s tools, and mcp_servers is not used:

import os

from agents import Agent, HostedMCPTool

agent = Agent(
    name="Operations",
    tools=[
        HostedMCPTool(
            tool_config={
                "type": "mcp",
                "server_label": "lighthouse",
                "server_url": "https://mcp.atlanticagenticlabs.com/t/<tenant id>/mcp",
                "authorization": os.environ["LIGHTHOUSE_TOKEN"],
                "require_approval": "never",
            }
        )
    ],
)

Audit

LightHouse checks and records requests from ChatGPT, Codex and OpenAI’s APIs in the same way as requests from any other MCP client:

Event	Record
Approval	Each person’s approval or decline is written to the tenant’s audit log, with the client’s name and the scopes approved.
Knowledge read	Each `knowledge` tool call is audited as a content read by the person who signed in, or by the key that made it.
Refusal	A sign-in refused because the person’s access has been withdrawn is audited.
Credential use	Settings → Keys shows each key’s last use. Settings → Keys → Signed-in tools shows each delegated token, its scopes and its last use.

ChatGPT and OpenAI’s APIs keep their conversation and request records under the settings of the OpenAI account or workspace. LightHouse does not receive them.

Revoke access

Credential	Where to revoke
A person’s delegated token	The person revokes it in Settings → Keys → Signed-in tools. ChatGPT or Codex then asks the person to sign in again.
A machine key	Settings → Keys

When a person’s access is withdrawn in LightHouse, their token stops working immediately, including the copy ChatGPT holds.

Troubleshooting

Symptom	Cause
ChatGPT cannot create or reach the server	The hosted endpoint is not enabled for the platform (Availability), or the tenant ID in the address is wrong.
The option to add a custom MCP server is unavailable	The ChatGPT workspace does not allow custom MCP servers. The workspace administrator controls this setting.
The approval page reports that the request cannot be completed	The sign-in expired, or the address names another tenant. Start the sign-in again from ChatGPT or with `codex mcp login lighthouse`.
The Responses API reports an error listing the server’s tools	The `authorization` token is missing, expired or revoked, or the machine key or Access service token in `headers` is wrong.
A tool returns `scope_required`	The token was not approved for that tool’s scope. Revoke the token and sign in again, approving the scope (Scopes, per tool).
A tool reports that the role does not allow it	The tool requires a role the person does not hold, such as `client_admin` for billing.

See also Connect a client and MCP security.