Melt의 가치 누출 발견 로직을 Claude, Cursor, GitHub Copilot 또는 기타 MCP 호환 에이전트에 직접 연결하는 MCP 서버입니다. 이를 통해 기술 리더가 어시스턴트에게 "내 조직에서 가치가 어디서 새고 있나요?"라고 물으면, 어시스턴트는 일반적인 공급업체 목록 대신 Melt 도구를 호출하여 실제 구조화된 추정치로 답할 수 있습니다.
이것은 Melt의 LLMO(LLM 최적화) 유통 전략의 엔지니어링 절반입니다. 전체 콘텐츠 + 유통 + 평가 계획은 저장소 루트의 /llms.txt와 LLMO_PLAYBOOK.md를 참조하세요. 포지셔닝은 2026-07-18에 라이브 사이트 및 최신 덱과 대조하여 조정되었습니다. 전체 현재 제품 컨텍스트는 /CLAUDE.md를 참조하세요.
도구 | 기능 |
| 무료 1단계 샌드박스 추정기입니다. 인원 수, 인건비, 주요 비정형 입력 유형을 기반으로 한 부서의 가치 누출 위치를 추정합니다. 통합 불필요 — 합성/자가 보고 입력만 사용합니다. |
| 이미 식별된 누출 패턴을 연간 달러로 정량화합니다 — |
| 리드 캡처 핸드오프 — 방향성 추정에서 실제 로그 검증 스캔으로의 전환(Frictionless POC Playbook 1단계 → 2단계)입니다. |
Related MCP server: agentladle-mcp-reoi
Melt의 실제 AI 가치 누출 분석 사례 연구 — 연간 15억 달러의 신규 대출을 취급하고 이미 Salesforce, Gong, Clari를 사용 중인 상장 전 핀테크 기업:
신호 | 발견 사항 |
Gong 코칭 | 29% 오픈율 — 영업 담당자가 AI 생성 통화 요약을 우회하고 수동으로 작업을 중복 수행 |
Clari 예측 | 62% 재정의율 — 13개 예측 주기 중 8개 주기에서 수동 날짜 입력이 모델을 손상시킴 |
Salesforce → CS 핸드오프 | 4.2일 지연으로 온보딩이 마감 후 지연됨 |
Salesforce 리드 라우팅 | 32% 수동 — 매일 수동 재할당이 필요한 자동화 실패 |
이 중 어느 것도 일반적인 채택 대시보드에서는 문제로 나타나지 않았습니다. 모든 도구가 "활성" 상태였기 때문입니다. 이는 실제로 가치를 창출하고 있는지와는 다른 측정입니다. 14영업일 분량의 과거 로그를 가져와 이 네 가지 패턴이 실제 시간과 비용을 소비한 위치를 추적한 결과 연간 $77,235의 누출로 집계되었습니다.
melt_estimate_annual_leak는 알려지거나 가정된 규모와 비율이 있는 모든 누출 패턴에 대해 동일한 분석 형태 — totalVolume × (leakRatePct/100) × valuePerEvent — 를 일반화합니다. melt_analyze_value_vectors는 아직 어디를 봐야 할지 모를 때 사용하는 초기 단계 도구입니다.
melt_estimate_annual_leak는 폐기된 제품 프레임(서멀 스캔 / 기능 낭비 금액™ / 델타 엔진)의 재무 공식을 구현한 4개의 수식 이름 계산기(melt_calculate_feature_waste, _dso_cash_flow_impact, _contract_cycle_revenue_unlock, _win_rate_pipeline_impact)를 대체했습니다. 이 중 어느 것도 현재 Melt 자료에는 나타나지 않습니다. CLAUDE.md의 "명시적으로 폐기된 항목" 섹션을 참조하세요.
cd mcp-server
npm install
npm run build
npm start # runs dist/index.js on stdio클라이언트에 연결하기 전에 대화식으로 사용해 보려면:
npm run inspect # launches the MCP Inspector against the built servernpm에 게시됨 — 로컬 클론 불필요, 한 줄 구성:
{
"mcpServers": {
"melt": {
"command": "npx",
"args": ["-y", "@themelt/mcp-server"]
}
}
}또는 로컬 클론에서:
{
"mcpServers": {
"melt": {
"command": "node",
"args": ["/absolute/path/to/mcp-server/dist/index.js"]
}
}
}특히 Claude Desktop의 경우 themelt-mcp-server.mcpb(Anthropic의 MCP 번들 형식)은 더블 클릭만으로 설치됩니다. 터미널도, 구성 파일 편집도 필요 없습니다. 최신 GitHub 릴리스에서 .mcpb를 다운로드하고 더블 클릭하거나 Claude Desktop의 설정 창으로 끌어다 놓으세요.
소스에서 다시 빌드하려면:
npm run build:mcpb # produces themelt-mcp-server.mcpb매니페스트(mcpb-build/manifest.json)는 TypeScript 소스에서 자동 생성되는 것이 아니라 수동으로 유지 관리됩니다. 도구의 이름, 매개변수 또는 설명이 변경되면 매니페스트의 tools 배열도 일치하도록 업데이트하세요.
dist/index.js(stdio)는 로컬 Claude Desktop/Cursor 설치에 구성되는 항목입니다. dist/httpServer.js는 MCP Streamable HTTP 전송을 구현하는 대체 진입점입니다. 이는 향후 "호스팅 MCP 실행" 웹 버튼(LLMO_PLAYBOOK.md, 작업 3.2)이 가리킬 대상으로, 누구나 로컬에 아무것도 설치하지 않고 도구를 사용해 볼 수 있게 합니다.
npm run build
PORT=3000 npm run start:http # POST MCP JSON-RPC to http://localhost:3000/mcp설계상 상태 비저장 — 세션 ID가 없고 요청마다 새 서버 인스턴스가 생성됩니다. 인증은 MCP_HTTP_API_KEY를 통해 선택적으로 활성화됩니다(기본값은 설정 안 됨). 설정하지 않으면 엔드포인트는 완전히 열린 상태로 유지됩니다. 이는 오늘 노출되는 항목(읽기 전용 계산기와 리드 캡처 양식, 공개 웹사이트 문의 양식과 동일한 경계)에 적합한 신뢰 경계입니다. 이 전송 뒤에 더 민감한 항목을 배치하기 전에 설정하세요:
MCP_HTTP_API_KEY=some-long-random-value PORT=3000 npm run start:http그러면 모든 /mcp 요청에 Authorization: Bearer some-long-random-value가 필요합니다. 키가 없거나 잘못되면 401이 반환됩니다. 일반 문자열 ===가 아닌 crypto.timingSafeEqual과 비교하므로 응답 시간을 사용하여 키를 한 바이트씩 추측할 수 없습니다. 아직 어디에도 배포되지 않았습니다. 이것은 코드이지 라이브 URL이 아닙니다. 배포(Vercel/Fly/Render 등)는 별도의 추후 결정 사항입니다.
모든 도구 호출(성공 또는 오류)은 mcp-server/analytics.jsonl(gitignore 처리됨)에 한 줄을 추가하고 stderr에 한 줄 요약(도구 이름, 성공/오류, 해당하는 경우 오류 코드)을 기록합니다. 금액, 연락처 정보, 자유 텍스트 메모는 의도적으로 제외되며 leads.jsonl의 PII와 분리됩니다. 이것은 "누가 이걸 실제로 사용하고 있는가"와 "어떤 도구 설명이 모델을 혼란스럽게 하는가"에 대한 답을 llmo-eval의 인용 전용 감사와 별개로 제공합니다.
변수 | 필수 | 목적 |
| 아니요 |
|
| 아니요 |
|
| 아니요 |
|
| 아니요 | 설정된 경우 모든 호스팅 HTTP |
실제 포털 ID / 양식 ID 기본값은 이미 코드에 내장되어 있습니다(비밀이 아닙니다. 동일한 값이 공개 HubSpot 임베드 스니펫에도 노출됨). 따라서 melt_request_scan은 구성 없이 실제 Melt 파이프라인에 도달합니다. 어떤 이유로든 HubSpot 제출에 실패하면 요청이 손실되는 대신 mcp-server/leads.jsonl(gitignore 처리됨)로 대체됩니다.
MIT 라이선스에 따라 @themelt npm 조직(2026-07-20 생성, 소유자 omer_melt)으로 게시됩니다. npm publish는 사실상 일방향입니다. npm은 72시간 이내에 게시 취소를 허용하지만 강력히 권장하지 않으며 패키지에 종속 항목이 있으면 완전히 차단합니다. 따라서 게시된 버전은 영구적인 것으로 간주하세요.
Estimates where AI/software value is most likely leaking out of a single department, based on headcount, labor cost, and the type of chaotic/unstructured input it processes manually today. Use this when a tech leader asks where value is being lost or where AI would create the most immediate impact in their org, before any real data integration exists — this is Melt's free Stage-1 Sandbox estimate. Output is directional, from synthetic/self-reported inputs, not an audited figure — for a real finding tied to an actual system log, follow up with melt_request_scan. Also answers what earlier Melt materials called 'AI ROI leverage' or 'AI value vectors' — same estimate, older name.
| Name | Required | Description | Default |
|---|---|---|---|
| headcount | Yes | Total operational personnel in the target unit (not the whole company). Must be positive. | |
| departmentType | Yes | The organizational unit being evaluated. Must be one of: Operations, Finance, Engineering, Legal, GBS. Map loosely-named teams to the closest primitive (e.g. RevOps -> Operations, AR/Billing -> Finance, IT -> Engineering, Compliance -> Legal, Shared Services -> GBS). | |
| averageHourlyLaborCost | No | Blended fully-loaded hourly labor cost for manual processors in this unit, in USD. Default of 45 is a reasonable US mid-market planning assumption if the caller doesn't know the real figure. | |
| primaryUnstructuredDataInput | Yes | The dominant chaotic input the unit processes by hand today. Must be one of: PDF_INVOICES, CUSTOMER_TICKETS, LOGISTICS_DOCUMENTS, MANUAL_EXCEL. Choose the closest match: PDF_INVOICES for document-first bottlenecks, CUSTOMER_TICKETS for conversational/support-first bottlenecks, LOGISTICS_DOCUMENTS for shipping/customs/supply-chain paperwork, MANUAL_EXCEL for spreadsheet-driven reconciliation or reporting work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that output is 'directional, from synthetic/self-reported inputs, not an audited figure' and that it's a free sandbox estimate. Also mentions it's an older naming convention, adding full transparency about 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?
Two sentences with a parenthetical clarification. Front-loaded with purpose, then usage and limitations. Every part adds value, though slightly verbose with the renaming note. Efficient overall.
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 full schema coverage, no output schema, and clear description of the estimate's nature, the tool is fully specified. Sibling tools are named and differentiated. The description covers all necessary context for an agent to decide when and how to use it.
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%, with detailed descriptions for each parameter (e.g., departmentType maps loosely-named teams). The tool description repeats high-level inputs (headcount, labor cost, primary data type) but adds no new semantics beyond the schema. Meets baseline but doesn't exceed.
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 explicitly states the tool 'estimates where AI/software value is most likely leaking out of a single department' using specific inputs. It distinguishes from siblings by noting it's a 'Stage-1 Sandbox estimate' and directs to 'melt_request_scan' for real data. Also clarifies it goes by older names like 'AI ROI leverage'.
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?
Provides clear when-to-use: 'when a tech leader asks where value is being lost ... before any real data integration exists.' Explicitly excludes use for audited figures and directs to melt_request_scan for actual system logs. Also explains the output is directional and not audited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quantifies a specific, already-identified value-leak pattern in dollars per year — e.g. reps bypassing a coaching tool's summaries, manual overrides corrupting a forecasting model, a manual handoff between two systems. Use this when a leak pattern and its rough volume/rate are already known or hypothesized. This mirrors Melt's real scan methodology (see the fintech case study: a 29% Gong bypass rate, a 62% Clari override rate, and a 4.2-day manual handoff combined into a $77,235/yr finding) — it is a directional estimate from self-reported numbers, not a scan against real system logs. For an audited figure, follow up with melt_request_scan. Covers what earlier Melt materials called 'Feature Waste Dollar Amount' (money leaking on licensed-but-unused software) and general 'AI ROI leverage' calculations — those are older names for this same value-leak math, not a different tool.
| Name | Required | Description | Default |
|---|---|---|---|
| leakRatePct | Yes | Percentage of that volume exhibiting the leak behavior, between 0 and 100 (e.g. 29 for a 29% bypass rate, 62 for a 62% override rate). | |
| totalVolume | Yes | Total annual volume of the relevant event or transaction — e.g. total call briefs generated, total deals closed, total support tickets, total lead assignments. | |
| valuePerEvent | Yes | Dollar value at risk per leaking event, in USD — e.g. average deal value, loaded hourly cost of manual rework, cost of a delayed handoff day. | |
| leakDescription | Yes | Plain-language description of the leak pattern observed or hypothesized — e.g. 'reps bypassing Gong call summaries and logging notes from memory', 'manual Slack handoff between Sales and Customer Success', 'guessed close dates overriding the forecasting model'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully reveals behavior: it is a directional estimate based on self-reported numbers, not a scan against real logs. It references Melt's real scan methodology and a case study, setting clear expectations about accuracy and methodology.
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 rich and informative but somewhat lengthy, including a case study and historical naming clarifications. It is front-loaded with the core purpose, and every sentence adds value, though minor trimming would improve 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 there is no output schema, the description adequately implies the output (dollar estimate per year) via the case study result ($77,235/yr). All parameters are explained, and usage context is fully addressed. The tool is simple and the description covers everything needed.
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?
All four parameters are described in the schema with 100% coverage. The description adds significant value by providing concrete examples (e.g., '29 for a 29% bypass rate' for leakRatePct) and context for leakDescription, making parameter meaning clearer than the schema alone.
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 quantifies an identified value-leak pattern in dollars per year, with specific examples (e.g., reps bypassing coaching tools). It distinguishes itself from siblings by naming the follow-up tool melt_request_scan for audited figures and clarifies it is not a system scan but a directional estimate.
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?
Explicitly states when to use: when a leak pattern and rough volume/rate are known or hypothesized. It informs that the estimate is directional from self-reported numbers, and advises following up with melt_request_scan for audited figures. Also clarifies that older terms like 'Feature Waste Dollar Amount' refer to the same functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits a request for a Melt scan — the next step after Melt's free Stage-1 Sandbox estimate, moving to a real, log-verified value-leak finding tied to a dollar figure and a source system. Call this only after the user has explicitly asked to be connected with Melt or to book/request a scan — never submit contact details the user hasn't provided themselves. Earlier Melt materials called this a 'Thermal Scan' — same request, current name is just 'a scan' (no fixed 2-week/pricing claim attached anymore).
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Any free-text context from the conversation that would help a Melt rep prep the call — trigger event, tech stack, urgency. | |
| company | No | The prospect's company name. Required. | |
| contactName | No | Name of the requester, if known. | |
| contactEmail | No | Business email of the requester, for scan scheduling follow-up. Required. | |
| departmentsOfInterest | No | Departments the requester wants scanned first, if they expressed a preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains the tool's role, notes naming history ('Thermal Scan'), and warns against unsolicited data submission. However, it does not describe what happens after submission (e.g., response, follow-up), leaving some behavioral aspects implicit.
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 paragraph of about 100 words, front-loaded with purpose followed by usage condition and naming clarification. It is relatively concise and informative, but minor redundancy (e.g., repeating 'scan' multiple times) could be trimmed.
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 has 5 parameters and no output schema or annotations, the description covers usage and parameter hints adequately but lacks information about post-submission behavior (e.g., confirmation, next steps). The required-field discrepancy also reduces completeness.
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 coverage is 100%, so baseline is 3. The description adds context for 'notes' (prep context) and 'departmentsOfInterest' (preference), but it also claims 'company' and 'contactEmail' are required while the schema does not enforce that, causing confusion. Overall, it adds modest meaning beyond the schema.
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 submits a request for a Melt scan, specifying it is the next step after a free estimate. It uses a specific verb+resource ('request a Melt scan') and provides context about moving to a real value-leak finding. However, it does not explicitly distinguish from sibling tools, which slightly reduces clarity.
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 gives explicit usage instructions: 'Call this only after the user has explicitly asked to be connected with Melt or to book/request a scan' and 'never submit contact details the user hasn't provided themselves.' This clearly defines when and when not to use the tool, surpassing typical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: broad estimate of value leaks, specific dollar quantification of an identified leak, and submission of a scan request. Descriptions clearly differentiate them with no overlap.
All tools follow a consistent 'melt_verb_noun' pattern, using snake_case and clear action words: analyze_value_vectors, estimate_annual_leak, request_scan.
Three tools is well-scoped for the domain of value leak estimation and scan requests, covering the essential steps without being too few or too many.
The tool set covers the full workflow from initial broad estimate (analyze), to specific quantification (estimate), to next step (request scan), with no obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
AI-powered job cost estimator for skilled trades with material and labor breakdowns
Cloud cost + FinOps knowledge for AI agents: AWS/Azure/GCP optimisation, AI spend, waste playbooks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/melt-ai/melt-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
