What can you do with this server?

This server connects Claude Desktop to Snowflake-based energy trading data, enabling plain-English queries without writing SQL. It enforces read-only access (SELECT/WITH only) and supports credentials from a keyring or environment variables. * Portfolio PnL Analysis (get_spread_portfolios): Retrieve PnL summaries for spread trading portfolios over a date range, including total PnL, win rate, and best/worst days. * Spread Trading Breakdown (get_spread_analysis): Detailed PnL breakdowns by trading path (source→sink), book, or book+path, including win rate and Calmar ratio. * Nodal Price Spread (get_nodal_spread): Analyze DA and RT LMP price spreads between two price nodes, with hourly stats, summary statistics, and peak-hour breakdowns. * Price Node Lookup (list_price_nodes): Search for available price nodes by name and filter by ISO (e.g., ERCOT, PJM, MISO, SPP). * List Transmission Constraints (list_constraints): Retrieve all available ERCOT transmission constraint names. * Constraint Loading Analysis (get_constraint_loading): Get hourly max/min loading percentages for a specific ERCOT transmission constraint. * Grid Flow Analysis (get_flow_analysis): View all ERCOT transmission constraint loading for a single date to identify the most congested lines. * Generator Forecast vs. Actual (get_gen_comparison): Compare MUSE forecast vs. Edison actual generation by plant and fuel type, sortable by forecast error magnitude. * Plant-Level Generation Detail (get_gen_detail): Hourly Edison vs. MUSE generation data for a specific plant. * PJM Western Hub Prices (get_pjm_wh): Access PJM Western Hub DA/RT LMP prices and load data with configurable historical comparison days (up to 90). * Bid Segment Tracker (get_segment_tracker): Monitor bid segment submission counts per day and portfolio, filtered by submission status. Performance is optimized via warehouse pre-warming and a TTL cache to reduce query response times.

Which integrations are available for this server?

Provides tools for querying energy trading analytics from Snowflake, including spread portfolios, constraint loading, generator comparisons, and PJM price data.

How do I use durable-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@durable-mcp What was our total PnL last week?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

durable-mcp

by cshah26

Overview Schema Related Servers Score Discussions

TypeScript

Local

durable-mcp

MCP server for Durable energy trading analytics. Connects Claude Desktop to your Snowflake data so traders can ask plain-English questions about spread portfolios, nodal prices, transmission constraints, generator performance, and PJM markets — without writing SQL or opening the right dashboard.

How it works

Trader asks a question in Claude Desktop
          ↓
Claude picks the right tool based on the question
          ↓
MCP server (this repo, runs locally) queries your Snowflake
          ↓
Results come back → Claude reads them → answers the question

Note on data privacy: your trading data (PnL, portfolio names, bid paths) passes through Anthropic's servers as part of the Claude conversation. See Data & Security before using in production.

Related MCP server: redash-mcp

Setup (30 seconds)

1. Add to Claude Desktop

Open your Claude Desktop config file:

Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

Add this block:

{
  "mcpServers": {
    "durable": {
      "command": "npx",
      "args": ["-y", "github:cshah26/Chatbot-MCP"]
    }
  }
}

2. Restart Claude Desktop

That's it. The server reads credentials automatically from the Durable desktop app's keyring — no extra configuration needed if you already have the app installed.

Credential fallback

The server tries credentials in this order:

Durable app keyring — Windows Credential Manager under durable-desktop / snowflake-config. Works automatically if the desktop app is installed.
Environment variables — copy .env.example to .env and fill in:

SNOWFLAKE_ACCOUNT=your_account.region
SNOWFLAKE_USERNAME=your_username
SNOWFLAKE_PASSWORD=your_password
SNOWFLAKE_WAREHOUSE=COMPUTE_WH
SNOWFLAKE_ROLE=READ_ONLY_ROLE

Available tools

