counterparty-credit
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 DUKSEC 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.jsonWindows:
%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 Schwellenwertedocs/methodology-c0.md– menschenlesbare Methodik des Datensatzesdocs/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 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