Connect Cortex to ChatGPT: Automate Governance and Scorecarding

If you are looking to bring your internal developer portal directly into your AI assistant, you need to connect Cortex to ChatGPT. By doing this, you allow your engineering teams and IT admins to diagnose failing scorecards, track service dependencies, and request rule exemptions entirely through natural language. If your team uses Claude, check out our guide on connecting Cortex to Claude or explore our broader architectural overview on connecting Cortex to AI Agents.

Giving a Large Language Model (LLM) read and write access to your engineering system of record is an orchestration challenge. Cortex tracks everything from microservice owners to deployment lifecycles and highly specific security controls. To bridge this gap, you need a Model Context Protocol (MCP) server - a standard interface that translates an LLM's generic tool calls into precise REST API requests against the Cortex backend.

You can either dedicate senior engineering cycles to build, host, and maintain a custom MCP server, or you can use a managed infrastructure layer to dynamically generate a secure, authenticated MCP server URL. This guide breaks down exactly how to use Truto to generate a managed MCP server for Cortex, connect it natively to ChatGPT, and execute complex governance workflows without writing integration boilerplate.

The Engineering Reality of the Cortex API

A custom MCP server is a self-hosted translation layer. While the MCP standard provides a predictable framework for models to discover tools, implementing it against enterprise platforms is tedious. You are not just building a basic CRUD connector; you are building an intelligent agent handler that must respect the nuances of the Cortex architecture.

If you decide to build a custom MCP server for Cortex, you own the entire API lifecycle. Here are the specific integration challenges that make Cortex difficult for AI agents to navigate natively:

The Tag vs UUID Resolution Conundrum Cortex relies heavily on user-defined strings known as tags (e.g., api-gateway-service) alongside internal UUIDs (CIDs) to identify entities across the catalog. Certain endpoints demand tags, while others require UUIDs. If an LLM attempts to query a scorecard using a UUID when the API specifically expects a tag, the request will drop. A custom MCP server must implement mapping logic to resolve and inject the correct identifier type for every single API method, or the LLM will hallucinate failure states.

Asynchronous Scorecard Evaluations Scorecards in Cortex evaluate complex rules against multiple data sources (Git, APM, Cloud providers). When you trigger a scorecard evaluation, the result is not strictly synchronous. If an LLM tries to evaluate an entity score and immediately requests the result in the exact same execution loop, it will often retrieve stale data. Your MCP server must guide the LLM to understand that evaluation endpoints return a 204 No Content response, and the model must wait or poll subsequent endpoints to verify the updated state.

Massive YAML Descriptor Payloads Entities in the Cortex catalog are defined by heavy YAML or OpenAPI descriptors containing metadata, owners, groups, Git links, and Slack channels. When an LLM requests entity details, dumping a 5,000-line OpenAPI spec into the context window will immediately consume token limits and degrade reasoning capabilities. To be effective, the MCP server must filter these payloads, extracting only the relevant fields needed for the specific prompt before handing the response back to the LLM.

The Managed MCP Approach

Instead of forcing your platform engineering team to build a custom server, manage token refreshes, and write JSON schemas for every Cortex endpoint, you can use Truto.

Truto dynamically generates MCP tools based on the active resources and documentation of the underlying integration. When an LLM requests the available tools, Truto maps the Cortex API methods (e.g., list, get, create) into descriptive, snake-case MCP functions with strictly typed query and body schemas. These schemas explicitly instruct the LLM on exactly which parameters are required and how to format them.

A critical note on API rate limits: Cortex enforces rate limiting to protect their infrastructure. Truto does not retry, throttle, or apply backoff logic on rate limit errors. When Cortex returns an HTTP 429 (Too Many Requests), Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller - in this case, ChatGPT or your agent framework - is completely responsible for handling the retry and exponential backoff logic based on those headers.

How to Create the Cortex MCP Server

To expose Cortex to ChatGPT, you must first create the MCP server endpoint. Truto scopes each MCP server to a single integrated account, meaning the generated URL contains a secure cryptographic token tied specifically to your authenticated Cortex tenant.

You can generate this server via the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

For teams who want a zero-code setup, the UI provides a direct configuration path:

