Enables access to Lighthouse.one portfolio data, including portfolio overview, asset details, transaction history, and performance analysis of crypto investments.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Lighthouse MCP show me my portfolio overview"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables Claude to interact with your Lighthouse.one portfolio data. This integration allows you to query and analyze your crypto portfolio directly through Claude.
Authentication: Securely authenticate with Lighthouse using transfer token URLs
Portfolio Overview: Get detailed breakdowns of your portfolio including:
Total portfolio value
Asset type distribution
Major holdings (≥ $1,000)
List of connected wallets/accounts
Asset Details: View detailed information about specific assets in your portfolio
Transaction History: Access your transaction history across wallets
Performance Analysis: Get insights on portfolio performance over time
You can ask Claude any form of natural language questions about performance, assets distribution etc and it will try its best to invoke the right tools and generate an asnwer for you.
Related MCP server: Chronos MCP Server
NOTE: You must have at least Node LTS installed to use this MCP server. Try N-Install to quickly install Node on your system.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"lighthouse": {
"command": "npx",
"args": ["-y", "mcp-lighthouse"]
}
}
}Then restart the Claude app. If you don't get any errors on startup, then the MCP server is working.
You'll be asked for the authentication URL. To get it, follow these steps:
Go to the Settings page on Lighthouse.one
Click on "Link Mobile Device" option
Click on "Copy transfer link"
Note: The URL will be in the format of a Lighthouse transfer token URL which Claude can use to authenticate your session.
Once connected, you can use the following commands with Claude:
Authenticate
Use the authenticate command with a Lighthouse transfer token URL to log in.List Portfolios
Use the listLighthousePortfolios command to see all your portfolios and their total values.Get Portfolio Overview
Use the getLighthousePortfolio command to view your current portfolio status with detailed breakdowns.Get Yield Data
Use the getLighthouseYieldData command to see yield information for your portfolio.Get Performance Data
Use the getLighthousePerformanceData command to analyze your portfolio's performance over time.The server maintains a session file (.lighthouse_session) to persist your authentication
You only need to authenticate once unless you explicitly log out or the session expires
Session data is stored securely on your local machine
NOTE: You can always revoke the session key from the Lighthouse dashboard.
This MCP server runs locally on your machine and communicates directly with Lighthouse's API. Your authentication credentials are never shared with Claude or any third-party services.
Build the project:
npm install
npm run buildAdd the MCP server to Claude
Paste this JSON into the Develop settings of the Claude app. Make sure to point to the correct build output.
{
"mcpServers": {
"lighthouse": {
"command": "path/to/node/installation",
"args": ["path/to/this/folder/mcp-lighthouse/dist/index.js"]
}
}
}The project is built with TypeScript and uses the FastMCP framework for MCP server implementation. To modify or extend the functionality:
Make changes to index.ts
Rebuild the project: npm run build
Restart the server
Node.js 16 or higher
npm or yarn
A Lighthouse.one account
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. Dates show when Glama detected each change.
v1.0.0authenticategetLighthousePerformanceDatagetLighthousePortfoliogetLighthouseYieldDatalistLighthousePortfoliosEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/l3wi/mcp-lighthouse'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
