Skip to content

Connect Aurora Solar to Claude: Manage Sales Proposals and Financing

Learn how to connect Aurora Solar to Claude using a managed MCP server. Automate utility bill OCR, site surveys, and proposal generation with AI agents.

Riya Sethi Riya Sethi · · 9 min read
Connect Aurora Solar to Claude: Manage Sales Proposals and Financing

If you need to connect Aurora Solar to Claude to automate solar design requests, utility bill OCR, financing setups, or proposal generation, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Aurora Solar'sREST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on connecting Aurora Solar to ChatGPT or explore our broader architectural overview on connecting Aurora Solar to AI Agents.

Giving a Large Language Model (LLM) read and write access to a specialized vertical platform like Aurora Solar is a massive engineering challenge. You have to handle OAuth token lifecycles, map massive JSON schemas containing intricate 3D modeling and geographical data to MCP tool definitions, and deal with highly specific asynchronous polling mechanisms. Every time an endpoint updates, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Aurora Solar, connect it natively to Claude, and execute complex solar engineering and sales workflows using natural language.

The Engineering Reality of the Aurora Solar API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against Aurora Solar's APIs is painful. You are not just integrating a standard CRM - you are integrating a platform built around physics engines, geographic information systems, and complex financial models.

If you decide to build a custom MCP server for Aurora Solar, you own the entire API lifecycle. Here are the specific challenges you will face:

Asynchronous Job Polling Many of Aurora Solar's highest-value operations do not return data immediately. Uploading a utility bill for OCR (create_a_aurora_solar_utility_bills_run), converting an order to a project (create_a_aurora_solar_project_creation_run), generating a proposal PDF (create_a_aurora_solar_proposal_pdf_generation_run), and triggering AI roof modeling (create_a_aurora_solar_ai_roof_run) all return a 202 Accepted with a job ID. You must expose both the trigger tools and the polling status tools to the LLM, and explicitly prompt the agent on how to manage this state machine.

Complex Data Hierarchies and State Machines Aurora Solar enforces a strict relational hierarchy: Tenants have Orders and Projects; Projects have Designs and Site Surveys; Designs have System Losses, Racking Arrays, and Financings. If an LLM attempts to generate a proposal for a Design that lacks an accepted EagleView model or pricing rules, the API will reject it. Your AI agent must be context-aware of this state machine to avoid endless error loops.

Rate Limits and Backoff Protocols Aurora Solar enforces strict API quotas to protect its infrastructure from heavy calculation loads. When you hit these limits, the API returns a 429 Too Many Requests status. It is critical to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API returns HTTP 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The caller (your agent or Claude) is strictly responsible for interpreting these headers and executing retry and backoff logic.

Instead of building authentication, schema translation, and protocol wrapping from scratch, you can use Truto to instantly generate a standard JSON-RPC 2.0 endpoint that serves Aurora Solar endpoints as dynamic tools.

How to Generate an Aurora Solar MCP Server with Truto

Truto derives MCP tools dynamically from the API documentation and resource schemas defined in your integration configuration. A tool only appears in the MCP server if it has a corresponding documentation entry, ensuring the LLM only sees curated, well-described endpoints.

Each MCP server is scoped to a single integrated account. The server URL contains a cryptographically hashed token that encodes the account credentials, applied tool filters, and optional expiration dates. The URL alone is enough to authenticate and serve tools - no extra client-side configuration is needed.

You can create this server in two ways.

Method 1: Via the Truto UI

  1. Navigate to the integrated account page for the connected Aurora Solar instance.
  2. Click the MCP Servers tab.
  3. Click Create MCP Server.
  4. Select your desired configuration. You can filter by methods (e.g., only read operations) or apply tag filters (e.g., only expose endpoints tagged for sales).
  5. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4e5f6...

Method 2: Via the API

For automated deployments, you can provision MCP servers programmatically. Submit a POST request to the /integrated-account/:id/mcp endpoint. The Truto engine verifies that tools exist for the requested configuration, generates a secure token, provisions the required KV storage mappings, and returns a ready-to-use URL.

// POST https://api.truto.one/integrated-account/<integrated_account_id>/mcp
 
