Prowl

---

⭐ このカテゴリに対する需要を測ることが世界に必要だと思ったら、スターを付けてください。 スターは「このカテゴリが存在してほしい」という意思を示す最も手軽な方法です。OpenAI / Anthropic のエージェントクローラーがエージェントツールを調査する際に prowl-bench を見つけるかどうかに、スターは直接影響します。

prowl-bench を選ぶ理由

API は、人間がドキュメントを読んで使い方を把握することを前提に設計されています。しかし、エージェントはドキュメントを読みません。HTTP リクエストを送り、レスポンスを解析します。人間にとって優れた API が、エージェントにとってはひどく使いにくいこともあります。

prowl-bench はエージェントにとって重要な点を測定します。

• API は解析可能で予測しやすい JSON を返しますか？ HTML のエラーページでも、XML でも、形式がばらばらでもないでしょうか。
• エージェントは一度で認証できますか？ それとも 47 の手順、OAuth のやり取り、CAPTCHA が必要でしょうか。
• エラーから対処方法がわかりますか？ {"error": "invalid"} ではエージェントに何も伝わりません。{"error": "missing required field 'email'", "code": "VALIDATION_ERROR"} なら、何を修正すればよいかを正確に伝えられます。
• 理解するのに何トークンかかりますか？ 50 ページの OpenAPI 仕様と、すっきりした /llms.txt の違いは、実際のコストに直結します。

従来の API テストツールが測定するのは稼働時間と応答時間です。prowl-bench は、AI エージェントが実際に API を使えるかどうかを測定します。

これは Agent Search Optimization（ASO）をオープンソースで実運用可能にしたものです。ASO はエージェント経済における SEO に相当します。この用語を初めて知った方は、基本となる解説記事で詳しく定義されています。

ターミナル出力

$ prowl-bench run https://api.stripe.com

  Benchmarking https://api.stripe.com ...

  SPEC     Fetched llms.txt ................................ OK  (0.8s)
  ANALYZE  Extracting service structure .................... OK  (2.1s)
  PLAN     Designing 12 test cases ......................... OK  (1.4s)
  EXECUTE  Running tests against live API .................. OK  (3.2s)
  INTERPRET Normalizing scores (3 LLMs) ................... OK  (2.8s)

  prowl-bench v0.2.0 | Template: api_benchmark | LLMs: claude, gpt-4o, gemini

  ┌─  Stripe API    Score: 82  ────────────────────────┐
  │                                                     │
  │  auth simplicity     ████████░░   8.0               │
  │  consistency         █████████░   9.0               │
  │  doc quality         ████████░░   8.5               │
  │  error clarity       █████████░   9.2               │
  │  first try success   ███████░░░   7.0               │
  │  latency             ████████░░   8.0               │
  │  response parseab..  █████████░   9.5               │
  │  token efficiency    ███████░░░   7.0               │
  │                                                     │
  └─────────────────────────────────────────────────────┘

  Issues: 2
  - OpenAPI spec is 48,000+ tokens — consider publishing /llms.txt
  - POST /v1/charges returns HTML on 402 status codes

  Recommendations:
  - Add structured error codes to all 4xx responses
  - Publish a condensed /llms.txt for agent consumers

インストール

ソースからインストールします（まだ PyPI には公開されていません）。

pip install "git+https://github.com/opcastil11/prowl-bench.git"

Python 3.10 以降が必要です。システム依存関係はありません。

クイックスタート

# Set at least one LLM API key
export ANTHROPIC_API_KEY="sk-ant-..."
# or OPENAI_API_KEY, GOOGLE_API_KEY, or DEEPSEEK_API_KEY — more keys = more balanced scoring

# Benchmark any API
prowl-bench run https://api.stripe.com

# With a specific template
prowl-bench run https://api.stripe.com --template api_benchmark

# With credentials for authenticated endpoints
prowl-bench run https://api.openai.com \
  --credential "sk-proj-abc123" \
  --credential-type bearer_token

# Output as JSON (for pipelines)
prowl-bench run https://api.example.com --output json > results.json

# CI mode: exit 1 if score below threshold
prowl-bench run https://api.example.com --min-score 70

# Got an MCP server? This one needs no LLM key at all.
prowl-bench mcp https://mcp.example.com/mcp

仕組み

