Connect Aurora Solar to ChatGPT: Manage Solar Designs and Projects

You want to connect Aurora Solar to ChatGPT so your AI agents can read project specs, update order statuses, extract data from utility bills, and trigger automated roof designs. If your team uses Claude, check out our guide on connecting Aurora Solar to Claude or explore our broader architectural overview on connecting Aurora Solar to AI Agents.

Solar engineering and sales teams lose thousands of hours annually transferring data between CRMs, design software, and financial modeling tools. The mandate to automate these operations is clear, but giving a Large Language Model (LLM) read and write access to a sprawling, engineering-heavy ecosystem like Aurora Solar is a massive technical challenge.

You either spend weeks building, hosting, and maintaining a custom Model Context Protocol (MCP) server, or you use a managed infrastructure layer that handles the boilerplate for you. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Aurora Solar, connect it natively to ChatGPT, and execute complex solar engineering workflows using natural language.

The Engineering Reality of the Aurora Solar API

A custom MCP server is a self-hosted integration layer that translates an LLM's tool calls into REST API requests. While Anthropic's open standard provides a predictable way for models to discover tools over JSON-RPC, the reality of implementing it against vendor APIs is painful.

If you decide to build a custom MCP server for Aurora Solar, you own the entire API lifecycle. You are dealing with highly technical, domain-specific endpoints that break standard CRUD assumptions. Here is exactly what makes the Aurora Solar API uniquely difficult to wrap into LLM-friendly tools.

The Asynchronous Polling Trap

Most standard APIs return immediate synchronous responses. Aurora Solar handles heavy computational workloads - generating AI roof models, running PDF proposal engines, and executing Optical Character Recognition (OCR) on utility bills. When you call these endpoints, you do not get the result. You get a 202 Accepted status and a job_id.

An LLM does not inherently understand asynchronous state machines. If your MCP server just passes the 202 response back, the LLM will assume the design is finished and hallucinate the details. You must build specific status-checking tools into your MCP server and explicitly instruct the LLM: "When you receive a job_id, you must poll the status tool repeatedly until it returns a completed state before proceeding."

Complex Geographical and Geometric Payloads

Creating a design request in Aurora Solar is not like creating a text note in a CRM. Endpoints like EagleView design requests require strict, co-dependent arrays of geographic data - latitude and longitude must be perfectly paired, and roof pitches must align with exact obstruction counts. If your MCP server's JSON schema is even slightly loose, the LLM will attempt to pass malformed geographic objects, causing raw validation errors that confuse the model and break the loop.

Multipart Uploads and Binary Conversions

Solar workflows require heavy document management - uploading site survey photos, partner logos, and utility bills. The API expects raw binary image data for some endpoints and multipart form data for others, explicitly enforcing MIME types (e.g., converting JPGs to WebP on upload). LLMs cannot natively construct multipart binary payloads. Your MCP server must act as a translation layer, taking standard file references or base64 strings from the LLM and converting them into the exact byte streams Aurora Solar expects.

Transparent Rate Limit Handling

Aurora Solar enforces standard API rate limits to protect infrastructure. Handling these limits in an AI context requires careful architectural decisions.

A factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API like Aurora Solar returns an HTTP 429 Too Many Requests error, 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 spec. The caller - whether that is a custom script orchestrating the LLM, or the LLM's internal execution loop - is strictly responsible for implementing its own retry and backoff logic. Do not expect the integration layer to magically absorb rate limit errors.

Creating the Aurora Solar MCP Server

Instead of building a server from scratch, you can dynamically generate a managed MCP server using Truto. Truto derives tool definitions directly from the Aurora Solar API schemas, injecting necessary metadata (like pagination cursors and descriptive constraints) so ChatGPT understands exactly how to format its requests.

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

Option 1: Via the Truto UI

If you prefer a visual interface, you can generate the server directly from your connected Aurora Solar account:

1. Navigate to the Integrated Accounts page in the Truto dashboard.
2. Select your active Aurora Solar connection.
3. Click on the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (name, allowed methods, tags, and expiration).
6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Option 2: Via the API

For engineering teams building automated provisioning pipelines, you can generate the MCP server programmatically. This validates that tools exist, generates a secure cryptographic token, stores it in an edge key-value store, and returns a ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Aurora Solar ChatGPT Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The response returns the secure URL that ChatGPT will use to connect:

{
  "id": "abc-123",
  "name": "Aurora Solar ChatGPT Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

This URL is fully self-contained. The token encodes the exact integrated account and tool filters, requiring zero extra configuration on the client side.

Connecting the MCP Server to ChatGPT

Once you have your Truto MCP URL, connecting it to ChatGPT takes seconds.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode (MCP support requires this flag, available on Pro, Plus, Business, Enterprise, and Education accounts).
3. Under MCP servers / Custom connectors, click Add a new server.
4. Name: Give it a recognizable name like "Aurora Solar (Truto)".
5. Server URL: Paste the Truto MCP URL you generated above.
6. Click Save.

ChatGPT will immediately ping the endpoint, execute the JSON-RPC initialize handshake, and fetch the list of available Aurora Solar tools.

Method B: Via Manual Config (SSE Transport)

If you are using a custom multi-agent framework or a local wrapper that connects to ChatGPT's APIs, you can configure the server using the standard Server-Sent Events (SSE) transport adapter.

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

Hero Tools for Aurora Solar

Truto automatically generates a comprehensive suite of tools based on the Aurora Solar API. Exposing every tool to an LLM at once can overwhelm its context window, so it is best practice to filter the MCP server to the exact operations your persona needs. Here are the highest-leverage hero tools for solar workflows.

create_a_aurora_solar_tenant_design_request

Initiates a new remote design request for a project. This requires geographic coordinates and basic site context.

Usage Note: This triggers a state machine. The returned design request will be in a draft or submitted status and must be monitored by the team or agent.

"I need a new design request for project ID prj_8899. The address is 123 Solar Way, Austin, TX. Set the roof pitch to 20 degrees and note that it is a 2-story building. Create the request now."

create_a_aurora_solar_ai_roof_run

Triggers Aurora Solar's AI engine to automatically detect and map roof planes, obstructions, and pitch from aerial imagery.

Usage Note: This is an asynchronous job. It returns a job_id. You must explicitly instruct ChatGPT to take that ID and poll the list_all_aurora_solar_ai_roof_status tool until completion.

"Trigger an AI roof generation job for design ID dsn_4455. Once you receive the job ID, check the status endpoint every few seconds. Do not stop until the job status returns as 'succeeded', then summarize the roof geometry for me."

list_all_aurora_solar_design_racking_arrays

Retrieves the highly technical racking array data for a specific design. This includes adjacent arrays, rotation, pitch, azimuth, and ground-mounted classifications.

Usage Note: Crucial for engineering audits. The LLM can analyze this data to ensure the array layout meets specific local zoning regulations or spacing requirements.

"Fetch the racking array details for design ID dsn_4455. Audit the azimuth and tilt data across all arrays. Flag any arrays that are ground-mounted or have an azimuth outside of the optimal 160-200 degree range."

create_a_aurora_solar_utility_bills_run

Uploads a utility bill document to a project and starts an asynchronous OCR process to parse monthly usage, tariffs, and demand profiles.

Usage Note: Another async polling endpoint. The file upload requires strict adherence to supported MIME types (PDF, JPG, PNG). The LLM will need access to a file reading tool alongside this tool to execute the upload.

"Take the utility bill PDF located in the project folder and upload it to project ID prj_8899 to trigger an OCR run. Poll the bill status endpoint with the resulting job ID, and when finished, output the parsed year-1 energy consumption estimates."

update_a_aurora_solar_tenant_order_by_id

Updates the lifecycle phase of a sales order, moving a prospect from an initial lead through to a sold contract or declining them due to disqualification.

Usage Note: Used by sales agents to maintain CRM hygiene directly through chat.

"Update order ID ord_1122. Change the phase to 'contract_signed' and add a note stating that the customer accepted the updated 85% energy offset proposal."

For the complete inventory of available tools, including detailed JSON schemas, required parameters, and pagination logic, view the Aurora Solar integration page.

Workflows in Action

Giving ChatGPT isolated tools is helpful, but the real power of MCP is chaining these tools together to execute complex, multi-step workflows.

Scenario 1: The Automated Sales Update

Sales reps often waste time hopping between their inbox, CRM, and Aurora Solar to update project statuses after a call. An AI agent can handle this natively.

"Look up order ID ord_9900 for John Doe. We just got off a call, and his roof is heavily shaded by ancient oaks - he is disqualified. Mark the order as declined, set the disqualification reason to 'Severe shading', and summarize the final state of the order."

Step-by-step execution:

1. ChatGPT calls get_single_aurora_solar_tenant_order_by_id to verify the order details and current phase.
2. ChatGPT calls create_a_aurora_solar_order_decline, passing the order_id and the disqualified_reason payload.
3. The agent reads the final returned object and generates a brief summary confirming the order is officially closed in the system.

Scenario 2: The Engineering Design Automation Pipeline

When a site survey is completed, engineers need to generate a 3D roof model and extract the bill of materials. By chaining async tools, ChatGPT acts as an autonomous design assistant.

"Start an AI Roof generation job for design ID dsn_5566. Monitor the job status until it completes. Once it is successful, pull the roof summaries and the racking arrays, and give me a brief technical audit of the module layout."

sequenceDiagram
    autonumber
    participant User as User Prompt
    participant ChatGPT as ChatGPT
    participant Truto as Truto MCP Server
    participant Upstream as Upstream API (Aurora Solar)

    User->>ChatGPT: Start AI Roof job for dsn_5566 & audit
    ChatGPT->>Truto: call create_a_aurora_solar_ai_roof_run
    Truto->>Upstream: POST /designs/dsn_5566/ai_roof_runs
    Upstream-->>Truto: 202 Accepted (job_id: job_abc)
    Truto-->>ChatGPT: Returns job_id
    
    rect rgb(235, 232, 226)
    Note right of ChatGPT: LLM Polling Loop
    ChatGPT->>Truto: call list_all_aurora_solar_ai_roof_status (job_abc)
    Truto->>Upstream: GET /designs/dsn_5566/ai_roof_runs/job_abc
    Upstream-->>Truto: status: "in-progress"
    Truto-->>ChatGPT: status: "in-progress"
    
    ChatGPT->>Truto: call list_all_aurora_solar_ai_roof_status (job_abc)
    Truto->>Upstream: GET /designs/dsn_5566/ai_roof_runs/job_abc
    Upstream-->>Truto: status: "succeeded"
    Truto-->>ChatGPT: status: "succeeded"
    end

    ChatGPT->>Truto: call list_all_aurora_solar_design_roof_summaries
    Truto->>Upstream: GET /designs/dsn_5566/roof_summary
    Upstream-->>Truto: Returns JSON Geometry
    Truto-->>ChatGPT: Returns JSON Geometry
    ChatGPT-->>User: Outputs technical audit

Step-by-step execution:

1. ChatGPT calls create_a_aurora_solar_ai_roof_run and receives a job_id.
2. It enters a reasoning loop, calling list_all_aurora_solar_ai_roof_status repeatedly until it sees the succeeded state.
3. Upon success, ChatGPT calls list_all_aurora_solar_design_roof_summaries to analyze the generated pitch, azimuth, and obstruction metrics.
4. Finally, it calls list_all_aurora_solar_design_racking_arrays and formats a clean, human-readable summary for the engineer.

Security and Access Control

Exposing an enterprise instance of Aurora Solar to an AI model requires strict governance. If an LLM hallucinates a command, it could accidentally overwrite a finalized design. Truto's MCP architecture provides several layers of control directly embedded in the token URL:

• Method Filtering: Limit the server strictly to read-only operations. By passing config: { methods: ["read"] } during creation, you guarantee the LLM can fetch roof summaries and racking arrays, but physically cannot trigger jobs or alter order states.
• Tag Filtering: Group tools by functional area. If a support agent is using ChatGPT, you can restrict their server to tools tagged support or orders, hiding sensitive financial tools.
• API Token Authentication: By default, the MCP URL authorizes requests based on its embedded hash. By setting require_api_token_auth: true, the client (ChatGPT or custom framework) must also send a valid Truto API token in the header. This ensures that even if the URL leaks in a log file, it cannot be used without valid user credentials.
• Time-to-Live (TTL) Expiration: Create temporary access tokens for contractors or ephemeral testing loops. Set the expires_at property to an ISO datetime; a distributed scheduling primitive will automatically revoke access and clean up the keys when the time arrives.

Moving Past Manual Solar Ops

Connecting Aurora Solar to ChatGPT completely changes the velocity of your engineering and sales teams. Instead of clicking through complex UI menus to check roof pitch constraints, upload utility bills, or update CRM phases, your team can interact with raw architectural data using natural language.

Building this integration layer yourself means sinking months into handling undocumented async behavior, complex geometric schemas, and rate limit architectures. Using a managed MCP server offloads the protocol handling, letting you focus entirely on crafting the perfect AI prompts.