Skip to main content
Glama
comtechai

counterparty-credit

by comtechai

Counterparty Credit

An open, transparent MCP server that scores the credit health of public energy companies from public data. Ask an agent how sound a utility, generator, midstream operator, or power/gas marketer is; Counterparty Credit answers with a 0–100 score, a factor-by-factor breakdown, and the public source behind every number.

It is decision-support, not a credit rating — every output is sourced, explainable, and meant for human review. The point is a score you can argue with, not a black box.

Built by ComtechAI. Methodology version: ccr-ref-1.3.

Status: v1, deliberately stable

This repo is a scope-frozen reference implementation. It stays published and working; bug fixes and upstream-breakage patches are welcome, new capability is out of scope here. See DEVELOPMENT.md for setup, tests, and contribution rules.

Related MCP server: Pulse MCP Server

How it works

One MCP tool, counterparty.health, takes a company name or ticker. It resolves the SEC filer, pulls public financials and market data, scores four factors, and blends them into a composite with a descriptive band (Strong / Stable / Watch / Stressed / Distressed).

Factor

What it reads

Source

F1 — Balance-sheet strength

Leverage, interest coverage, current ratio

SEC EDGAR (XBRL)

F3 — Market-implied risk

Distance-to-default (naive Merton) + equity volatility

Tiingo daily prices + EDGAR

F4 — Business-mix / commodity exposure

Structural insulation of cash flows, by business type

Classification universe (27 names)

F5 — Event / news

Rating actions, covenant/liquidity events, unplanned outages

Google News RSS

The composite is a renormalized weighted blend over whatever factors actually compute this run. Reference weights are F1 0.20 · F3 0.15 · F4 0.25 · F5 0.15. When a factor's inputs are missing — no market feed for F3, an unclassified name for F4 — that factor drops and its weight redistributes across the rest. Nothing is imputed; a factor is either computed from real data or absent.

Every result carries a methodology_version and an as_of date, and each factor names the filing or feed behind it. Where a figure is a proxy (see limitations), the source line says so.

Install

Requires Python 3.10–3.14.

python3 -m venv venv && source venv/bin/activate   # Windows: venv\Scripts\activate
pip install -e .

Use it

From the command line

export SEC_USER_AGENT="Your Name you@example.com"   # SEC requires a contact User-Agent
export TIINGO_TOKEN="your_tiingo_key"               # optional; F3 is skipped without it
python3 -m counterparty_credit.cli "NextEra Energy"
python3 -m counterparty_credit.cli DUK

SEC returns HTTP 403 without a descriptive User-Agent. A free Tiingo token enables F3; omit it and the tool scores on F1/F4/F5 and says so. Filings and the ticker map cache under ~/.cache/counterparty-credit for 24 hours.

From Claude Desktop

Copy claude_desktop_config.example.json into your Claude Desktop config, set the command to this repo's venv Python (absolute path) and your keys in env, then restart Claude and ask "How financially sound is NextEra as a counterparty?" Claude calls the tool and reads back the score, breakdown, and sources.

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

If the company can't be resolved or its data can't be retrieved, the tool returns an error rather than a number. A score is only ever returned when it was actually computed.

Methodology

Scoring reads from a Methodology config object, not hardcoded constants. Methodology.default() is the open reference, locked at ccr-ref-1.3. The committed record:

  • src/counterparty_credit/methodology.py — source of truth for all curves, weights, thresholds

  • docs/methodology-c0.md — human-readable methodology of record

  • docs/methodology-c0.json — machine spec (a test guards against drift)

A custom methodology states only its overrides and inherits the rest of the reference:

CCR_METHODOLOGY=/path/to/methodology.json python3 -m counterparty_credit.cli "NextEra Energy"

Because every result is stamped with its version, a custom config is visibly not the reference. The locked numbers are a starting hypothesis, refined against real names; a recalibration is a new version, never a silent rewrite.

Limitations

These are deliberate and stated plainly. An honest scope is the point of a reference tool.

  • Not a credit rating. Decision-support from public data. No issuer engagement, no non-public information, no rating-agency methodology.

  • F2 (liquidity / collateral) is withheld from the live blend. Its v0 cash proxy returned near-identical scores regardless of credit quality, so it adds no discrimination. It is defined in the methodology but excluded until a real collateral-stress model replaces the proxy.

  • F3 needs a market feed. Without a Tiingo token, or for a name without clean price data, F3 drops and its weight redistributes.

  • F4 covers a fixed 27-name universe of North American energy issuers. Names outside it are scored without the business-mix factor rather than guessed at.

  • F5 keys on a fixed vocabulary. It detects rating actions phrased as upgrade / downgrade (gated to require rating-agency context) and a set of credit events; it will miss rating actions phrased with other verbs, and headline sentiment is coarse.

  • Coverage may use a cash-paid proxy. Some large filers tag no interest-expense concept; for those, coverage is computed from cash interest paid, which excludes capitalized interest. The source line flags this per name.

  • Point-in-time public data. Figures are as-of the latest filing; a stale filing is flagged, not silently used.