prowl-bench は 4 段階のパイプラインを実行します。各段階は、ハードコードされたヒューリスティックではなく、実際のデータを読み取る LLM によって進められます。

                ┌─────────────────────────────────────────────────┐
                │              prowl-bench pipeline               │
                └─────────────────────────────────────────────────┘

  ┌───────────┐    ┌──────────┐    ┌───────────┐    ┌─────────────┐
  │  ANALYZE  │───>│   PLAN   │───>│  EXECUTE  │───>│  INTERPRET  │
  │           │    │          │    │           │    │             │
  │ Read spec │    │ Design   │    │ Run real  │    │ Score 0-10  │
  │ Extract   │    │ test     │    │ HTTP      │    │ across 8    │
  │ structure │    │ cases    │    │ requests  │    │ dimensions  │
  │ + auth    │    │ + probes │    │ + record  │    │ (multi-LLM) │
  └───────────┘    └──────────┘    └───────────┘    └─────────────┘
       │                                                  │
       │         OpenAPI / llms.txt / HTML                 │ Claude + GPT-4o
       └──────────────── input ──────────────────────────  │ + Gemini average
                                                          ▼
                                                   ┌─────────────┐
                                                   │   REPORT    │
                                                   │ Terminal /  │
                                                   │ JSON / CI   │
                                                   └─────────────┘

フェーズ 1 -- 分析： LLM が API 仕様（OpenAPI、llms.txt、または生の HTML）を読み取り、サービスの種類、認証方法、エンドポイント、料金モデル、レート制限を抽出します。

フェーズ 2 -- 計画： 分析に基づき、LLM が対象を絞ったテストケースを設計します。エンドポイントのプローブ、エラー処理のチェック、認証フローのテスト、料金の検証などです。

フェーズ 3 -- 実行： 稼働中の API に対して実際の HTTP リクエストを送信します。すべてのリクエストは、SSRF をブロックし、ペイロードを検証し、プロンプトインジェクションを防止するサンドボックスを通過します。レスポンス、レイテンシ、エラーが記録されます。

フェーズ 4 -- 解釈： 利用可能なすべての LLM が、8 つの側面からそれぞれ独立して結果をスコアリングします。バランスを保つため、スコアは平均化されます。LLM プロバイダーが増えるほど、偏りは少なくなります。

テンプレート

サービスのメタデータから自動検出される6種類のベンチマークテンプレートです。

テンプレート	認証情報	自動検出の条件	最適な対象
api_benchmark	必須	OpenAPI 仕様またはベンチマークガイドがある	REST API、LLM プロバイダー
platform_profile	不要	API を示す情報が見つからない	SaaS プラットフォーム、Web ツール
mcp_compliance	不要	URL が MCP エンドポイントに見える、またはカテゴリが mcp	MCP サーバー
docs_quality	不要	API ドキュメントの URL のみがある	ドキュメントの監査
defi_yield	必須	カテゴリが defi、staking、yield	DeFi プロトコル
crypto_app	必須	カテゴリが crypto、exchange、wallet	取引所、ウォレット

# List all templates with details
prowl-bench templates

# Force a specific template
prowl-bench run https://example.com --template platform_profile

MCP サーバー — prowl-bench mcp

LLM キーなしで、MCP サーバーのエージェント対応度をスコアリングします。ハンドシェイク （initialize → notifications/initialized → tools/list）を実行し、計測可能な項目を評価します。 入力スキーマ、ツールの説明、プロパティごとのドキュメント、ハンドシェイクの レイテンシ、そしてサーバーが instructions を送信するかどうかです。

prowl-bench mcp https://mcp.example.com/mcp
prowl-bench mcp https://mcp.example.com --tools        # list every tool
prowl-bench mcp https://mcp.example.com -o json        # machine-readable
prowl-bench mcp https://mcp.example.com --min-score 70 # CI gate

MCP conformance — https://mcp.aarna.ai

   x https://mcp.aarna.ai (http 405)
  -> https://mcp.aarna.ai/mcp (http 200)

  Crypto Technical Features v1.27.0  https://mcp.aarna.ai/mcp
  protocol 2025-06-18 · sse framing · stateless · 975ms

  Score: 93/100

  reachability          ##########    10.0/10
  tool discovery        ##########    10.0/10
  tool documentation    ##########    10.0/10
  schema quality        #######...     7.0/10
  latency               #########.     9.1/10
  agent guidance        ##########    10.0/10

  Tools: 18 · 18 documented · 18 with a schema

  Findings
    medium   40 of 40 schema properties have no description
             Per-property descriptions are what stop an agent passing a
             plausible value in the wrong format.

