counterparty-credit
Uses Google News RSS to fetch recent headlines for the event/news factor, detecting rating actions, covenant/liquidity events, and unplanned outages in credit scoring.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@counterparty-creditCredit health of Duke Energy"
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.
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 DUKSEC 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.jsonWindows:
%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, thresholdsdocs/methodology-c0.md— human-readable methodology of recorddocs/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 toolcounterparty.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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| band | Yes | Descriptive band derived from the score |
| name | Yes | The query as the caller sent it |
| as_of | Yes | As-of date for the underlying data (YYYY-MM-DD) |
| score | Yes | Composite 0–100 health score |
| ticker | No | Equity ticker, if resolved |
| factors | Yes | Factor-by-factor breakdown, each independently sourced |
| summary | Yes | Plain-language read a desk could act on |
| disclaimer | No | Non-negotiable framing — this is not a rating. |
| resolved_name | Yes | Canonical entity name after resolution |
| methodology_version | Yes | Versioned methodology id, e.g. 'tenor-0.1.0-stub' |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
counterparty.health
TDQS
Scored across 1 tool
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.
A single tool name naturally presents no inconsistencies. The dotted notation 'counterparty.health' is descriptive and suggests a clear action/domain pattern.
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.
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
Related MCP Connectors
Independent trust scores, tool surfaces and change history for MCP servers.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Scores any MCP server before you trust it: free quick check, full paid report, 2-5 way compare.
Remote MCP server to enrich company profiles with structured B2B data and confidence scores.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server for Axonn, enabling access to US energy regulatory filings, real-time ISO prices, and market data.MIT
- FlicenseNot gradedqualityCmaintenanceAn 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.-
- FlicenseNot gradedqualityBmaintenanceMCP 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.-
- AlicenseNot gradedqualityCmaintenanceProvides 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