1. Log into your Truto dashboard and navigate to your connected Cortex Integrated Account page.
2. Click on the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration. You can filter the server to only expose read methods, or restrict it to specific tags like scorecards or catalog.
5. Click Save. Copy the generated MCP server URL (it will look like https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the Truto API

For platform teams embedding AI capabilities into internal tools, you can dynamically provision MCP servers on the fly using the Truto REST API. This generates a secure token stored in edge KV storage for immediate authentication.

Make a POST request to the /integrated-account/:id/mcp endpoint:

curl -X POST https://api.truto.one/integrated-account/<CORTEX_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Cortex Governance Assistant",
    "config": {
      "methods": ["read", "write"],
      "tags": ["catalog", "scorecards", "workflows"]
    }
  }'

Expected Response:

{
  "id": "9f8d7b6a-5c4d-3e2f-1a0b",
  "name": "Cortex Governance Assistant",
  "config": { 
    "methods": ["read", "write"], 
    "tags": ["catalog", "scorecards", "workflows"] 
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/c9f8a7d6e5b4c3d2e1f0..."
}

Keep this url secure. It acts as the direct JSON-RPC endpoint for your AI agent.

How to Connect the MCP Server to ChatGPT

With your Cortex MCP URL generated, you need to connect it to your ChatGPT interface. You can do this visually in the ChatGPT macOS/web application, or by utilizing a local proxy configuration if you are running custom agent frameworks.

Method 1: Via the ChatGPT UI

ChatGPT allows you to add custom tools via remote MCP URLs natively (Note: this feature requires a Pro, Team, or Enterprise account with Developer mode enabled).

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Toggle Developer mode to the ON position.
3. Scroll down to MCP servers / Custom connectors and click Add new server.
4. Provide a recognizable name (e.g., "Cortex Governance Data").
5. Paste the Truto MCP url you generated in the previous step into the Server URL field.
6. Click Save.

ChatGPT will immediately ping the endpoint, execute an initialize handshake, and request the tools/list. Your agent is now ready to query Cortex.

Method 2: Via Manual Config File (SSE Transport)

If you are using a custom framework or Claude Desktop and prefer file-based configuration, you can wrap the remote Truto URL in a local SSE (Server-Sent Events) proxy.

Update your MCP configuration file (e.g., mcp-servers.json):

{
  "mcpServers": {
    "cortex_governance": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/c9f8a7d6e5b4c3d2e1f0..."
      ]
    }
  }
}

This configuration starts a local process that tunnels standard I/O communication from your agent over HTTP to the Truto edge router.

Cortex Hero Tools for AI Agents

Truto automatically generates highly contextualized tools based on Cortex documentation. Here are the highest-leverage tools available to your ChatGPT agent for governance operations.

list_all_cortex_catalog_entity

Retrieves a complete list of all entities across the Service, Resource, and Domain Catalogs in Cortex. The agent uses this to discover the available services and identify their internal tags.

"List all active microservices in the catalog and output their owner email addresses and primary language tags."

get_single_cortex_scorecard_by_id

Fetches the complete definition of a scorecard, including all rules, levels, exemptions, and passing criteria. This is essential for helping engineers understand exactly why they are failing a specific requirement.

"Fetch the 'Production Readiness' scorecard and explain what the criteria is for achieving the 'Gold' level."

cortex_scorecard_evaluate_entity_score

Triggers an immediate rule evaluation for a specific entity against a designated scorecard. This allows the agent to force a refresh after an engineer claims to have pushed a fix.

"Trigger a score evaluation for the 'payment-gateway' service against the 'Security Baseline' scorecard."

cortex_scorecard_request_exemption

Allows the LLM to submit a formal rule exemption request for a specific entity. The agent can take reasoning provided by a developer in chat and map it directly into the exemption workflow.

"Request an exemption for the 'frontend-proxy' service on the 'Require SonarQube' rule. State that this is a legacy passthrough that does not run custom logic."

cortex_dependency_list_for_entity

Extracts the upstream and downstream architectural dependencies for a specific service. The agent uses this to analyze impact radius during an incident.

"List all upstream dependencies calling the 'user-auth-service'. I need to know which APIs will break if auth goes down."

create_a_cortex_workflow_run

Starts an automated developer workflow directly from chat. This is useful for kicking off scaffolding, remediation scripts, or access requests governed by Cortex.

