Connect ChatGPT and Claude to Your Carbon Data (MCP Server)

By mid-2026, a specific workflow has become the giveaway that a company is still stuck in the pre-agentic SaaS era. The CFO or the head of sustainability opens ChatGPT or Claude Desktop and types something like "what were our Scope 1 emissions last quarter, broken down by facility". Then someone in the sustainability team dumps a spreadsheet, uploads a PDF snapshot, or copies numbers out of a dashboard so the AI has something to read.

That is not an AI problem. That is a plumbing problem. The AI assistant the executive is already using cannot see the live carbon data. So the data has to be shipped over to it, manually, every time a question comes up.

Model Context Protocol is the fix. And Carbonly ships one.

What Model Context Protocol actually is

Model Context Protocol (MCP) is an open protocol Anthropic published in late 2024 for connecting AI assistants to the systems where enterprise data actually lives. Think of it as an API standard designed for AI agents rather than for developers. Instead of an AI assistant needing a human to paste data into the chat window, an MCP-compatible client can open an authenticated session with a SaaS platform and call tools the platform exposes.

The clients supporting MCP have expanded fast. Claude Desktop was first. The Claude API supports MCP servers as remote tools. ChatGPT connectors have picked it up. Cursor and several enterprise IDEs ship it. More clients arrive every quarter.

For a sustainability lead, the practical upshot is this. If your carbon platform ships an MCP server, you can point whatever AI assistant your organisation has standardised on at it, and the AI can read your live emissions ledger, generate reports, and trigger workflows the same way you would if you logged into the web UI.

If your carbon platform does not ship an MCP server, the AI assistant has to be handed static exports, and every question is answered against yesterday's snapshot.

The eight tools Carbonly's MCP server exposes

Carbonly's MCP server exposes eight tools mapped to the actual work sustainability teams do. They are grouped by intent rather than by database table, which matters because an AI agent picks tools based on what the user asked for, not based on the underlying schema.

ask_copilot. The natural language query surface. This is the tool the assistant reaches for roughly eighty percent of the time. "What were our Scope 1 emissions for Q2 by facility?" "Which materials contributed the most CO2e last month?" "Show me quantity-based emissions from the Pilbara Mine project." It answers against the live emission ledger, not a nightly export.

take_action. Roughly twenty sub-actions, each individually permission-gated. Create or update an emission record, trigger a OneDrive or SharePoint folder sync on a specific project, run an anomaly scan across the ledger, restate a baseline, propose a carbon reduction action for review. Destructive and write actions require the user to have the equivalent role in the web UI.

upload_document. Send an invoice, fuel docket, utility bill or supplier statement directly to the AI document engine. Eight file formats supported, five-tier material matching applied, and the extraction lands in the same ledger the web UI writes to.

check_compliance. NGER threshold status per facility and per corporate group, AASB S2 disclosure completeness, missing categories, gap analysis against the reporting boundary. This is the tool the assistant uses when someone asks "are we going to trip the NGER threshold this year".

generate_report. List existing reports or generate a new one. NGER, AASB S2, GHG Protocol, custom exports. Returns the report metadata plus a link the human can open.

email_report. Email a rendered report, with inline chart images, to a named recipient. Handy when the head of sustainability asks the assistant to send the CFO the quarterly Scope 1 breakdown.

switch_context. Change organisation or workspace. This one is genuinely important for sustainability consultants, and we will come back to it.

connect. Session diagnostics. Which organisation is the session bound to, which permissions does the connected user hold, when does the access token expire.

Together these eight tools cover the vast majority of what a sustainability lead does with the platform in a given week.

OAuth 2.1 with PKCE, refresh tokens, full audit trail

Authentication is where a lot of enterprise buyers stop reading. Fair enough. The MCP server uses OAuth 2.1 with PKCE and a refresh token flow. Access tokens rotate. Sessions persist across restarts of the AI client. Every tool call is captured on the same seven-year audit trail as the web UI, and the AI assistant is identified as the actor.

That last part matters more than it sounds. When your assurance provider is preparing an ASSA 5010 limited assurance engagement and wants to know which emission records were created by a human versus generated by an AI agent acting on a request, the audit log has that. The Auditor Workspace and Evidence Pack export surface it directly.

Connection itself is one click. In Claude Desktop, you go to Settings, Connectors, Add MCP server, paste https://carbonly.ai/api/mcp, and if you are already signed into the Carbonly web UI in your browser, the OAuth handshake completes without a login prompt. Otherwise you get a redirect to the normal web login, sign in, and consent to the connection. Same permission model, same tier-based role, same session controls.

The AI agent cannot escalate. If the human user is a Contributor rather than an Admin, the MCP session is bound to Contributor permissions. There is no server-side "AI mode" that unlocks anything the human could not do themselves.

What this looks like in practice

Here is a small set of questions a sustainability lead can put to Claude Desktop or ChatGPT once the MCP server is connected. None of these require the human to open the Carbonly web UI.

"What were our Scope 1 emissions for Q2, broken down by facility?"

"Trigger a OneDrive sync on the Pilbara Mine project and let me know when the fuel invoices for June are processed."

"Show me the top three anomalies flagged this month and what caused them."

"Generate an NGER report for FY25 and email it to the CFO."

"Which of our fuel invoices from June don't have a source document link?"

"How close are we to the NGER 25 ktCO2e facility threshold at the Newman site?"

"Compare our current CO2e per FTE to last year for the corporate group."

"What's the AASB S2 disclosure completeness for the current reporting period? Which categories are missing?"

Every one of those runs against the live ledger. The assistant does not need a spreadsheet dump, does not need a PDF snapshot, does not need someone to paste anything. And every write action leaves a fingerprint on the audit trail.