知っておくべきことは3つあります。

• 指定した URL が最初に試されます。 その後、/mcp、/mcp/、/api/mcp、/sse が試されます。 実際のエンドポイントを指定すると失敗していたのは、これまで入力のうちそれだけでした。
• どちらのレスポンス形式も読み取ります。 streamable-http では、サーバーは POST に対して application/json または text/event-stream で応答できます。どちらか一方しか読み取れない クライアントは、ネットワークの半分に対して正しく動作しません。
• ツールは呼び出しません。 tools/call には副作用があり、それはサーバーを実行する側に委ねられます。 そのため、エージェントがツールを使うのに十分な情報があるかどうかはわかりますが、 ツールが動作するかどうかはわかりません。

スコアは決定論的なため、CI で差分を確認できます。サーバーに到達できない場合、または --min-score を満たさない場合は、ゼロ以外の終了コードを返します。計算値ではなく LLM による判断が必要な場合は、prowl-bench run を使用してください。

同じサーバーでも、mcp と run が同じ数値を出すことはありません。これはバグではなく、 異なる尺度を使っているためです。mcp はハンドシェイクで計測できる6項目を評価します。 run はそれらをエージェント効率の8つの次元に対応付け、読み取り専用の プローブでは観測できない運用面の項目に85の上限を適用します。自分のサーバーの経時的な追跡には mcp を、Prowl カタログ内の他のすべてとの比較には run を使用してください。

スコアリング

実環境でのエージェント効率を考慮した、重み付けされた8つの次元です。

次元	重み	測定内容
token_efficiency	25%	エージェントが API を理解して使用するために必要なトークン数
first_try_success	20%	初回の試行で成功する呼び出しの割合
response_parseability	15%	HTML エラーページや混在した形式ではなく、明確で予測可能な JSON であるか
error_clarity	15%	エラーから、何を修正すべきかをエージェントが正確に把握できるか
doc_quality	10%	仕様、ドキュメント、または llms.txt の完全性
auth_simplicity	5%	認証に必要な手順数（1つのヘッダーか、OAuth の一連の手順か）
latency	5%	応答速度
consistency	5%	同じリクエストで常に同じ形式のレスポンスが返るか

各次元は 0〜10 でスコアリングされ、その後、重み付けされて 0〜100の総合スコア が算出されます。

トークン効率と初回成功率は、エージェントのコストと信頼性に直接影響するため、最も大きな重みが付けられています。

測定できない次元は、0点として扱わずスキップします。 すべてのテンプレートで8つすべてを 観測できるわけではありません。mcp_compliance は意図的にツールを呼び出さないため、 error_clarity や consistency について評価できません。これらを0点にすると、誰もテストしていない 項目に対して「テストした結果、ひどかった」と報告することになります。平均は実際に含まれる重みに 基づいて算出され、内訳には測定した項目だけが表示されます。次元を空欄にしても不利益がないわけでは ありません。latency または consistency が欠ける実行には 85 の上限が適用されるため、 テンプレートが得意な次元だけを報告して100点に到達することはできません。これは Prowl バックエンドの compute_score と同じ動作のため、この CLI の数値は prowl.world の数値と同じ意味を持ちます。

複数 LLM によるスコアリング

prowl-bench は、単一モデルによる偏りを軽減するため、利用可能なすべての LLM プロバイダーで INTERPRET フェーズを実行し、スコアを平均します。

プロバイダー	環境変数	モデル
Claude	ANTHROPIC_API_KEY	Claude Sonnet
GPT-4o	OPENAI_API_KEY	GPT-4o
Gemini	GOOGLE_API_KEY	Gemini 2.5 Flash
DeepSeek	DEEPSEEK_API_KEY	DeepSeek V3
Claude CLI	(フォールバック)	Web サブスクリプションを使用

よりバランスの取れた結果を得るには、複数のキーを設定してください。

export ANTHROPIC_API_KEY="sk-ant-..."
export OPENAI_API_KEY="sk-..."
export GOOGLE_API_KEY="AI..."
export DEEPSEEK_API_KEY="sk-..."

