模型上下文协议 (MCP) 服务器，使 Claude 能够与您的 Lighthouse.one 投资组合数据进行交互。此集成允许您直接通过 Claude 查询和分析您的加密货币投资组合。
身份验证：使用传输令牌 URL 安全地与 Lighthouse 进行身份验证
投资组合概览：获取您的投资组合的详细分类，包括：
投资组合总价值
资产类型分布
主要持股（≥1,000 美元）
已连接钱包/账户列表
资产详情：查看您投资组合中特定资产的详细信息
交易历史记录：访问跨钱包的交易历史记录
绩效分析：了解投资组合随时间的变化
您可以向 Claude 询问任何形式的自然语言问题，例如性能、资产分配等，它会尽力调用正确的工具并为您生成答案。
Related MCP server: Chronos MCP Server
注意：您必须至少安装 Node LTS 才能使用此 MCP 服务器。请尝试使用N-Install快速在您的系统上安装 Node。
将其添加到您的claude_desktop_config.json中：
{
"mcpServers": {
"lighthouse": {
"command": "npx",
"args": ["-y", "mcp-lighthouse"]
}
}
}然后重启 Claude 应用程序。如果启动时没有出现任何错误，则表示 MCP 服务器正常运行。
系统将要求您提供身份验证 URL。要获取该 URL，请按以下步骤操作：
前往 Lighthouse.one 的“设置”页面
点击“链接移动设备”选项
点击“复制转账链接”
注意：该 URL 将采用 Lighthouse 传输令牌 URL 的格式，Claude 可以使用它来验证您的会话。
连接后，您可以对 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 build将 MCP 服务器添加到 Claude
将此 JSON 粘贴到 Claude 应用的“开发”设置中。确保指向正确的构建输出。
{
"mcpServers": {
"lighthouse": {
"command": "path/to/node/installation",
"args": ["path/to/this/folder/mcp-lighthouse/dist/index.js"]
}
}
}该项目使用 TypeScript 构建，并使用 FastMCP 框架实现 MCP 服务器。如需修改或扩展功能，请执行以下操作：
对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
