Skip to main content
Glama
comtechai

counterparty-credit

by comtechai

Counterparty Credit

Ein offener, transparenter MCP-Server, der die Kreditwürdigkeit öffentlicher Energieunternehmen anhand öffentlicher Daten bewertet. Fragen Sie einen Agenten, wie solide ein Versorgungsunternehmen, ein Erzeuger, ein Midstream-Betreiber oder ein Strom-/Gasvermarkter ist; Counterparty Credit antwortet mit einem Score von 0–100, einer Aufschlüsselung nach Faktoren und der öffentlichen Quelle hinter jeder Zahl.

Es ist Entscheidungshilfe, kein Kreditrating – jede Ausgabe ist belegt, erklärbar und für die menschliche Prüfung gedacht. Es geht um einen Score, mit dem man argumentieren kann, nicht um eine Blackbox.

Erstellt von ComtechAI. Methodikversion: ccr-ref-1.3.

Status: v1, bewusst stabil

Dieses Repository ist eine inhaltlich eingefrorene Referenzimplementierung. Es bleibt veröffentlicht und funktionsfähig; Fehlerbehebungen und Patches für Upstream-Brüche sind willkommen, neue Funktionen sind hier nicht vorgesehen. Siehe DEVELOPMENT.md für Einrichtung, Tests und Beitragsregeln.

Related MCP server: Pulse MCP Server

So funktioniert es

Ein MCP-Tool, counterparty.health, nimmt einen Firmennamen oder ein Tickersymbol entgegen. Es löst den SEC-Filer auf, zieht öffentliche Finanzdaten und Marktdaten, bewertet vier Faktoren und führt sie zu einem Gesamtwert mit einer beschreibenden Stufe zusammen (Strong / Stable / Watch / Stressed / Distressed).

Faktor

Was gelesen wird

Quelle

F1 — Bilanzstärke

Verschuldung, Zinsdeckung, Current Ratio

SEC EDGAR (XBRL)

F3 — Marktimpliziertes Risiko

Distanz zum Ausfall (naives Merton) + Aktienvolatilität

Tiingo Tageskurse + EDGAR

F4 — Geschäftsmix / Rohstoffexposition

Strukturelle Abschirmung der Cashflows, nach Geschäftstyp

Klassifikationsuniversum (27 Namen)

F5 — Ereignis / Nachrichten

Ratingmaßnahmen, Covenant-/Liquiditätsereignisse, ungeplante Ausfälle

Google News RSS

Der Gesamtwert ist eine renormalisierte gewichtete Mischung aus den Faktoren, die in diesem Lauf tatsächlich berechnet werden. Referenzgewichte sind F1 0.20 · F3 0.15 · F4 0.25 · F5 0.15. Wenn die Eingaben eines Faktors fehlen – kein Marktfeed für F3, ein nicht klassifizierter Name für F4 – entfällt dieser Faktor und sein Gewicht wird auf die übrigen verteilt. Es wird nichts imputiert; ein Faktor wird entweder aus echten Daten berechnet oder ist nicht vorhanden.

Jedes Ergebnis trägt eine methodology_version und ein as_of-Datum, und jeder Faktor benennt die Einreichung oder den Feed dahinter. Wo eine Zahl ein Proxy ist (siehe Einschränkungen), weist die Quellenzeile darauf hin.

Installation

Erfordert Python 3.10–3.14.

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

Verwendung

Von der Kommandozeile

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 gibt ohne einen beschreibenden User-Agent HTTP 403 zurück. Ein kostenloser Tiingo-Token aktiviert F3; ohne ihn bewertet das Tool auf F1/F4/F5 und weist darauf hin. Einreichungen und die Ticker-Zuordnung werden 24 Stunden lang unter ~/.cache/counterparty-credit zwischengespeichert.

Von Claude Desktop