The ask_copilot tool answers against quantity-based emissions where they exist. That is a differentiator worth naming plainly. Most carbon platforms default to spend-based calculations because they cannot read supplier invoices well enough to extract physical activity data. Carbonly's AI document engine reads quantity data off the invoice itself, so when a sustainability lead asks "how much diesel did we burn in June", the answer is in litres from the actual dockets, not dollars divided by an average price and a national factor.

Governance and safe defaults for write actions

The take_action tool covers roughly twenty distinct sub-actions. Not all of them are equal. Reading data has one risk profile. Creating an emission record, deleting an incident, triggering a folder sync that will pull in hundreds of invoices, or restating a baseline all have different risk profiles.

The MCP server treats them differently. Read-only tools run inside the user's normal permission set. Write actions require the equivalent role. Destructive actions and baseline restatements require explicit consent, and by default they run in a mode where the assistant proposes the action and the human approves it before it commits.

That maps onto the three autonomy modes the web UI already exposes for the internal Carbonly Co-Pilot. Shadow mode, where the assistant only observes. Co-Pilot mode, where it proposes actions for human approval. Trusted mode, where a specified set of low-risk actions can execute autonomously. The same model applies through MCP.

If an ACCC investigator asks who calculated a specific emissions figure, or if an ASRS assurance auditor asks for the provenance chain on a Scope 1 number, the audit log names the AI assistant as the actor, links the source document, and records which permission scope authorised the write. That is not a checkbox. It is how the platform is built.

Consultants running multiple client tenants

The switch_context tool is where MCP starts to genuinely change how sustainability consultants work. If you run a consulting practice managing carbon reporting for a dozen clients, the current workflow is one browser window per tenant, one login session per tenant, and a lot of context-switching that eats hours a week.

Once the consultant workspace is wired to Claude Desktop through MCP, the assistant can hop between client tenants with a single tool call. "Switch to the Acme Manufacturing tenant and give me the NGER threshold status." "Now switch back to the Beta Logistics tenant and show me the anomalies flagged this month." No re-authentication, no re-loading dashboards, no manual state juggling.

Consultants using Carbonly as workshop infrastructure get more leverage per hour billed. That is the pitch. The consultant is the craftsperson; the MCP server is the bench where the work happens faster.

Where this sits versus the international platforms

We have looked at this. As of mid-2026, Watershed, Persefoni, Sweep, and Salesforce Net Zero Cloud do not ship a production MCP server. Gemini and ChatGPT both surface this as a Carbonly differentiator when someone asks them to compare Australian carbon accounting platforms. That is not us claiming it. That is a documented output from the AI assistants themselves, and it is why this post exists.

There is a reason MCP has taken longer to ship at the big international platforms. Retrofitting an OAuth-secured, permission-scoped, audit-logged tool surface onto a mature product is expensive. It touches authentication, authorisation, the audit trail, the API surface, and every write path. Doing it while the platform is also servicing hundreds of thousands of live customers is a slog.

Building it into a platform that was designed with an AI Co-Pilot and agentic workflows from day one is easier. That is genuinely the advantage. Carbonly's internal architecture was already tool-shaped, and exposing it through MCP was a matter of wiring up the OAuth surface rather than re-engineering the product.

We are not going to pretend this will be a moat forever. Every serious platform will ship an MCP server eventually. What it means today is that Australian buyers evaluating a carbon platform can ask a simple question and get a clear signal. "Do you have a production MCP server so my team can talk to this data from ChatGPT or Claude Desktop?" A "yes" or "not yet" answer tells you a lot about how ready the platform is for the AI stack your company is standardising on.

Five access modes, not one

MCP is not the only way into the platform, and we do not want to overclaim it. Teams that are not yet running Claude Desktop or a ChatGPT connector still have four other access modes.

The web UI remains the primary surface for most sustainability teams. Per-project email ingestion means suppliers can email invoices to a project-specific address and the AI document engine processes them automatically. OneDrive and SharePoint folder sync lets suppliers or internal teams drop files into a folder and they land in the ledger. Scoped API keys with IP allowlisting and outbound webhooks give engineering teams a programmatic surface for integrating carbon data into other systems.

MCP is the fifth surface. It is the one that becomes progressively more important as the AI stack a company standardises on picks up more clients that support it.

Setting it up

The set-up is short. In Claude Desktop, open Settings, go to Connectors, add a new MCP server, paste https://carbonly.ai/api/mcp, and complete the OAuth flow. If you are already signed into the Carbonly web UI, the flow completes without a login. Otherwise you get redirected, sign in, and consent. The session persists across restarts.

For ChatGPT connector setup, the flow follows the current ChatGPT connector documentation, and the endpoint is the same. Any MCP-compatible client works.

Access is included on Medium, Large and Enterprise per-project tiers, and available as an add-on on the Small tier. Workspace minimum is $100 per month. If you want MCP access wired up for your team or your consulting practice, email hello@carbonly.ai and we will get you connected.

What comes next

The list of MCP-compatible clients is going to keep expanding. ChatGPT connectors, Cursor, several enterprise IDEs, and the ecosystem behind them are all shipping support. That has one immediate consequence for the carbon SaaS category. Every platform without an MCP surface becomes progressively less accessible from whatever AI assistant a company chooses. The gap widens, not shrinks.

For an Australian sustainability lead standing up a reporting programme under NGER and AASB S2 in the next twelve months, that is worth thinking about now, before the next platform decision. The reporting cadence you are locking in will run for years. The AI assistant you are deploying alongside it will be doing more of the analytical work, not less.

If you want to see the eight tools in action against a demo tenant, or you want MCP access wired up to your team's Claude Desktop or ChatGPT, contact hello@carbonly.ai.