Claude가 Lighthouse.one 포트폴리오 데이터와 상호 작용할 수 있도록 하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 통합을 통해 Claude를 통해 암호화폐 포트폴리오를 직접 쿼리하고 분석할 수 있습니다.
인증 : 전송 토큰 URL을 사용하여 Lighthouse에서 안전하게 인증합니다.
포트폴리오 개요 : 다음을 포함하여 포트폴리오의 자세한 분석을 확인하세요.
총 포트폴리오 가치
자산 유형 분포
주요 보유 자산(≥ $1,000)
연결된 지갑/계정 목록
자산 세부 정보 : 포트폴리오의 특정 자산에 대한 자세한 정보를 확인하세요.
거래 내역 : 여러 지갑에서 거래 내역에 액세스하세요
성과 분석 : 시간 경과에 따른 포트폴리오 성과에 대한 통찰력 얻기
클로드에게 성과, 자산 분배 등에 대한 자연어 질문을 하면 클로드는 최선을 다해 적절한 도구를 사용하여 답변을 생성해 줍니다.
Related MCP server: Chronos MCP Server
참고: 이 MCP 서버를 사용하려면 Node LTS 이상이 설치되어 있어야 합니다 . N-Install을 사용하여 시스템에 Node를 빠르게 설치해 보세요.
claude_desktop_config.json 에 다음을 추가하세요:
지엑스피1
그런 다음 Claude 앱을 다시 시작하세요. 시작 시 오류가 발생하지 않으면 MCP 서버가 작동 중인 것입니다.
인증 URL을 입력하라는 메시지가 표시됩니다. URL을 얻으려면 다음 단계를 따르세요.
Lighthouse.one의 설정 페이지로 이동하세요
"모바일 기기 연결" 옵션을 클릭하세요
"전송 링크 복사"를 클릭하세요
참고: URL은 Claude가 세션을 인증하는 데 사용할 수 있는 Lighthouse 전송 토큰 URL 형식입니다.
연결되면 Claude와 함께 다음 명령을 사용할 수 있습니다.
인증하다
Use the authenticate command with a Lighthouse transfer token URL to log in.포트폴리오 목록
Use the listLighthousePortfolios command to see all your portfolios and their total values.포트폴리오 개요 보기
Use the getLighthousePortfolio command to view your current portfolio status with detailed breakdowns.수확량 데이터 가져오기
Use the getLighthouseYieldData command to see yield information for your portfolio.성능 데이터 가져오기
Use the getLighthousePerformanceData command to analyze your portfolio's performance over time.서버는 인증을 유지하기 위해 세션 파일( .lighthouse_session )을 유지합니다.
명시적으로 로그아웃하거나 세션이 만료되지 않는 한 한 번만 인증하면 됩니다.
세션 데이터는 로컬 머신에 안전하게 저장됩니다.
참고: Lighthouse 대시보드에서 언제든지 세션 키를 취소할 수 있습니다.
이 MCP 서버는 사용자 컴퓨터에서 로컬로 실행되며 Lighthouse API와 직접 통신합니다. 사용자의 인증 정보는 Claude 또는 타사 서비스와 절대 공유되지 않습니다.
프로젝트를 빌드하세요:
npm install
npm run buildClaude에 MCP 서버 추가
이 JSON을 Claude 앱의 개발 설정에 붙여넣으세요. 올바른 빌드 출력을 가리키도록 하세요.
{
"mcpServers": {
"lighthouse": {
"command": "path/to/node/installation",
"args": ["path/to/this/folder/mcp-lighthouse/dist/index.js"]
}
}
}이 프로젝트는 TypeScript로 제작되었으며 MCP 서버 구현을 위해 FastMCP 프레임워크를 사용합니다. 기능을 수정하거나 확장하려면 다음을 수행하세요.
index.ts 를 변경하세요
프로젝트를 다시 빌드하세요: npm run build
서버를 다시 시작하세요
Node.js 16 이상
npm 또는 yarn
Lighthouse.one 계정
Authenticate with Lighthouse using a transfer token URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an authentication operation but doesn't describe what happens after authentication (e.g., session establishment, token storage, duration), whether it's idempotent, what errors might occur, or any rate limits. 'Authenticate' implies a state-changing operation, but the behavioral implications are underspecified.
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 with zero wasted words. It's front-loaded with the core purpose and includes the essential detail about the authentication method. Every element earns its place.
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?
For an authentication tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. Authentication is a critical, state-changing operation that requires clear behavioral disclosure about what happens after authentication, error conditions, and session management. The description provides only the basic purpose without addressing these complexities.
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 0%, so the description must compensate. It mentions 'transfer token URL' which provides some semantic context for the single 'url' parameter, but doesn't explain what format this URL should have, where to obtain it, or what constitutes a valid transfer token. The description adds minimal value beyond the bare parameter name.
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 ('Authenticate') and resource ('with Lighthouse'), specifying the action and target system. It distinguishes from sibling tools which are all data retrieval operations, but doesn't explicitly contrast with them. The mention of 'using a transfer token URL' adds specificity about the authentication method.
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 explicit guidance on when to use this tool versus alternatives is provided. The description implies this is for initial authentication, but doesn't state prerequisites, when authentication is required, or how this relates to the sibling data retrieval tools that presumably require authentication first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance data for a Lighthouse portfolio
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | No | Optional portfolio name | |
| startDate | No | Optional start date. Formatted as YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't describe whether this is a read-only operation, what the return format looks like (e.g., structured data, metrics), potential rate limits, or error conditions. This leaves significant gaps in understanding how the tool behaves beyond its simple purpose.
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 purpose without unnecessary words. It's appropriately sized for a simple data retrieval tool and front-loaded with the core action, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a data retrieval tool. It doesn't explain what 'performance data' entails (e.g., metrics, time series, aggregated results) or how results are structured, which is critical for an agent to interpret outputs. The simplicity of the tool (2 optional parameters) doesn't compensate for these missing behavioral details.
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 input schema has 100% description coverage, clearly documenting both optional parameters ('portfolio' and 'startDate') with formatting details for the date. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for any gaps.
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 action ('Get performance data') and target resource ('for a Lighthouse portfolio'), making the purpose understandable. However, it doesn't differentiate this tool from its sibling 'getLighthouseYieldData' which suggests another type of portfolio data, leaving some ambiguity about what specifically distinguishes 'performance data' from 'yield data'.
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 'getLighthouseYieldData' or 'getLighthousePortfolio'. It doesn't mention prerequisites (e.g., whether authentication is required via the 'authenticate' sibling tool) or context for selecting this specific data retrieval method, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and display a detailed summary of a Lighthouse portfolio with breakdown by asset types and major holdings.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | No | Optional portfolio name to select a specific portfolio to display a summary for |
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 states the tool fetches and displays data, implying a read-only operation, but doesn't address key aspects like authentication requirements, rate limits, error conditions, or response format. The description lacks details on what 'detailed summary' entails beyond asset types and holdings, leaving behavioral traits unclear.
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, well-structured sentence that efficiently conveys the core action and output. It avoids redundancy and front-loads key information. However, it could be slightly more concise by merging 'fetch and display' into a single verb like 'retrieve', but this is minor.
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 no annotations and no output schema, the description is incomplete for a tool that fetches detailed data. It mentions 'detailed summary' but doesn't specify what that includes beyond asset types and holdings, leaving gaps in understanding the return value. For a read operation with potential complexity, more context on output structure or behavior is 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?
Schema description coverage is 100%, with the single parameter 'portfolio' documented as an optional string for selecting a specific portfolio. The description adds no additional parameter semantics beyond what the schema provides, such as default behavior if omitted or examples of portfolio names. Baseline score of 3 is appropriate since the schema adequately covers the parameter.
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 with specific verbs ('fetch and display') and resources ('detailed summary of a Lighthouse portfolio'), including what information is provided ('breakdown by asset types and major holdings'). It distinguishes from siblings like 'listLighthousePortfolios' by focusing on detailed summaries rather than listing portfolio names. However, it doesn't explicitly contrast with performance or yield data tools, preventing 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 'getLighthousePerformanceData' or 'getLighthouseYieldData'. It mentions fetching a 'detailed summary' but doesn't clarify if this should be used for overviews versus those tools for specific metrics. No prerequisites, exclusions, or explicit alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get yield data for a Lighthouse portfolio
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | No | Optional portfolio name to select a specific portfolio to display a summary for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states what the tool does without details on permissions, rate limits, data format, or response behavior. It doesn't add meaningful context beyond the basic purpose, leaving gaps in understanding how the tool behaves.
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 purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'yield data' entails, the return format, or any behavioral traits, making it inadequate for a tool that likely returns financial data without further 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 the 'portfolio' parameter as optional for selecting a specific portfolio. The description doesn't add any extra meaning or context about the parameter beyond what's 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 action ('Get') and resource ('yield data for a Lighthouse portfolio'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'getLighthousePerformanceData' or 'getLighthousePortfolio', which likely retrieve different types of portfolio information, so it misses full sibling distinction.
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. The description lacks context about when yield data is needed compared to performance data or portfolio details, and there's no mention of prerequisites or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Lighthouse portfolios, their total portfolio value, the wallets within each portfolio and their total value
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what data is returned but lacks critical behavioral details: whether this is a read-only operation, if it requires authentication (implied by sibling 'authenticate'), pagination or rate limits, or error conditions. The description is insufficient for a tool with zero 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 core action ('List all Lighthouse portfolios') and specifies the exact data returned. Every word adds value with zero waste or redundancy.
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 no annotations, no output schema, and a read operation that likely requires authentication (based on sibling tools), the description is incomplete. It covers what data is returned but omits behavioral context like authentication requirements, response format, or error handling, which are essential for proper tool invocation.
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 with 100% schema description coverage (empty schema), so no parameter documentation is needed. The description appropriately focuses on output semantics, establishing a baseline of 4 for zero-parameter tools that describe their purpose clearly.
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 'List' and the resource 'Lighthouse portfolios', specifying exactly what data is returned: portfolios, their total value, wallets within each, and wallet values. It distinguishes from siblings like getLighthousePortfolio (singular) and getLighthousePerformanceData (performance metrics).
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 implies usage for retrieving portfolio lists with values, but provides no explicit guidance on when to use this versus alternatives like getLighthousePortfolio (for a single portfolio) or getLighthousePerformanceData (for performance data). No exclusions or prerequisites are mentioned.
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.
v1.0.0authenticategetLighthousePerformanceDatagetLighthousePortfoliogetLighthouseYieldDatalistLighthousePortfoliosScored across 5 tools
Each tool has a clearly distinct purpose: authentication, listing portfolios, getting portfolio details, and retrieving performance and yield data. There is no overlap in functionality, making it easy for an agent to select the correct tool for each task.
The naming is mixed with inconsistent patterns: 'authenticate' uses a verb only, while others use a verb_noun format (e.g., 'getLighthousePerformanceData'). However, all names are readable and follow a general descriptive style, though they lack a uniform convention.
With 5 tools, the server is well-scoped for managing Lighthouse portfolios. Each tool serves a specific and necessary function, from authentication to data retrieval, without being overly sparse or bloated.
The toolset covers core operations for portfolio management, including authentication, listing, and detailed data retrieval. A minor gap exists in update or delete operations for portfolios, but the provided tools support essential workflows effectively.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Connect your portfolio to Claude, ChatGPT, or Codex to analyze it and make smarter investments.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
