Explore exposing GAT via MCP / chat-based scenario access

Motivation

It would be useful to discuss GAT scenarios (PLEXOS/Sienna/ReEDS results — dispatch, capacity, unserved energy, etc.) directly in a chat interface like Claude Desktop, instead of always going through a Python script. This issue is to track exploring that, not to commit to an implementation yet — there's a real architectural question to resolve first.

The open question: standalone MCP server vs. a Meridian extension

Two candidate shapes, and they're not obviously compatible:

Option A — GAT ships its own MCP server. Tools like load_scenario, get_area_dispatch, get_area_unserved, plot, etc., exposed directly to any MCP client (Claude Desktop, Claude Code, others).

Option B — GAT becomes a Meridian extension. ~/code/Meridian is explicitly meant to be the unifying interactive interface across grid-related tools, and already has a pip-installable extension architecture built for close to exactly this (see docs/extensions.md, server/lib/extensions/): an extension subclasses MeridianExtensionBase, registers via a meridian.extensions entry point, and can:

• register DuckDB tables that are queryable via SQL by Meridian's own AI chat assistant
• provide AI context (schemas, column descriptions, example queries, prompts injected into the LLM system prompt)
• supply projects/scenarios/datasets, controls, and charts

Meridian already has an example of this shape (extensions/seds). A GAT extension along these lines would get chat-based scenario Q&A "for free" inside Meridian's existing chat UI, without GAT needing its own MCP surface at all — and would avoid ending up as a second, competing chat-driven interface to the same class of data that Meridian is trying to unify.

Why this needs a decision, not just code

Building a standalone GAT MCP server (Option A) is real, non-trivial work, and if Meridian is meant to be the single place users go to talk to grid data conversationally, a parallel GAT-specific MCP server could work against that goal rather than for it. Worth resolving which of these (or some combination — e.g., a thin MCP server that's really just a wrapper delegating to the same query layer a Meridian extension would use) is the right target before writing tool definitions.

Next steps (not yet started)

• Decide: standalone MCP server, Meridian extension, or both sharing a common query layer
• If Meridian extension: scope which GAT capabilities map to DuckDB tables vs. AI-context/prompt injection vs. charts
• If MCP server: scope the tool surface (scenario loading, dispatch/capacity/unserved-energy queries, plotting)

Start by reading docs/extensions.md and the extension implementation under server/lib/extensions/, then inspect the existing extensions/seds example in Meridian. Resolve whether GAT should provide a standalone MCP server, a Meridian extension, or a shared query layer, and define the initial capability scope. Done means the architectural direction and next implementation boundary are agreed.