에이전트가 모든 API 호출에 과도한 비용을 지불하고 있습니다. 저희가 해결해 드립니다.
Hebline은 모든 API 호출(LLM 호출 포함)을 적절한 가격의 최적 서비스로 라우팅합니다. 충분할 때는 무료로, 중요할 때는 유료로. Hebline은 그 차이를 알고 있습니다.
다른 모든 라우터는 유료 호출에서 마진을 남깁니다. 무료 대안으로 라우팅하면 그들의 수익이 줄어듭니다. API 호출에 마진은 없습니다. 절대 없습니다.
에이전트가 돈을 낭비하고 있습니다. 하나의 작업이 서로 다른 제공업체에 걸쳐 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 ( |
웹 스크래핑 | 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}콘텐츠는 기록되지 않으며 메타데이터만 기록됩니다. 이 데이터는 향후 버전에서 헤브 학습(Hebbian Learning)의 기반이 됩니다.
[x] stdio 전송을 사용하는 핵심 MCP 서버
[x] 가중치 점수 라우터
[x] 지오코딩 어댑터 (Nominatim, Google Maps)
[x] 번역 어댑터 (MyMemory, LibreTranslate, DeepL)
[x] BYOK 키 관리
[x] 추가 전용(Append-only) 호출 로깅
[x] GitHub Actions를 사용한 CI/CD
[ ] 헤브 학습(Hebbian Learning) — 라우터가 호출 기록에서 학습
[ ] Hopfield 네트워크 점수 산정 (가중치 점수 산정 대체)
[ ] 더 많은 카테고리 (웹 스크래핑, 통화, OCR, 이메일)
[ ] 커뮤니티 어댑터 시스템
[ ] 원격 배포를 위한 SSE 전송
[ ] 비용 분석을 위한 웹 대시보드
[ ] 예산 알림 및 지출 한도
[ ] 다중 에이전트 비용 귀속
기여를 환영합니다! 새로운 어댑터를 추가하는 것은 간단합니다. 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.