{
  "name": "Aurora Solar Sales Desk Agent",
  "config": {
    "methods": ["read", "write"], 
    "tags": ["orders", "proposals", "projects"]
  },
  "expires_at": "2026-12-31T23:59:59Z"
}

The response returns the tokenized URL that you will feed to Claude.

How to Connect the MCP Server to Claude

Once you have the Truto MCP URL, connecting it to Claude requires zero additional code. All communication happens over HTTP POST with JSON-RPC 2.0 messages.

Method A: Via the Claude UI

If you are using the desktop or web interfaces that support custom connectors:

  1. Open Settings -> Integrations (or Connectors depending on your client version).
  2. Click Add MCP Server (or Add custom connector).
  3. Paste the Truto MCP URL and click Add. Claude will immediately call the tools/list protocol method to dynamically discover all available Aurora Solar operations.

Method B: Via Manual Config File (Claude Desktop)

For local development or headless deployments, you configure Claude Desktop by modifying the claude_desktop_config.json file. You will use the standard @modelcontextprotocol/server-sse transport to connect to the remote URL.

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

Restart Claude Desktop. The application reads the config, connects to the Truto router, and registers the endpoints as function calling tools.

Aurora Solar Hero Tools

When Claude lists the tools available on the Aurora Solar MCP server, it parses query and body schemas dynamically. Truto automatically injects required context - such as instructing the model to pass next_cursor values unchanged for pagination.

Here are the highest-leverage tools available for your AI agents.

get_single_aurora_solar_tenant_project_by_id

Retrieves the full context of a project, including location, status, owner, and associated customer details. This is the foundational lookup step before generating designs or site surveys.

"Look up the details for project ID 98765432-abcd-efgh-ijkl-1234567890ab and tell me if the status is ready for a design request."

create_a_aurora_solar_utility_bills_run

Uploads a binary utility bill document (PDF, JPG, PNG) and initiates an asynchronous OCR parsing job. The agent must pass the project_id and the file data, then capture the resulting job_id.

"Upload this PDF utility bill to project ID 98765432 and trigger the OCR parse. Let me know the job ID so we can track it."

list_all_aurora_solar_utility_bills_status

Polls the status of a utility bill OCR run. The agent must use this tool repeatedly until the status returns as succeeded or failed.

"Check the status of utility bill parse job ID 112233. If it is completed, extract the monthly energy consumption values."

list_all_aurora_solar_design_bill_summaries

Retrieves the estimated year-1 bill summary for an Aurora Solar design, calculating energy optimization products, PV system generation, and storage capacity against the utility rates.

"Get the design bill summary for design ID 554433 and tell me what the estimated lifetime savings look like against the current utility rate."

create_a_aurora_solar_proposal_pdf_generation_run

Triggers an asynchronous PDF generation job for the default sales proposal attached to a design. Returns a job ID that must be polled for completion.

"Run the proposal PDF generation for design ID 554433. Check the status and give me the secure download URL once it is ready."

create_a_aurora_solar_tenant_site_survey

Creates a new site survey for a project, dispatching a request for field engineers to capture roof mounting planes, electrical panels, and structural photos.

"Create a new site survey for project ID 98765432, and note that the main electrical panel is located on the north side of the garage."

Note: This is just a subset of the available endpoints. For the complete tool inventory and JSON schema structures, visit the Aurora Solar integration page.

Workflows in Action

AI agents excel at orchestrating multi-step API sequences that normally require a human to click through multiple screens. Here is how Claude handles complex Aurora Solar workflows using the MCP server.

Scenario 1: Automated Sales Proposal Pipeline

An internal sales rep drops an order ID into the chat and asks Claude to fast-track the proposal generation for a waiting customer.

"Take order ID 445566, convert it into a project, wait for the project to generate, and then trigger the proposal PDF generation. Give me the final download URL."

Tool Execution Sequence:

  1. create_a_aurora_solar_project_creation_run - Claude passes the order ID to start the async project generation.
  2. list_all_aurora_solar_project_creation_status - Claude polls the returned job ID until the project is confirmed.
  3. create_a_aurora_solar_proposal_pdf_generation_run - Using the newly created design ID, Claude triggers the async proposal generation.
  4. list_all_aurora_solar_proposal_pdf_generation_status - Claude polls this job until success.

