エージェントはすべてのAPI呼び出しで過払いしています。私たちがそれを解決します。
Heblineは、LLM呼び出しを含むすべてのAPI呼び出しを、適切な価格で最適なサービスへルーティングします。十分な場合は無料で、重要な場合は有料で。Heblineはその違いを理解しています。
他のルーターはすべて、有料の呼び出しからマージンを得ています。無料の代替手段にルーティングすることは、彼らの収益を損なうことになります。API呼び出しにマージンは一切ありません。今後もありません。
エージェントは資金を浪費しています。1つのタスクで、異なるプロバイダー間で5〜10回の有料API呼び出しがトリガーされます。透明性もコスト管理もありません。Heblineはそれを解決します：
無料を優先してルーティング — ほとんどの呼び出しには最高のモデルは必要ありません。Heblineはいつ重要かを正確に学習し、市場の変化に合わせて学習し続けます。
マージンなし。誠実なルーティング。 — 私たちはあなたがより多く支払っても利益を得ません。そのため、実際にコストを削減するために構築された唯一のルーターです。
プロバイダーの抽象化 — エージェントは「どのサービス」を使うかではなく、「何」が必要か（「この住所をジオコーディングして」）を伝えます。エージェントのコードを変更せずにプロバイダーを切り替えることができます。
コストの透明性 — すべての呼び出しは、使用されたサービス、レイテンシ、コストとともにログに記録されます。エージェントが何にいくら使っているかを正確に把握できます。
使用状況から学習 — ヘブ則学習（Hebbian learning）により、機能するものは強化され、機能しないものは弱められます。ブローカーは日々賢くなっていきます。
BYOK (Bring Your Own Key) — 有料サービスは、環境変数を通じてあなたのAPIキーを使用します。キーがない場合、そのサービスはルーティングから自動的に除外されます。
GDPR準拠 — 匿名化されたメタデータのみがログに記録されます。API呼び出しの内容は保存されません。ネットワークからデータが一切出ないセルフホストオプションもあります。
オープンソース — コアMCPサーバーはMITライセンスです。コミュニティ主導のアダプターシステムを採用しています。
Related MCP server: Clawy MCP Server
Your AI Agent ←→ Hebline MCP Server ←→ Best API (Nominatim, DeepL, Google Maps, ...)
│
Smart Routing
Cost Logging
Provider ScoringエージェントはHeblineにMCPサーバーとして接続します。APIを直接呼び出す代わりに、Heblineのツール（execute、compare、または categories）を使用します。Heblineは利用可能なすべてのサービスをスコアリングし、最適なものを選択して呼び出しを行い、完全なメタデータとともに結果を返します。
ツール | 説明 |
| 最適なサービスにルーティングしてAPI呼び出しを行います。結果とメタデータ（サービス、コスト、レイテンシ）を返します。 |
| 機能ごとに利用可能なすべてのサービスをスコア付きで表示します。コミットする前に何が利用可能かを確認できます。 |
| サポートされているすべての機能とそのサービスを一覧表示します。 |
claude_desktop_config.json に追加します：
{
"mcpServers": {
"hebline": {
"command": "npx",
"args": ["-y", "-p", "@hebline.ai/mcp-server", "hebline-mcp"]
}
}
}.mcp.json に追加します：
{
"mcpServers": {
"hebline": {
"command": "hebline-mcp"
}
}
}.cursor/mcp.json に追加します：
{
"mcpServers": {
"hebline": {
"command": "npx",
"args": ["-y", "-p", "@hebline.ai/mcp-server", "hebline-mcp"]
}
}
}~/.codeium/windsurf/mcp_config.json に追加します：
{
"mcpServers": {
"hebline": {
"command": "npx",
"args": ["-y", "-p", "@hebline.ai/mcp-server", "hebline-mcp"]
}
}
}.vscode/mcp.json に追加します：
{
"servers": {
"hebline": {
"type": "stdio",
"command": "npx",
"args": ["-y", "-p", "@hebline.ai/mcp-server", "hebline-mcp"]
}
}
}npm install -g @hebline.ai/mcp-server使用したい有料プロバイダーの環境変数を設定します：
GOOGLE_MAPS_API_KEY=your-key-here
DEEPL_API_KEY=your-key-here
LIBRETRANSLATE_API_KEY=your-key-hereキーがなくても問題ありません。Heblineは自動的に無料の代替手段にルーティングします。
カテゴリ | 無料 | 有料 (BYOK) |
LLMs | Groq (Llama 3.3 70B), Google Gemini Flash | OpenAI GPT-4o-mini ( |
ジオコーディング | Nominatim (OpenStreetMap) | Google Maps ( |
翻訳 | MyMemory | DeepL ( |
Webスクレイピング | Fetch Scraper | Firecrawl ( |
通貨 | ExchangeRate-API | Fixer.io ( |
OCR | OCR.space | Google Vision ( |
天気 | Open-Meteo | OpenWeatherMap ( |
Web検索 | DuckDuckGo | Brave Search ( |
ニュース | HackerNews | NewsAPI.org ( |
9カテゴリ、20サービス。 無料サービスはすぐに動作し、APIキーは不要です。ローカルキーが設定されていない場合、LLMはHeblineプロキシ経由でルーティングされます（1日50回まで無料）。
エージェントが次のように尋ねます：「ベルリンのブランデンブルク門をジオコーディングして」
Heblineが受け取るもの：
{
"capability": "geocoding",
"input": { "query": "Brandenburger Tor, Berlin" },
"constraint": "free"
}Heblineの応答：
{
"success": true,
"data": {
"lat": 52.5163,
"lon": 13.3777,
"displayName": "Brandenburger Tor, Pariser Platz, Berlin, 10117, Deutschland"
},
"meta": {
"service": "Nominatim (OpenStreetMap)",
"costUsd": 0,
"latencyMs": 258,
"score": 0.702,
"free": true
}
}エージェントは座標を取得し、それが無料であったことを認識し、Heblineは将来の分析のために呼び出しをログに記録しました。
mcp-server/
├── src/
│ ├── index.ts # MCP server entry point (stdio transport)
│ ├── types.ts # Shared TypeScript types
│ ├── registry.ts # Service definitions (capabilities, costs, scores)
│ ├── router.ts # Weighted scoring engine (Hopfield-ready)
│ ├── logger.ts # Append-only JSONL call log (~/.hebline/calls.jsonl)
│ ├── adapters/ # One adapter per service
│ │ ├── nominatim.ts # Free geocoding
│ │ ├── google-maps.ts # Paid geocoding (BYOK)
│ │ ├── mymemory.ts # Free translation
│ │ ├── libretranslate.ts # Paid translation (BYOK)
│ │ └── deepl.ts # Paid translation (BYOK)
│ └── tools/ # MCP tool definitions
│ ├── execute.ts # Route + call best service
│ ├── compare.ts # Score all services
│ └── categories.ts # List capabilitiesすべてのAPI呼び出しは ~/.hebline/calls.jsonl にログ記録されます：
{"timestamp":"2026-03-29T09:36:37Z","capability":"geocoding","serviceId":"nominatim","latencyMs":212,"success":true,"costUsd":0}コンテンツはログに記録されず、メタデータのみが記録されます。このデータは将来のバージョンでヘブ則学習を強化します。
[x] stdioトランスポートを備えたコアMCPサーバー
[x] 重み付けスコアリングルーター
[x] ジオコーディングアダプター (Nominatim, Google Maps)
[x] 翻訳アダプター (MyMemory, LibreTranslate, DeepL)
[x] BYOKキー管理
[x] 追記型呼び出しログ
[x] GitHub ActionsによるCI/CD
[ ] ヘブ則学習 — ルーターが呼び出し履歴から学習します
[ ] ホップフィールドネットワークスコアリング（重み付けスコアリングを置き換え）
[ ] さらなるカテゴリ（Webスクレイピング、通貨、OCR、メール）
[ ] コミュニティアダプターシステム
[ ] リモートデプロイ用のSSEトランスポート
[ ] コスト分析用のWebダッシュボード
[ ] 予算アラートと支出制限
[ ] マルチエージェントのコスト帰属
貢献を歓迎します！新しいアダプターの追加は簡単です。ServiceAdapter インターフェースを実装して登録するだけです。
git clone https://github.com/hebline/mcp-server.git
cd mcp-server
npm install
npm run build
npm testHebline によって構築されました — 無料を優先してルーティング。必要な時だけ支払います。
List all capabilities Hebline supports and which services are available for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('List'), but doesn't specify whether it requires authentication, has rate limits, returns structured data, or involves pagination. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's function without fluff. It's front-loaded with the core action ('List') and resource, making it easy to parse. Every word contributes to understanding, achieving ideal conciseness.
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 simplicity (0 parameters, no output schema), the description is adequate but not fully complete. It explains what the tool does but lacks details on return format, error handling, or behavioral constraints. With no annotations to fill gaps, it meets minimum viability but leaves room for improvement in guiding agent usage.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for missing param info. A baseline of 4 is appropriate as it avoids redundancy and focuses on the tool's purpose without unnecessary parameter details.
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 clearly states the tool's purpose: 'List all capabilities Hebline supports and which services are available for each.' It uses specific verbs ('List') and identifies the resource ('capabilities Hebline supports'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools (compare, execute), which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'compare' or 'execute'. It doesn't mention prerequisites, timing, or contextual triggers. While the purpose is clear, the lack of comparative or conditional guidance limits its utility for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare all available services for a capability. Shows scores, costs, and Hebline's recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | Capability to compare services for, e.g. 'geocoding', 'translation' | |
| constraint | No | Cost constraint filter | any |
| region | No | Region filter, e.g. 'eu', 'us' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions outputs (scores, costs, recommendation) but lacks details on behavioral traits such as data freshness, rate limits, authentication needs, or error handling. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the purpose. It could be slightly more structured by separating key points, but it avoids redundancy and wastes no words.
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 complexity (comparison with multiple outputs), lack of annotations, and no output schema, the description is incomplete. It hints at outputs but doesn't detail format or behavior, leaving gaps for the agent to handle mutations or errors.
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?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional meaning beyond what the schema provides, such as examples or constraints not in the schema, meeting the baseline for high coverage.
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 clearly states the verb 'compare' and the resource 'all available services for a capability', with specific outputs mentioned ('scores, costs, and Hebline's recommendation'). It distinguishes from sibling tools 'categories' and 'execute' by focusing on comparison rather than listing or execution.
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?
No guidance is provided on when to use this tool versus alternatives like 'categories' or 'execute'. The description implies usage for comparing services but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Route to the best service and execute the API call. Returns result with metadata (service used, cost, latency).
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | What you need, e.g. 'geocoding', 'translation' | |
| input | Yes | Service-specific input (e.g. { query: 'Berlin' } for geocoding, { text: 'Hello', target: 'de' } for translation) | |
| constraint | No | Cost constraint: 'free' = only free services, 'cheapest' = prefer lowest cost, 'any' = best overall | any |
| region | No | Preferred region, e.g. 'eu', 'us'. Omit for global. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that the tool returns 'result with metadata (service used, cost, latency)', which adds some behavioral context. However, it lacks details on permissions, rate limits, error handling, or side effects, which are important for a tool that executes API calls and routes services.
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 very concise and front-loaded: it states the core purpose in the first clause and adds return details in parentheses. Every sentence earns its place with no wasted words, making it efficient and well-structured.
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 complexity (executes API calls with routing) and lack of annotations/output schema, the description is moderately complete. It covers the purpose and return metadata, but gaps remain in behavioral details and usage guidelines. It's adequate but has clear room for improvement in context.
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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or usage examples). Baseline is 3 when schema coverage is high and description doesn't compensate.
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 clearly states the tool's purpose: 'Route to the best service and execute the API call.' It specifies the action (route and execute) and resource (API call), but doesn't distinguish it from sibling tools like 'categories' or 'compare' which have different purposes. The description is specific but lacks sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or other contexts, and offers no explicit when/when-not scenarios. Usage is implied (e.g., for API calls with routing), but no clear alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.9.1categoriescompareexecuteScored across 3 tools
Each tool has a clearly distinct purpose with no overlap: 'categories' lists capabilities and services, 'compare' analyzes service options with recommendations, and 'execute' routes and runs API calls. The separation between listing, comparing, and executing is unambiguous.
All tool names follow a consistent verb-only pattern in lowercase, with no mixing of conventions. The naming is straightforward and predictable across the set.
Three tools is well-scoped for the server's purpose of managing and executing API services through Hebline. Each tool earns its place by covering a distinct phase: discovery, comparison, and execution.
The tool set provides complete coverage for the domain: it allows agents to discover capabilities, compare service options, and execute calls with metadata. There are no obvious gaps in the workflow from start to finish.
AI model routing on your own vendor keys: pick the best model per prompt, or route and run it.
AI service marketplace — agents discover, call, and pay for API services automatically.
Stripe-native marketplace where AI agents discover and pay per call for API services.
AI routing, memory, guardrails, and governance. Routes across Claude, GPT, Gemini.