Layout

src/counterparty_credit/
  schema.py          # locked I/O contract (HealthResult)
  methodology.py     # config object — reference default + worksheet loader
  resolve.py         # name/ticker → CIK + ticker (SEC company_tickers.json)
  edgar.py           # XBRL companyfacts → financials (recency-aware tag selection)
  ratios.py          # leverage / coverage / liquidity
  market.py          # daily prices → price + annualized vol (Tiingo)
  dtd.py             # naive-Merton distance-to-default
  news.py            # recent headlines (Google News RSS)
  scoring.py         # F1, F3, F5 scorers
  f4_business_mix.py # F4 business-mix lookup over the universe
  universe.json      # 27-name classification universe
  score.py           # orchestration → weighted composite → HealthResult
  server.py          # MCP tool
  cli.py             # one-command live scoring
tests/

Disclaimer

Counterparty Credit produces decision-support from public data. It is not a credit rating, not investment advice, and not affiliated with any rating agency or the issuers it scores. Outputs are sourced and intended for human review.

Available Tools

1 tool
counterparty.healthA

Assess the credit health of a public energy company from public data.

Use this when asked how financially sound or risky an energy counterparty is — a regulated utility, merchant generator/IPP, midstream operator, or power/gas marketer. Accepts a company name or ticker.

Returns a 0-100 health score and descriptive band (Strong/Stable/Watch/Stressed/ Distressed), a factor-by-factor breakdown with the public source behind each factor, a plain-language summary, the methodology version, and an as-of date. This is transparent decision-support, not a credit rating.

Raises rather than guessing when the company cannot be resolved or its public data cannot be retrieved. A score is only ever returned when it was actually computed.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
bandYesDescriptive band derived from the score
nameYesThe query as the caller sent it
as_ofYesAs-of date for the underlying data (YYYY-MM-DD)
scoreYesComposite 0–100 health score
tickerNoEquity ticker, if resolved
factorsYesFactor-by-factor breakdown, each independently sourced
summaryYesPlain-language read a desk could act on
disclaimerNoNon-negotiable framing — this is not a rating.
resolved_nameYesCanonical entity name after resolution
methodology_versionYesVersioned methodology id, e.g. 'tenor-0.1.0-stub'

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the return contents (health score, band, factor breakdown, sources, summary, methodology version, as-of date), frames the output as 'transparent decision-support, not a credit rating,' and explicitly states it 'raises rather than guessing' when resolution or data retrieval fails.

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 front-loaded with the main action, immediately followed by usage context, output details, and an explicit failure behavior. Every sentence contributes necessary information without redundancy, and the structure makes it easy for an agent to quickly determine purpose and call behavior.

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

Completeness5/5

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

Given the tool's single parameter, no annotations, no siblings, and an output schema that can carry return structure, the description covers all key contextual needs: input type, applicable domain, output semantics, methodological transparency, and error behavior. An agent has enough information to invoke the tool correctly and interpret its result.

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?

The input schema only provides a required string property 'name' with 0% description coverage, so the description must compensate. It does by adding that the tool 'Accepts a company name or ticker.' This is meaningful semantic guidance for the single parameter, though slightly more detail about accepted formats would push it higher.

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 a specific verb and resource: 'Assess the credit health of a public energy company from public data.' It further clarifies the exact scope by listing company types (regulated utility, merchant generator/IPP, midstream operator, marketer) and the accepted inputs (company name or ticker). Even without siblings, the purpose is 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?

The description explicitly states when to use the tool: 'Use this when asked how financially sound or risky an energy counterparty is.' It gives clear context and enumerates the applicable counterparty types, but it does not explicitly state when not to use it or name alternatives. Since there are no sibling tools, this is a clear and sufficient usage guideline.

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.

  1. 1 tool updatev0.1.0
    • First observedcounterparty.health

TDQS

A4.6/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap with other tools. The tool's purpose is clearly defined and unique within this server.

Naming Consistency5/5

A single tool name naturally presents no inconsistencies. The dotted notation 'counterparty.health' is descriptive and suggests a clear action/domain pattern.

Tool Count3/5

One tool feels thin for a server, even when narrowly scoped. The functionality is focused, but a server with a single tool offers little flexibility or breadth for an agent.

Completeness4/5

The tool covers the core domain of assessing counterparty credit health thoroughly, returning scores, factors, sources, and methodology. It lacks supplementary operations like historical comparisons or bulk screening, but these are not essential for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for Axonn, enabling access to US energy regulatory filings, real-time ISO prices, and market data.
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that exposes Moody's Pulse (Cortera) trade-credit data with grounded knowledge-base context, enabling search, report retrieval, and explanation of metrics and use cases.
    -
  • F
    license
    Not graded
    quality
    B
    maintenance
    MCP server that exposes the credit scoring model's deterministic tools (probability of default, SHAP explanations, typicality check, financial ratios) to AI agents, enabling natural language credit risk assessment.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides complete credit dossiers for individuals or companies, including registration data, risk score, and pending issues, via a hosted MCP server with a single read-only tool.
    MIT