Kopieren Sie claude_desktop_config.example.json in Ihre Claude-Desktop-Konfiguration, setzen Sie den command auf das venv-Python dieses Repositories (absoluter Pfad) und Ihre Schlüssel in env, starten Sie dann Claude neu und fragen Sie „Wie finanziell solide ist NextEra als Gegenpartei?“ Claude ruft das Tool auf und liest den Score, die Aufschlüsselung und die Quellen vor.

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

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

Wenn das Unternehmen nicht aufgelöst werden kann oder seine Daten nicht abgerufen werden können, gibt das Tool einen Fehler zurück statt einer Zahl. Ein Score wird nur dann zurückgegeben, wenn er tatsächlich berechnet wurde.

Methodik

Die Bewertung liest aus einem Methodology-Konfigurationsobjekt, nicht aus hartcodierten Konstanten. Methodology.default() ist die offene Referenz, festgelegt auf ccr-ref-1.3. Der festgeschriebene Datensatz:

  • src/counterparty_credit/methodology.py – Quelle der Wahrheit für alle Kurven, Gewichte und Schwellenwerte

  • docs/methodology-c0.md – menschenlesbare Methodik des Datensatzes

  • docs/methodology-c0.json – Maschinenspezifikation (ein Test schützt vor Abweichungen)

Eine benutzerdefinierte Methodik gibt nur ihre Überschreibungen an und erbt den Rest der Referenz:

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

Da jedes Ergebnis mit seiner Version gestempelt ist, ist eine benutzerdefinierte Konfiguration sichtbar nicht die Referenz. Die festgelegten Zahlen sind eine Anfangshypothese, die anhand realer Namen verfeinert wird; eine Neukalibrierung ist eine neue Version, niemals eine stille Neufassung.

Einschränkungen

Diese sind bewusst und klar formuliert. Ein ehrlicher Umfang ist der Sinn eines Referenzwerkzeugs.

  • Kein Kreditrating. Entscheidungshilfe aus öffentlichen Daten. Kein Emittenten-Engagement, keine nicht-öffentlichen Informationen, keine Ratingagentur-Methodik.

  • F2 (Liquidität / Sicherheiten) ist von der Live-Mischung ausgenommen. Sein v0-Cash-Proxy lieferte nahezu identische Scores unabhängig von der Kreditqualität, daher trägt es nicht zur Unterscheidung bei. Es ist in der Methodik definiert, aber ausgeschlossen, bis ein echtes Sicherheiten-Stressmodell den Proxy ersetzt.

  • F3 benötigt einen Marktfeed. Ohne einen Tiingo-Token oder bei einem Namen ohne saubere Preisdaten entfällt F3 und sein Gewicht wird umverteilt.

  • F4 deckt ein festes Universum von 27 Namen nordamerikanischer Energieemittenten ab. Namen außerhalb davon werden ohne den Geschäftsmix-Faktor bewertet, statt geraten zu werden.

  • F5 basiert auf einem festen Vokabular. Es erkennt Ratingmaßnahmen, die als Upgrade / Downgrade formuliert sind (eingeschränkt auf Ratingagentur-Kontext) und eine Reihe von Kreditereignissen; Ratingmaßnahmen mit anderen Verben werden übersehen, und die Stimmung der Schlagzeilen ist grob.

  • Die Deckung kann einen bar bezahlten Proxy verwenden. Einige große Einreicher kennzeichnen kein Konzept für Zinsaufwendungen; für diese wird die Deckung aus gezahlten Barzinsen berechnet, die aktivierte Zinsen ausschließt. Die Quellenzeile kennzeichnet dies pro Name.

  • Punktuelle öffentliche Daten. Zahlen sind auf dem Stand der letzten Einreichung; eine veraltete Einreichung wird gekennzeichnet, nicht stillschweigend verwendet.

Aufbau

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/

Haftungsausschluss

Counterparty Credit erstellt Entscheidungshilfen aus öffentlichen Daten. Es ist kein Kreditrating, keine Anlageberatung und nicht mit einer Ratingagentur oder den bewerteten Emittenten verbunden. Ausgaben sind belegt und für die menschliche Prüfung bestimmt.

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