"Start a new run of the 'Rotate AWS Credentials' workflow for the 'billing-service' entity."

To view the complete schema definitions and the full inventory of available Cortex operations, view the Cortex integration page.

Workflows in Action

Connecting Cortex to ChatGPT transforms static governance data into interactive remediation flows. Here is how specific engineering personas utilize these tools in practice.

Workflow 1: The Scorecard Diagnosis and Exemption

Persona: Platform Engineer

A platform engineer notices their service just dropped to a Bronze rating on the Security scorecard. Instead of digging through the UI to cross-reference rules, they ask ChatGPT to diagnose and resolve the issue.

"Check why my 'checkout-api' service is failing the Security scorecard. If it's the SAST scanning rule, request an exemption for 30 days because we are migrating from Checkmarx to Snyk next month."

Execution Steps:

1. cortex_scorecard_get_scores: The agent fetches the current score for checkout-api on the security scorecard.
2. get_single_cortex_scorecard_by_id: The agent fetches the scorecard definition to map the failing rule identifier to the human-readable SAST scanning requirement.
3. cortex_scorecard_request_exemption: The agent submits the exemption request with the provided business justification, applying it to the exact rule identifier.

Outcome: The agent returns a confirmation that the exemption is pending approval by the security team, sparing the developer from navigating three separate Cortex UI pages.

Workflow 2: Incident Blast Radius Analysis

Persona: Site Reliability Engineer (SRE)

During a Sev-1 incident, an SRE needs to know exactly which downstream systems are going to fail because a core caching layer is unavailable.

"The 'redis-cache-cluster' is down. List all downstream catalog entities that depend on it, and extract the Slack channel for the owning teams so I can page them."

sequenceDiagram
    participant User
    participant Agent as ChatGPT
    participant Truto as Truto MCP
    participant Cortex as Cortex API

    User->>Agent: "Find dependencies for 'redis-cache-cluster' and owner Slack channels."
    Agent->>Truto: call cortex_dependency_list_for_entity
    Truto->>Cortex: GET /api/v1/catalog/redis-cache-cluster/dependencies
    Cortex-->>Truto: Return upstream callers
    Truto-->>Agent: Dependency array
    loop For each caller
        Agent->>Truto: call get_single_cortex_catalog_entity_by_id
        Truto->>Cortex: GET /api/v1/catalog/{caller_tag}
        Cortex-->>Truto: Return entity metadata
        Truto-->>Agent: Entity metadata including Slack channels
    end
    Agent-->>User: Formatted incident report with @mentions

Execution Steps:

1. cortex_dependency_list_for_entity: The agent queries Cortex for all edges pointing to redis-cache-cluster.
2. get_single_cortex_catalog_entity_by_id: The agent iterates through the caller tags to fetch the metadata for each dependent service.
3. Formatting: The agent compiles the slackChannels array from the metadata payloads and presents a formatted incident response list to the user.

Outcome: The SRE gets a prioritized list of impacted services and exact Slack handles to broadcast incident updates, saving critical minutes during mitigation.

Security and Access Control

Giving an LLM access to your internal developer portal requires strict guardrails. Truto's MCP architecture provides several layers of access control out of the box:

• Method Filtering: You can strictly limit the MCP server to read operations. If a user attempts to trick the LLM into deleting a catalog entity, the server lacks the tool entirely, making unauthorized writes impossible.
• Tag Filtering: You can scope an MCP server to specific functional areas using integration tags. For example, you can create a server that only exposes scorecards and workflows, hiding access to custom data webhooks or integration configurations.
• Extra Authentication (require_api_token_auth): For enterprise security, you can enforce secondary authentication. Even if a user discovers the MCP server URL, they must pass a valid Truto API token in the Authorization header to execute tools.
• Time-to-Live (expires_at): You can assign an expiration datetime to the MCP token. This is ideal for granting an external contractor or a temporary AI workflow time-boxed access to Cortex data. Cloudflare KV and durable objects automatically purge the credentials once expired.

Integrating AI with your engineering portal shouldn't require dedicating sprint capacity to API maintenance. By leveraging a managed MCP server, you abstract away the complexities of the Cortex API - from nested entity resolution to standardized HTTP 429 rate limit propagation. This allows your team to focus strictly on building agentic workflows that improve developer productivity, rather than maintaining the pipelines that power them.