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)
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/Meridianis 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 (seedocs/extensions.md,server/lib/extensions/): an extension subclassesMeridianExtensionBase, registers via ameridian.extensionsentry point, and can: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)