您的智能体在每次 API 调用上都支付了过高的费用。我们来解决这个问题。
Hebline 将每一次 API 调用（包括 LLM 调用）引导至性价比最高的合适服务。够用时选择免费，必要时选择付费。它懂得如何区分。
其他所有路由服务都会从您的付费调用中赚取差价。将您引导至免费替代方案会损害他们的收入。您的 API 调用绝无差价。永远不会。
您的智能体正在流失资金。一个任务可能会触发跨不同提供商的 5–10 次付费 API 调用。没有透明度，没有成本控制。Hebline 解决了这个问题：
优先路由至免费服务 — 大多数调用不需要最好的模型。Hebline 能精确判断何时需要，并随着市场变化不断学习。
无差价。诚实的路由。 — 我们不会在您支付更多费用时获利。因此，我们是唯一真正旨在为您节省资金的路由服务。
提供商抽象 — 您的智能体只需说明它需要什么（“对这个地址进行地理编码”），而无需指定使用哪个服务。无需更改智能体代码即可切换提供商。
成本透明度 — 每次调用都会记录所使用的服务、延迟和成本。确切了解您的智能体花费了多少。
从使用中学习 — 赫布学习（Hebbian learning）会强化有效的路径，削弱无效的路径。您的代理每天都在变得更聪明。
BYOK（自带密钥） — 付费服务通过环境变量使用您的 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您的智能体作为 MCP 服务器连接到 Hebline。它不再直接调用 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 ( |
网页抓取 | Fetch Scraper | Firecrawl ( |
货币 | ExchangeRate-API | Fixer.io ( |
OCR | OCR.space | Google Vision ( |
天气 | Open-Meteo | OpenWeatherMap ( |
网络搜索 | DuckDuckGo | Brave Search ( |
新闻 | HackerNews | NewsAPI.org ( |
9 个类别，20 个服务。 免费服务可立即使用——无需 API 密钥。当未设置本地密钥时，LLM 会通过 Hebline 代理进行路由（每天 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
[ ] 赫布学习 — 路由器从调用历史中学习
[ ] Hopfield 网络评分（取代加权评分）
[ ] 更多类别（网页抓取、货币、OCR、电子邮件）
[ ] 社区适配器系统
[ ] 用于远程部署的 SSE 传输
[ ] 用于成本分析的 Web 仪表板
[ ] 预算提醒和支出限制
[ ] 多智能体成本归因
欢迎贡献！添加新适配器非常简单——实现 ServiceAdapter 接口并注册它。
git clone https://github.com/hebline/mcp-server.git
cd mcp-server
npm install
npm run build
npm test由 Hebline 构建 — 优先路由至免费服务。仅在必要时付费。
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.