3 つすべてを設定すると、各モデルが個別にスコアを付け、結果が平均されます。JSON 出力にはモデルごとの内訳が含まれます。

Python API

import asyncio
from prowl_bench import BenchmarkReport
from prowl_bench.core.pipeline import run_benchmark

async def main():
    report: BenchmarkReport = await run_benchmark(
        url="https://api.stripe.com",
        name="Stripe",
        spec_content="...",  # OpenAPI spec, llms.txt, or any text
    )

    print(f"Overall: {report.overall_score}/100")
    print(f"Template: {report.template}")

    for dim, score in sorted(report.dimensions.items()):
        print(f"  {dim}: {score}/10")

    for issue in report.issues:
        print(f"  Issue: {issue}")

asyncio.run(main())

JSON にエクスポートする場合：

from prowl_bench.output.json_export import report_to_json

json_str = report_to_json(report)

CI との統合

エージェントの効率低下を検出するため、CI パイプラインに prowl-bench を追加します。

# .github/workflows/api-bench.yml
name: API Benchmark
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # Weekly Monday 6am

jobs:
  benchmark:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - run: pip install "git+https://github.com/opcastil11/prowl-bench.git"

      - name: Run benchmark
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          prowl-bench run https://api.yourservice.com \
            --min-score 70 \
            --output json > benchmark.json

      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: benchmark-results
          path: benchmark.json

--min-score フラグを指定すると、総合スコアがしきい値を下回った場合にコード 1 で終了し、CI ジョブを失敗させます。

Prowl への提出

提出方法は 3 つあります。あなたが誰なのか、またベンチマーク結果が公式スコアに反映されるかどうかによって異なります。

フラグ	認証	公式スコアへの影響	使用するケース
--submit	エージェントキー（ak_...）	なし — コミュニティ履歴として記録	透明性の確保や貢献のために、他者のサービスをベンチマークする場合
--vendor-submit	ベンダー JWT	あり（置き換えガードあり）	サービスを所有しており（所有権確認済み＋DNS 検証済み）、最新の自己申告スコアを公開したい場合
--provide	エージェントキー＋プロバイダープロファイル	あり（プロバイダーによる先行スナップショット）	プロバイダーとしてサービスを先行して獲得し、遡及収益を得たい場合

1. コミュニティへの提出（--submit）

# One-time: register for an agent key
prowl-bench register
export PROWL_AGENT_KEY="ak_abc123..."

# Benchmark and submit as community history
prowl-bench run https://api.example.com --submit

サービスプロフィールの「コミュニティへの提出」に保存されます。主要スコアには反映されません。

2. ベンダーによる自己申告（--vendor-submit）

独自のベンチマークで公式 Prowl スコアを更新したいサービス所有者向けです。

# 1. Claim the service at prowl.world (DNS / well-known / meta-tag verification)
# 2. Log in at https://prowl.world/app#/login
# 3. Copy the JWT from browser localStorage (key: prowl_jwt)
export PROWL_VENDOR_JWT="eyJhbGc..."

# 4. Benchmark and self-attest
prowl-bench run https://api.example.com --vendor-submit

置き換えガードにより、1 つの LLM による実行結果が、信頼度の高い Prowl の複数 LLM によるスコアを知らないうちに置き換えることを防ぎます。Prowl／プロバイダーのスコアを置き換えるには、提出結果が複数 LLM（プロバイダー 2 つ以上）によるものであること、現在のスコアを上回ること、または現在のスコアが 14 日以上前のものであることが必要です。

プロバイダーネットワーク — 収益を獲得

ベンチマークを実行して、そこから生じる**収益の 70%**を獲得できます。Prowl が 30% を受け取ります。ユーザーがあなたのベンチマーク済みサービスのベンチマークに $1.00 を支払うと、あなたは $0.70 を受け取ります。

クイックスタート

# 1. Register an agent key (if you haven't)
prowl-bench register
export PROWL_AGENT_KEY="ak_..."

# 2. Register as a provider with your wallet
prowl-bench provide register-provider --wallet "sol:YourWalletAddress"

# 3. Start the bot — it auto-claims directives, benchmarks, and submits
prowl-bench bot start

以上です。ボットが利用可能な作業を Prowl に問い合わせ、指示を取得し、ベンチマークパイプライン全体を実行して、結果を自動的に提出します。