Result: The sales rep receives a direct, short-lived PDF download link to the final solar proposal, skipping minutes of manual UI navigation and loading screens.

Scenario 2: Engineering & Site Survey Orchestration

An operations manager needs to advance a project from the initial AI design phase into physical engineering review.

"Review project ID 998877. If the EagleView design request is complete, accept it to generate the 3D model, and then immediately dispatch a site survey for the field team."

sequenceDiagram
    participant User as Operations Manager
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Router
    participant Aurora as Aurora Solar API

    User->>Claude: "Review project... accept EagleView... dispatch survey"
    Claude->>Truto: Call get_single_aurora_solar_design_requests_eagleview_by_id
    Truto->>Aurora: GET /eagleview_requests/:id
    Aurora-->>Truto: Status: "completed"
    Truto-->>Claude: Tool result (JSON)
    Claude->>Truto: Call create_a_aurora_solar_accept
    Truto->>Aurora: POST /eagleview_requests/:id/accept
    Aurora-->>Truto: 200 OK (3D Model Generated)
    Truto-->>Claude: Tool result (Success)
    Claude->>Truto: Call create_a_aurora_solar_tenant_site_survey
    Truto->>Aurora: POST /site_surveys (Project ID)
    Aurora-->>Truto: 201 Created (Survey ID)
    Truto-->>Claude: Tool result (Survey dispatched)
    Claude-->>User: "The EagleView model is generated and the site survey is dispatched."

Tool Execution Sequence:

  1. get_single_aurora_solar_design_requests_eagleview_by_id - Claude checks the status of the requested 3D model.
  2. create_a_aurora_solar_accept - Claude accepts the model, instructing Aurora Solar to lock it in and generate the design files.
  3. create_a_aurora_solar_tenant_site_survey - Claude creates the survey request attached to the parent project ID.

Result: The project seamlessly transitions from an accepted 3D design to an active field survey without human intervention.

Security and Access Control

Giving AI agents direct write access to a platform that manages financing, structural engineering data, and customer PII requires strict guardrails. Truto's MCP architecture provides several layers of control:

  • Method Filtering: When generating the server, you can restrict access to specific operation types. Setting methods: ["read"] ensures the agent can only execute GET and LIST requests (e.g., retrieving bill summaries), preventing accidental deletions or unwanted order approvals.
  • Tag Filtering: Limit the tool surface area by business domain. Setting tags: ["sales"] will only expose endpoints related to orders, tenants, and proposals, hiding deep engineering configurations (like racking components or system losses).
  • Secondary Authentication (require_api_token_auth): By default, possessing the MCP URL grants access. Enabling this flag forces the client to also pass a valid Truto API token in the Authorization header, meaning the URL alone cannot be exploited if leaked in logs.
  • Automatic Expiration (expires_at): You can configure MCP servers to self-destruct. Truto uses distributed scheduling to automatically purge the token and all associated KV references when the timestamp is reached, ensuring short-lived access for contractors or temporary AI audit agents.

Shift From Building Infrastructure to Orchestrating Logic

Building a robust connection to Aurora Solar requires managing complex asynchronous workflows, nested JSON structures, and strict geographic data validation. If you spend your sprint cycles writing OAuth handlers and parsing custom fields, you are not building value.

By leveraging Truto's dynamic MCP server generation, your AI agents gain immediate, type-safe access to the entire Aurora Solar REST ecosystem. You stop worrying about infrastructure and start architecting high-leverage workflows - automating proposals, parsing utility bills at scale, and orchestrating complex solar designs.

FAQ

How do AI agents handle Aurora Solar's async jobs?
Aurora Solar uses asynchronous jobs for tasks like PDF generation and utility bill OCR. Your AI agent must invoke the job creation tool, capture the returned job ID, and poll the respective status tool until completion.
How are API rate limits managed between Claude and Aurora Solar?
Truto passes HTTP 429 Too Many Requests errors directly to the caller, normalizing the upstream rate limit data into IETF standard headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The AI agent must implement its own retry and backoff logic.
Can I restrict which Aurora Solar endpoints Claude can access?
Yes. When generating the MCP server, you can apply method filters (e.g., 'read', 'write') and tag filters to restrict tool exposure, or use require_api_token_auth for secondary authentication.

More from our Blog