Skip to main content
Glama
comtechai

counterparty-credit

by comtechai

Counterparty Credit

公開データから上場エネルギー企業の信用健全性をスコアリングする、オープンで透明なMCPサーバーです。エージェントに、公益事業、発電事業者、ミッドストリーム事業者、電力・ガスマーケッターの健全性を尋ねると、Counterparty Creditは0〜100のスコア、要素別の内訳、そして各数値の背後にある公開ソースを回答します。

これは意思決定支援であり、信用格付けではありません。すべての出力は出典が明示され、説明可能で、人間によるレビューを意図しています。目的は、議論できるスコアであり、ブラックボックスではないことです。

ComtechAI によって構築されました。メソドロジーバージョン: ccr-ref-1.3

ステータス: v1、意図的に安定

このリポジトリは、スコープを固定したリファレンス実装です。公開され、動作し続けます。バグ修正や上流の破損に対するパッチは歓迎しますが、新機能はここでは対象外です。セットアップ、テスト、コントリビューションルールについては DEVELOPMENT.md を参照してください。

Related MCP server: Pulse MCP Server

仕組み

1つのMCPツール counterparty.health は、会社名またはティッカーを受け取ります。SECファイラーを特定し、公開財務データと市場データを取得し、4つの要素をスコアリングして、説明的なバンド(Strong / Stable / Watch / Stressed / Distressed)を持つ複合スコアにブレンドします。

Factor

What it reads

Source

F1 — バランスシートの強さ

レバレッジ、インタレスト・カバレッジ、流動比率

SEC EDGAR (XBRL)

F3 — 市場インプライド・リスク

デフォルトまでの距離(ナイーブ・マートン)+ 株式ボラティリティ

Tiingo daily prices + EDGAR

F4 — ビジネスミックス / コモディティ・エクスポージャー

ビジネスタイプによるキャッシュフローの構造的隔離

分類ユニバース(27銘柄)

F5 — イベント / ニュース

格付けアクション、コベナンツ/流動性イベント、計画外の停止

Google News RSS

複合スコアは、この実行で実際に計算された要素に対する再正規化された加重ブレンドです。参照ウェイトは F1 0.20 · F3 0.15 · F4 0.25 · F5 0.15 です。要素の入力が欠落している場合(F3の市場フィードがない、F4の未分類の名前など)、その要素は除外され、そのウェイトは残りの要素に再配分されます。何も補完されません。要素は実際のデータから計算されるか、存在しないかのどちらかです。

すべての結果には methodology_versionas_of 日付が含まれ、各要素はその背後にあるファイリングまたはフィードを明示します。数値がプロキシである場合(制限事項を参照)、ソース行にその旨が記載されます。

インストール

Python 3.10〜3.14が必要です。

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

使用方法

コマンドラインから

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

説明的な User-Agent がない場合、SECはHTTP 403を返します。無料のTiingoトークンでF3が有効になります。省略すると、ツールはF1/F4/F5でスコアリングし、その旨を通知します。ファイリングとティッカーマップは ~/.cache/counterparty-credit に24時間キャッシュされます。

Claude Desktopから

claude_desktop_config.example.json をClaude Desktopの設定にコピーし、command をこのリポジトリのvenv Python(絶対パス)に設定し、env にキーを設定して、Claudeを再起動し、「カウンターパーティとしてのNextEraの財務健全性はどの程度ですか?」 と尋ねます。Claudeがツールを呼び出し、スコア、内訳、ソースを読み上げます。

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

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

会社を特定できない場合やデータを取得できない場合、ツールは数値ではなくエラーを返します。スコアは実際に計算された場合にのみ返されます。

メソドロジー

スコアリングは、ハードコードされた定数ではなく、Methodology 設定オブジェクトから読み取ります。Methodology.default() はオープンなリファレンスであり、ccr-ref-1.3 に固定されています。コミットされたレコードは次のとおりです:

  • src/counterparty_credit/methodology.py — すべてのカーブ、ウェイト、しきい値のソース・オブ・トゥルース

  • docs/methodology-c0.md — 人間が読める公式メソドロジー

  • docs/methodology-c0.json — マシン仕様(テストがドリフトを防ぎます)

カスタムメソドロジーは、そのオーバーライドのみを指定し、残りのリファレンスを継承します:

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

すべての結果にはバージョンが刻印されているため、カスタム設定がリファレンスではないことは明らかです。固定された数値は、実際の銘柄に対して洗練された出発点の仮説です。再較正は新しいバージョンであり、黙って書き換えられることはありません。

制限事項

これらは意図的であり、明確に述べられています。正直なスコープがリファレンスツールの要点です。

  • 信用格付けではありません。 公開データからの意思決定支援です。発行体との関与、非公開情報、格付け機関のメソドロジーは一切使用しません。

  • F2(流動性 / 担保)はライブブレンドから除外されています。 そのv0キャッシュプロキシは、信用品質に関係なくほぼ同一のスコアを返したため、識別力がありません。メソドロジーでは定義されていますが、実際の担保ストレスモデルがプロキシに取って代わるまで除外されます。

  • F3には市場フィードが必要です。 Tiingoトークンがない場合、またはクリーンな価格データがない銘柄の場合、F3は除外され、そのウェイトは再配分されます。

  • F4は、北米のエネルギー発行体の固定された27銘柄のユニバースを対象としています。 その外の銘柄は、推測ではなく、ビジネスミックス要素なしでスコアリングされます。

  • F5は固定された語彙に依存します。 アップグレード / ダウングレード と表現された格付けアクション(格付け機関の文脈を要求するようにゲートされています)と一連の信用イベントを検出します。他の動詞で表現された格付けアクションは見逃し、見出しのセンチメントは粗いものです。

  • カバレッジは現金支払いプロキシを使用する場合があります。 一部の大規模ファイラーは利息費用の概念をタグ付けしていません。そのような場合、カバレッジは支払われた現金利息から計算され、資本化利息は除外されます。ソース行は銘柄ごとにこれをフラグします。

  • 時点の公開データ。 数値は最新のファイリング時点のものです。古いファイリングはフラグされ、黙って使用されることはありません。

レイアウト

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/

免責事項

Counterparty Creditは、公開データから意思決定支援を生成します。これは信用格付けではなく、投資助言でもなく、いかなる格付け機関やスコアリング対象の発行体とも提携していません。出力は出典が明示され、人間によるレビューを意図しています。

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