Tool	What it does
`get_spread_portfolios`	PnL summary by portfolio — total PnL, win rate, best/worst days
`get_spread_analysis`	Breakdown by path (source→sink), book, or book+path — win rate, avg/day
`get_nodal_spread`	DA and RT LMP spread between two nodes — hourly stats, peak-hour breakdown, day-of-week heatmap
`list_price_nodes`	Search available price nodes by name or ISO
`list_constraints`	List all ERCOT transmission constraint names
`get_constraint_loading`	Hourly max/min loading % for a specific ERCOT constraint
`get_flow_analysis`	All constraint loading for a single date — shows which lines are most at risk
`get_gen_comparison`	MUSE forecast vs Edison actual by plant and fuel type
`get_gen_detail`	Hourly Edison vs MUSE generation for a single plant
`get_pjm_wh`	PJM Western Hub DA/RT LMP prices and load with historical daily averages
`get_segment_tracker`	Bid segment counts by day and portfolio — submitted vs unsubmitted

Example questions

"What was our total PnL last week?"
"Show me the spread between HB_NORTH and HB_SOUTH for July"
"Which constraints were most loaded yesterday?"
"How accurate was MUSE for gas plants this month?"
"What were PJM Western Hub prices on July 10th?"

Performance

What was slow (and what's fixed)

Snowflake warehouse cold start — 10–30s on the first question of the day Snowflake auto-suspends idle warehouses. The server now sends a SELECT 1 immediately on startup — before any trader types anything — so the warehouse is warm and the connection is live by the time the first query arrives.

No caching — every question hit Snowflake live A TTL cache now sits in front of every query:

Data type	Cache TTL
Historical PnL, spreads, constraint loading	3 minutes
Node list, constraint names (static reference data)	1 hour

Repeat questions are served from memory instantly.

Expected response times

Scenario	Before	After
First question of the day	15–35s	1–3s
Same question asked again	3–8s	<100ms
New question, warm warehouse	2–5s	1–3s

Snowflake warehouse tip

Set auto-suspend to 10 minutes in your Snowflake account settings (default is 5) to give more buffer during trading hours. Optionally schedule a SELECT 1 at 6am on trading days to pre-warm the warehouse before traders arrive.

Data & Security

What leaves your network

When a tool runs, the SQL results — PnL numbers, portfolio names, bid paths, generator data — are sent to Anthropic's servers as part of the Claude conversation. This is real trading data: positions, performance, and strategy details.

It does not go anywhere else. The MCP server has no telemetry, no external logging, and no analytics calls beyond Snowflake and Claude.

Anthropic's data policy

	Claude API	Claude.ai (consumer)
Trains on your data	No	Depends on settings
Data retention	Short-term for safety review	Longer
Enterprise agreement / BAA	Available	Not available

Options if your firm has data sensitivity requirements

Option 1 — Claude Enterprise Anthropic's enterprise offering includes a data processing agreement, zero retention, and stricter data handling. Designed for financial firms. The MCP server works unchanged.

Option 2 — Local model Run a local LLM (e.g. Llama 3 via Ollama) instead of Claude. Nothing leaves your network. Tradeoff: local models are less capable. The MCP protocol is identical — only the model endpoint changes.

Option 3 — Data minimization Modify tools to send only aggregated summaries to Claude (totals, averages) rather than raw row data. Claude can still answer most questions but sees less sensitive detail.

Consult your compliance team before using this with live trading data.

Architecture

src/
  index.ts          — entry point: stdout guard, module loading, server setup, pre-warm
  db.ts             — Snowflake connection, TTL cache, query execution, auto-retry
  keyring.ts        — reads credentials from Windows Credential Manager
  tools/
    spread.ts       — get_spread_portfolios, get_spread_analysis
    nodal.ts        — get_nodal_spread, list_price_nodes
    constraints.ts  — list_constraints, get_constraint_loading, get_flow_analysis
    generators.ts   — get_gen_comparison, get_gen_detail
    pjm.ts          — get_pjm_wh
    segments.ts     — get_segment_tracker

Key design decisions

stdout guard Snowflake's SDK (winston) writes logs directly to process.stdout, which would corrupt the MCP JSON-RPC stream. index.ts patches process.stdout.write before any modules load, redirecting anything that isn't a JSON-RPC 2.0 message to stderr. The filter checks for "jsonrpc":"2.0" specifically to avoid false positives.

Read-only enforcement db.ts rejects any SQL that does not start with SELECT or WITH. No writes possible.

Connection auto-retry If the Snowflake connection drops between queries (idle timeout, network reset), the next query transparently resets the connection state and retries once with a fresh connection before surfacing an error to the caller.

Development

npm install
npm run build   # compile TypeScript → dist/
npm start       # run the compiled server

The dist/ directory is committed so npx github:... works without a build step on the consumer side.

Publishing updates

Push to GitHub — team members get the latest automatically on the next Claude Desktop restart:

git add -A && git commit -m "your message" && git push

Changelog

`391cbaf` — fix+perf: resolve 9 code review issues

Bugs fixed

logLevel restored from 'OFF' to 'ERROR' — Snowflake SDK error events (TLS drops, connection resets) are visible on stderr again; the stdout intercept already handled MCP stream safety
Auto-retry on stale connection — if the connection drops between queries, it resets and retries once transparently instead of failing
stdout filter tightened from "jsonrpc" to "jsonrpc":"2.0" — eliminates false positives from any library that logs JSON containing the word "jsonrpc"
Comment corrected: snowflake-sdk uses winston internally, not log4js

Performance

Snowflake connection and warehouse pre-warmed on startup — first question no longer pays 10–30s resume cost
TTL query cache added — repeat questions served from memory; static reference data (node list, constraint names) cached for 1 hour
Dynamic imports parallelised with Promise.all — all 8 tool modules load concurrently at startup

Cleanup

console.error and console.warn overrides removed — dead code (those methods write to stderr internally and never touched stdout)

`3f4f7d2` — fix: intercept process.stdout.write to block snowflake log4js from corrupting MCP stream

`1017fff` — fix: redirect all stdout to stderr to keep MCP protocol stream clean

`f706a7b` — fix: include dist/ in repo so npx github: works without build step

Available Tools

11 tools

get_constraint_loadingA

Get hourly max and min loading percentages for a specific ERCOT transmission constraint over a date range. Use this when asked about constraint loading, line loading, transmission utilization, or how loaded a specific constraint is. Values near 100% indicate the constraint is at or near its limit.

ParametersJSON Schema

Name	Required	Description
`date_to`	Yes	End date in YYYY-MM-DD format
`date_from`	Yes	Start date in YYYY-MM-DD format
`constraint_name`	Yes	Exact constraint name (use list_constraints to find names)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. It explains what the tool returns and that high values indicate near limit, but does not disclose read-only nature, authentication needs, rate limits, or any side effects. Adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first describes the function, second gives usage context and interpretation. No wasted words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only 3 parameters, no output schema, and no annotations, the description covers the essential aspects: what it returns, usage context, and value interpretation. Could mention output format but is sufficient for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description need not add parameter details. It does not provide additional meaning beyond the schema's own descriptions (dates format, constraint name lookup). Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves hourly max and min loading percentages for a specific ERCOT transmission constraint over a date range. It distinguishes from siblings like get_flow_analysis by focusing on 'constraint loading' and transmission utilization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this when asked about constraint loading, line loading, transmission utilization, or how loaded a specific constraint is.' Provides clear context but does not mention when not to use it or alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_flow_analysisA

Get all ERCOT transmission constraint loading for a single date. Shows which constraints are most loaded and at risk of binding. Use this when asked about transmission congestion, binding constraints, or overall grid loading on a specific day.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes	Market date in YYYY-MM-DD format

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains output (most loaded/at risk constraints) but omits behavioral traits like read-only guarantee, pagination, or auth requirements. Adequate for a simple read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: function, outcome, usage context. No extraneous words, well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (one parameter, no output schema, no annotations), the description sufficiently covers purpose, usage, and parameter format. Minor gap: no mention of return value structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'date' with a clear description. The tool description does not add extra meaning beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and resource 'all ERCOT transmission constraint loading for a single date.' It clearly distinguishes from sibling tools like 'get_constraint_loading' by specifying scope and risk assessment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'when asked about transmission congestion, binding constraints, or overall grid loading on a specific day.' However, lacks explicit when-not-to-use or alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_gen_comparisonA

Compare generator forecast vs actual output. Compares MUSE (forecast) vs Edison (actual/IIR) generation by plant and fuel type. Shows average percentage difference — positive means Edison produced more than MUSE forecast. Use this when asked about generator forecasts, forecast accuracy, MUSE vs Edison, plant output, or fuel-type generation.

ParametersJSON Schema

Name	Required	Description	Default
`date_to`	Yes	End date in YYYY-MM-DD format
`sort_by`	No	Sort by: abs_diff (largest error first), diff, or plant name	abs_diff
`date_from`	Yes	Start date in YYYY-MM-DD format
`fuel_type`	No	Filter by fuel type (e.g. GAS, WIND, SOLAR, NUCLEAR)
`plant_name`	No	Filter by specific plant name (partial match)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description must carry full burden. It explains the calculation and data sources but omits behavioral traits like read-only nature, data freshness, or pagination. Adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines purpose, second adds detail on meaning and usage. No fluff, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description lacks detail on return format. It only mentions 'shows average percentage difference'. For a complex tool, more context on output structure would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds example fuel type values and notes partial match for plant_name, but does not significantly enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it compares generator forecast (MUSE) vs actual (Edison) output, specifies the metric (average percentage difference), and explains directionality. This is specific and distinct from siblings like get_gen_detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists when to use: 'when asked about generator forecasts, forecast accuracy, MUSE vs Edison, plant output, or fuel-type generation.' Lacks explicit when-not or alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_gen_detailA

Get hourly Edison vs MUSE generation detail for a specific plant. Use this when asked about a specific plant's hourly output, forecast vs actual for a single plant, or generation time series.

ParametersJSON Schema

Name	Required	Description
`date_to`	Yes	End date in YYYY-MM-DD format
`date_from`	Yes	Start date in YYYY-MM-DD format
`plant_name`	Yes	Exact plant label as shown in MUSE (use get_gen_comparison to find names)

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It indicates a read operation ('Get') and the data type (hourly comparison), but does not explicitly state read-only status, permissions, or potential side effects. The description adds some context but not full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences: the first states the core function, and the second provides usage guidance. No extraneous information, efficiently packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 required params and no output schema, the description covers purpose and usage but lacks details on output structure (fields expected) or limitations. It is minimally adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described in the schema. The description does not add further parameter-specific meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns hourly Edison vs MUSE generation detail for a specific plant, with explicit use cases (hourly output, forecast vs actual, time series). This distinguishes it from sibling tools like get_gen_comparison, which is referenced for finding plant names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: when asked about a specific plant's hourly output, forecast vs actual, or time series. It also indirectly advises against using it for finding plant names by referencing get_gen_comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_nodal_spreadA

Get DA (day-ahead) and RT (real-time) LMP price spread between two price nodes over a date range. Returns hourly spread data, summary statistics, and peak-hour breakdown. Use this when asked about spread between locations, node prices, DA vs RT spread, price differences, or specific source/sink pairs.

ParametersJSON Schema

Name	Required	Description
`date_to`	Yes	End date in YYYY-MM-DD format
`date_from`	Yes	Start date in YYYY-MM-DD format
`sink_node`	Yes	Sink price node name (e.g. HB_SOUTH, LZ_AEN)
`source_node`	Yes	Source price node name (e.g. HB_NORTH, LZ_HOUSTON)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the returned data (hourly spread, summaries, peak-hour breakdown) but does not disclose behavioral aspects like data freshness, rate limits, or authorization needs. With no annotations, the description could add more context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose, and includes usage guidance. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a data retrieval tool with 4 parameters, no output schema, and no annotations, the description adequately explains what it returns and when to use it. Additional detail on return format would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% parameter descriptions. The tool description does not add extra semantic meaning beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves DA and RT LMP price spreads between two nodes over a date range and lists output types. It does not explicitly differentiate from sibling tools like get_spread_analysis but provides use-case examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this when asked about spread between locations...' providing clear context for invocation. However, it does not mention when not to use this tool or suggest alternative siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pjm_whA

Get PJM Western Hub DA/RT LMP prices and load data. Use this when asked about PJM Western Hub prices, PJM WH, Eastern power prices, or PJM load.

ParametersJSON Schema

Name	Required	Description	Default
`target_date`	Yes	Target market date in YYYY-MM-DD format
`historical_days`	No	Number of historical days to include (default 7, max 90)

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It does not disclose read-only nature, idempotency, rate limits, auth requirements, data freshness, or any side effects. This is a significant gap for a 'get' operation that should be safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first on purpose, second on usage. No extraneous information, front-loaded, and each sentence serves a clear function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description gives a reasonable sense of what is returned (prices and load). Combined with fully described parameters, it is adequate for simple data retrieval. However, it lacks details on response structure or pagination if any.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters well. The description adds context about the returned data (prices and load) but does not elaborate further on parameter format or usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves PJM Western Hub DA/RT LMP prices and load data, with specific location and data types. It distinguishes well from sibling tools that handle constraints, flows, generation, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases ('PJM Western Hub prices, PJM WH, Eastern power prices, or PJM load'), but does not mention when not to use or reference sibling alternatives directly. However, the given contexts are clear for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_segment_trackerA

Get bid segment counts for spread portfolios — how many segments were submitted per day and portfolio. Use this when asked about bid activity, segment counts, submission status, or how many bids were placed.

ParametersJSON Schema

Name	Required	Description	Default
`date_to`	Yes	End date in YYYY-MM-DD format
`date_from`	Yes	Start date in YYYY-MM-DD format
`submitted_filter`	No	Filter by submission status	all

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the tool returns counts per day and portfolio, implying read-only behavior, but does not explicitly declare it as read-only, mention any destructive potential, or detail side effects. Basic transparency but no additional context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the core purpose in the first sentence and usage guidance in the second. No fluff, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and 3 parameters, the description adequately explains the output concept (counts per day and portfolio) and usage. It could include details on response format or aggregation, but it is sufficient for an agent to understand what the tool returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes all three parameters. The description adds a high-level context (counts per day and portfolio) but does not provide additional parameter-level meaning beyond what the schema's descriptions already offer. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns bid segment counts per day and portfolio, with a specific verb ('Get') and resource ('segment counts'). It distinguishes from siblings by focusing on segment counts and submission status, which is unique among the listed siblings like get_spread_analysis or get_nodal_spread.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use it: 'Use this when asked about bid activity, segment counts, submission status, or how many bids were placed.' This provides clear context but does not specify when not to use it or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_spread_analysisA

Get detailed breakdown of spread trading PnL by path (source→sink), book, or book+path. Shows win rate, Calmar ratio, best/worst days per path or book. Use this when asked about specific paths, books, source/sink pairs, or route-level performance.

ParametersJSON Schema

Name	Required	Description	Default
`group`	No	Portfolio group name to filter by (leave blank to list available groups)
`date_to`	Yes	End date in YYYY-MM-DD format
`breakdown`	No	Breakdown dimension: path (source→sink), book, or book+path	path
`date_from`	Yes	Start date in YYYY-MM-DD format

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It implies read-only ('Get detailed breakdown') and mentions specific metrics (win rate, Calmar ratio), but does not disclose potential side effects, auth needs, or rate limits. Adequate but could be more comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose and outputs, second gives usage guidance. Very concise, front-loaded, and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 params, no output schema, and no annotations, the description covers purpose, usage, and key metrics shown. It lacks output format details but compensates by listing metrics. Slightly incomplete regarding error conditions or permissions, but sufficient given context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description reinforces breakdown options by explaining 'path (source→sink)', but adds little beyond schema descriptions for other parameters. It does not add new parameter-specific meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Get detailed breakdown of spread trading PnL by path, book, or book+path', providing a specific verb and resource. It clearly distinguishes from sibling tools like get_flow_analysis by focusing on spread trading PnL breakdowns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use this when asked about specific paths, books, source/sink pairs, or route-level performance', providing clear context for when to use. While it doesn't explicitly list when not to use, the sibling list implies alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_spread_portfoliosA

Get PnL summary for spread trading portfolios over a date range. Returns total PnL, win rate, best/worst days, and per-portfolio breakdown. Use this when asked about portfolio performance, PnL, profit/loss, trading results.

ParametersJSON Schema

Name	Required	Description	Default
`date_to`	Yes	End date in YYYY-MM-DD format
`date_from`	Yes	Start date in YYYY-MM-DD format
`submitted_filter`	No	Filter by submission status	all

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as read-only status, authentication requirements, or potential side effects. The tool likely performs a read operation but this is not confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the core function and output, followed by usage triggers. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers return fields (total PnL, win rate, best/worst days, per-portfolio breakdown) and parameter range (date range). It is mostly complete but could mention error handling or data freshness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters adequately. The description adds no additional parameter details beyond what is in the schema, achieving the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a PnL summary for spread trading portfolios, listing specific return fields (total PnL, win rate, etc.) and distinguishes from siblings by focusing on portfolio performance rather than other analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to use the tool—'when asked about portfolio performance, PnL, profit/loss, trading results'—but does not mention when not to use it or provide alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_constraintsA

List all available ERCOT transmission constraint names. Use this to find constraint names before calling get_constraint_loading.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and description only states it lists constraint names. It does not disclose any behavioral traits such as read-only nature, performance, or data freshness. For a simple list operation, the lack of detail is acceptable but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff, front-loaded with purpose. Every sentence is meaningful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description is nearly complete. It could briefly mention that output is a list of constraint names, but the context of being used before get_constraint_loading implies the return format. Minor gap: no explicit output description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters (100% coverage). According to guidelines, baseline is 4 for 0 parameters. Description adds no parameter info as none exist, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'List', resource 'ERCOT transmission constraint names', and purpose 'to find constraint names before calling get_constraint_loading'. It distinguishes from sibling tool get_constraint_loading by indicating this is a preparatory step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool: 'Use this to find constraint names before calling get_constraint_loading.' This provides clear context and alternative/next-step tool reference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_price_nodesA

Search for price nodes by name. Use this to look up node names before calling get_nodal_spread. Returns node name, ISO, zone, and type.

ParametersJSON Schema

Name	Required	Description	Default
`iso`	No	Filter by ISO (e.g. ERCOT, PJM, MISO, SPP)
`search`	Yes	Partial node name to search for (e.g. "HB_", "HOUSTON", "LZ_")

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, but the description implies a read-only search operation. It doesn't disclose any behavioral traits like pagination, rate limits, or prerequisites. Adequate but lacks depth for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose, second gives usage context and return value. Every word serves a purpose, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with 2 parameters and no output schema, the description adequately explains the use case and output fields. Could mention pagination or ordering, but it's not severely lacking given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The tool description adds no new parameter information beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it searches for price nodes by name, and explicitly connects it to a downstream tool (get_nodal_spread). Also lists the returned fields, making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using this tool before get_nodal_spread, providing a clear workflow. No mention of when not to use it or comparison with sibling list_constraints, but the guidance is specific and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv1.0.0Jul 15, 2026
- First observedget_constraint_loading
- First observedget_flow_analysis
- First observedget_gen_comparison
- First observedget_gen_detail
- First observedget_nodal_spread
- First observedget_pjm_wh
- First observedget_segment_tracker
- First observedget_spread_analysis
- First observedget_spread_portfolios
- First observedlist_constraints
- First observedlist_price_nodes

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Tools target distinct domains (constraints, generation, spreads, PJM) with clear descriptions. Minor overlap exists between get_spread_analysis and get_spread_portfolios, but their granularity differs (path/book vs portfolio summary).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: 'get_' for data retrieval and 'list_' for enumeration. No mixed conventions or vague verbs.

Tool Count5/5

11 tools cover the energy trading analytics domain comprehensively without being excessive. Each tool serves a clear purpose and earns its place.

Completeness4/5

The tool set covers listing, detail, and comparison for constraints, generation, spreads, and prices. A minor gap is the lack of tools for submitting trades or updating data, but the server appears focused on read-only analytics.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
RampOAuth
com.ramp.ramp-mcp-remote
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Finance Databases Search
2
DataDoe MCPOAuth
com.datadoe
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
E-commerce & Retail CRM
212
agentcentral AOAuth
to.agentcentral
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
E-commerce & Retail Customer Support
26

Related MCP Servers

MCP Snowflake Server NSP
Cloud Platforms Databases
nsphung
A
license
A
quality
A
maintenance
A Snowflake MCP server — SQL queries, schema exploration, and data insights for AI assistants
Updated 2 days ago (2026-09-04 18:51 UTC)
6
2
MIT
redash-mcp
Databases Search Data Visualization
seob717
A
license
A
quality
A
maintenance
MCP server that connects Redash to Claude AI, enabling natural language data queries, dashboard management, and SQL execution.
Updated 2 months ago (2026-07-06 09:46 UTC)
24
385
1
MIT
QueryForge
Databases Data Visualization
Mikebenisberchmans
F
license
Not graded
quality
C
maintenance
A unified MCP server that lets Claude query any SQLite database and build live Streamlit dashboards — all from a single conversation.
Updated 17 days ago (2026-08-20 16:46 UTC)
1
-
toad-mcp-server
RAG Systems AI & Machine Learning
vola-trebla
F
license
A
quality
D
maintenance
MCP server exposing portfolio AI tools including semantic search, evaluation framework, and prompt management, enabling natural language interaction with these services via Claude Desktop.
Updated 6 months ago (2026-03-17 23:57 UTC)
5
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cshah26/Chatbot-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

durable-mcp

How it works

Setup (30 seconds)

1. Add to Claude Desktop

2. Restart Claude Desktop

Credential fallback

Available tools

Example questions

Performance

What was slow (and what's fixed)

Snowflake warehouse tip

Data & Security

What leaves your network

Anthropic's data policy

Options if your firm has data sensitivity requirements

Architecture

Key design decisions

Development

Publishing updates

Changelog

391cbaf — fix+perf: resolve 9 code review issues

3f4f7d2 — fix: intercept process.stdout.write to block snowflake log4js from corrupting MCP stream

1017fff — fix: redirect all stdout to stderr to keep MCP protocol stream clean

f706a7b — fix: include dist/ in repo so npx github: works without build step

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`391cbaf` — fix+perf: resolve 9 code review issues

`3f4f7d2` — fix: intercept process.stdout.write to block snowflake log4js from corrupting MCP stream

`1017fff` — fix: redirect all stdout to stderr to keep MCP protocol stream clean

`f706a7b` — fix: include dist/ in repo so npx github: works without build step