自律型ボット

このボットは、あなたが眠っている間も収益を得られる、長時間稼働するデーモンです。

# Start with defaults (poll every 60s, 1 benchmark at a time)
prowl-bench bot start

# Faster polling, more concurrent work
prowl-bench bot start --poll-interval 30 --max-workers 3

# Check your status
prowl-bench bot status

ボットの仕組み：

1. Prowl に問い合わせ、未処理の指示（ベンチマーク作業指示）を取得します
2. 利用可能な指示のうち、最も優先度の高いものを取得します
3. 4 フェーズのベンチマークパイプライン全体（ANALYZE、PLAN、EXECUTE、INTERPRET）を実行します
4. 結果を Prowl に提出します
5. これを繰り返します

ベンチマークに失敗した場合、ボットは指示をキューに戻し、ほかの人が利用できるようにします。

手動モード

ボットを使わずに、ベンチマークを手動で実行することもできます。

# Benchmark any URL and submit as provider
prowl-bench run https://api.stripe.com --provide

# Check available work orders
prowl-bench provide directives

# Claim specific work
prowl-bench provide claim abc123
prowl-bench run https://target-api.com --provide

# Check earnings
prowl-bench provide dashboard
prowl-bench provide earnings

# Withdraw
prowl-bench provide withdraw 5.00

すべてのコマンド

コマンド	説明
ボット
prowl-bench bot start	自律型プロバイダーボットを起動
prowl-bench bot status	プロバイダーのステータスと利用可能な作業を確認
プロバイダー
prowl-bench provide register-provider	ウォレットアドレスを指定してプロバイダーとして登録
prowl-bench provide dashboard	統計、ベンチマーク、収益を表示
prowl-bench provide directives	利用可能な作業指示を一覧表示
prowl-bench provide claim <id>	指示を取得
prowl-bench provide earnings	収益の詳細な内訳
prowl-bench provide withdraw <amount>	ウォレットに出金
prowl-bench provide guide	プロバイダーハンドブック

収益の仕組み

Bot claims directive for a service
  → Runs full benchmark pipeline
    → Submits results (quality scored 0-100)
      → Vendor pays $1.00 for benchmark on that service
        → $0.70 credited to your pending balance
          → prowl-bench provide withdraw → sent to your wallet

未獲得のサービスでは、事前収益は $0.00 ですが、あなたが指定プロバイダーになります。ベンダーが後日支払いを行うと、ベンチマークは最初にあなたへ割り当てられます。

指令（バウンティ）

Prowl は、ベンチマークが必要なサービス向けに、毎時自動で作業指示を生成します。

優先度	報酬	トリガー
Critical	$0.70	サービスが申請済みで、ベンチマークが一度も実施されていない（ベンダーが待機中）
High	$0.50	ベンチマークが古い（30 日超）
Normal	$0.35	人気のサービスで更新が必要
Low	catalog	未申請のサービス（ベンダーが支払うと遡って報酬を獲得）

品質要件

提出物は自動採点されます。品質が高いほど、より早く承認されます。

• HTTP レスポンスコードとレイテンシ測定値を含める
• 少なくとも 3 つのエンドポイントをテストする
• 証拠（レスポンスのサンプル）を含める
• 実行可能な問題点と推奨事項を提示する
• 品質の低い提出物は却下されます（報酬なし）

セキュリティ

prowl-bench は、すべての送信リクエストをサンドボックス化します。

• SSRF の防止 -- URL は、ブロック対象ネットワーク、プライベート IP、クラウドメタデータエンドポイント、ローカルホストに該当しないか検証されます
• ペイロード上限 -- リクエストボディは 10KB に制限されます
• プロンプトインジェクション対策 -- すべてのユーザー入力は、LLM に送信する前にサニタイズされます
• レート制限 -- ベンチマーク 1 回の実行につき、HTTP リクエストは最大 20 件です
• 認証情報の漏えい防止 -- 認証情報が LLM プロンプトや出力に含まれることはありません

プロジェクト構成

src/prowl_bench/
├── cli.py              # Typer CLI (run, templates, register, provide, bot)
├── bot.py              # Autonomous provider bot daemon
├── config.py           # Settings from env vars
├── core/
│   ├── pipeline.py     # 4-phase benchmark pipeline
│   ├── scoring.py      # Weighted score computation
│   ├── types.py        # Dataclasses (BenchmarkReport, etc.)
│   └── json_utils.py   # Safe JSON extraction from LLM output
├── llm/
│   ├── router.py       # Multi-provider LLM router
│   ├── providers.py    # Claude, GPT-4o, Gemini, DeepSeek, CLI fallback
│   └── prompts.py      # System prompts for each phase
├── output/
│   ├── terminal.py     # Rich terminal rendering
│   └── json_export.py  # JSON report export
├── sandbox/
│   ├── url_validator.py      # SSRF prevention
│   ├── payload_validator.py  # Size + content validation
│   └── prompt_sanitizer.py   # Injection protection
├── submission/
│   ├── client.py       # Submit results to prowl.world
│   └── provider.py     # Provider network API client
└── templates/
    ├── base.py              # Base template class
    ├── api_benchmark.py     # REST API benchmark
    ├── platform_profile.py  # SaaS platform profile
    ├── mcp_compliance.py    # MCP server compliance
    ├── docs_quality.py      # Documentation audit
    ├── defi_yield.py        # DeFi protocol benchmark
    └── crypto_app.py        # Crypto app benchmark

他のエージェントインフラストラクチャとの比較

prowl-bench は測定レイヤーです。エージェントスタック内の他のツールと競合するのではなく、連携して動作します。

ツール	レイヤー	機能
prowl-bench	測定	8 つの側面で API のエージェント対応度を複数の LLM により採点
Composio	認証	約 850 の SaaS コネクターの OAuth フローを管理
Smithery	カタログ	7,000 以上の MCP サーバーをホストし、インデックス化
Official MCP Registry	ディスカバリー	MCP サーバーの正式な参照リスト
Kong Context Mesh	ゲートウェイ	エージェントのトラフィックに対するエンタープライズポリシーと監査

詳細な比較：Prowl、Composio、Smithery の比較（機能マトリックス＋意思決定フローチャート）

本格的なエージェント構築では、これらのうち 2 つまたは 3 つを組み合わせて使うのが一般的です。同じスタックの異なるレイヤーの課題を解決します。

詳しくはこちら

• 📚 エージェント検索最適化（ASO）とは？ — 基本となる解説記事（読了時間 15 分）
• 🗺️ 2026 年の主要なエージェントディスカバリープラットフォーム — 忖度のないリスト
• 🧬 ASO のコンセプトハブ — 8 つの側面を解説
• 🛰️ エージェントウェブマップ — 採点済み API のピクセルグリッド
• 🐦 @prowl_world — リリースノート、手法の更新情報
• 📨 [email protected] — 質問、連携、報道に関するお問い合わせ

コントリビューション

ガイドラインについては、CONTRIBUTING.md をご覧ください。

最初のコントリビューションにおすすめの項目：

• ローカル LLM プロバイダー（Ollama / llama.cpp）を追加する — src/prowl_bench/llm/providers.py を参照
• 新しいベンチマークテンプレートを追加する — src/prowl_bench/templates/ と CONTRIBUTING.md#adding-a-new-template を参照
• ターミナル出力の書式を改善する — src/prowl_bench/output/terminal.py を参照
• SDK の品質採点を追加する（現在は品質ではなく有無のみを確認）
• MCP トランスポートのバリエーションを追加する（現在、npm の mcp-prowl は stdio のみ）

人気の API／サービス向けのベンチマークアダプターをリリースすれば、次回のリリースノートで紹介します。

# Clone and install dev dependencies
git clone https://github.com/opcastil11/prowl-bench.git
cd prowl-bench
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

# Run tests
pytest tests/ -q

# Lint
ruff check src/ tests/

$PROWL トークン

Prowl は Solana 上の $PROWL トークンによって資金を得ています。トークンの収益は、LLM の推論コスト、クローラーのインフラストラクチャ、オープンソース開発に充てられます。

• トークン： Pump.fun の $PROWL
• ミント： DRg2EnkqTNFVnBegv1KReGTWs1cGBNCfyyUnY6bkpump
• チェーン： Solana
• 支払い： 有料 API エンドポイントでは、$PROWL トークンの送金を受け付けます（金額は任意）

ライセンス

Apache 2.0 -- LICENSE を参照してください。

---