How do I use projectionlab-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@projectionlab-mcp export my financial data" 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.

projectionlab-mcp

by mormubis

Overview Schema Related Servers Score Discussions

TypeScript

Local

ProjectionLab MCP Server

MCP server for ProjectionLab — export, snapshot, and restore your financial plans. Includes a built-in FIRE advisor knowledge base for analyzing Financial Independence scenarios.

Why this approach

Most MCP servers that connect to third-party services ask you to paste API keys into config files, environment variables, or .env files. That key then lives on disk, gets passed through the MCP protocol, and travels through the AI conversation — where it can end up in logs, history, or training data.

This server works differently:

Your API key never leaves the browser. The key is extracted from the ProjectionLab settings page, stored in the browser's sessionStorage, and used there. The MCP server never sees it. The AI never sees it. It doesn't exist in any config file, environment variable, or conversation log. Other ProjectionLab MCPs store the key in plaintext files on disk or pass it through environment variables.
Everything runs in a browser you can see. This server doesn't make hidden API calls on your behalf. It generates JavaScript that executes in a browser tab where ProjectionLab is open. You can watch every operation happen in real time — open DevTools, inspect network requests, see exactly what's being read or written. Nothing is opaque. Other approaches run headless browsers in the background where you can't observe what's happening.
Zero infrastructure. No bundled Chromium, no background daemons, no Firefox + GeckoDriver, no Rust toolchain. The only dependencies are the MCP SDK and zod. It works with whatever browser MCP you already have running.
Snapshots are redacted automatically. When you save financial data locally, any field named key, apiKey, or pluginKey is replaced with [REDACTED] before writing to disk.
Published with provenance. Every release is built and published from GitHub Actions via npm trusted publishing. No long-lived tokens, no manual publishes. You can verify that the package on npm was built from this repo — npm audit signatures confirms the cryptographic link between the published tarball and the exact commit that produced it.

The trade-off is that you need a browser automation MCP running alongside this one. But for something as sensitive as your financial data, that transparency is worth it.

Related MCP server: pocketledger

Features

Guided API key setup — securely extracts and validates the key entirely in the browser
Full data export — returns a script that exports all plans, accounts, income, expenses, and settings
Local snapshots — save exports as timestamped JSON files with automatic API key redaction
Snapshot restore — generate scripts to restore plans and current finances from any snapshot
FIRE knowledge base — curated resource with links to FIRE concepts, withdrawal strategies, and ProjectionLab help docs

Prerequisites

This server generates JavaScript that must be executed in a browser where ProjectionLab is open. You need a browser automation MCP alongside this one:

Chrome DevTools MCP or Playwright MCP
A ProjectionLab Premium account with Plugins enabled

API

Tools

pl_setup
- Guided two-step API key configuration
- Step 1 (no args): returns the settings URL, a browser extraction script, and setup instructions
- Step 2 (validationResult): confirms the key is valid and ready
- The extraction script reads the key from the DOM, stores it in sessionStorage, and validates it — all client-side
pl_export
- Returns a JavaScript string that exports all ProjectionLab data
- Execute the script in the browser; pass the result to pl_snapshot to save it
- Annotations: readOnlyHint: true
pl_snapshot
- Saves export data as a local JSON file
- Input: data (required) — the export result from running the pl_export script in the browser
- Input: label (optional) — appended to the snapshot filename
- API keys are automatically redacted before writing
pl_list_snapshots
- Lists all saved snapshots, sorted newest first
- Returns filename, path, creation time, and size
- Annotations: readOnlyHint: true
pl_restore
- Reads a snapshot file and returns JavaScript strings to restore the data
- Input: snapshotPath (required) — absolute path to the snapshot file
- Returns one script per data section (plans, current finances); execute each in order
- Always take a snapshot of the current state before restoring

Resources

projectionlab://knowledge
- Curated index of ProjectionLab documentation URLs organized by topic
- Covers FIRE concepts, withdrawal strategies, and ProjectionLab features

Usage with Claude Desktop

Add this to your claude_desktop_config.json:

NPX

{
  "mcpServers": {
    "projectionlab": {
      "command": "npx",
      "args": ["-y", "@mormubis/projectionlab-mcp"]
    }
  }
}

Local (from source)

{
  "mcpServers": {
    "projectionlab": {
      "command": "node",
      "args": ["/path/to/projectionlab-mcp/dist/index.js"]
    }
  }
}

Usage with VS Code

Add this to your .vscode/mcp.json:

{
  "servers": {
    "projectionlab": {
      "command": "npx",
      "args": ["-y", "@mormubis/projectionlab-mcp"]
    }
  }
}

Configuration

Variable	Description	Default
`PROJECTIONLAB_SNAPSHOTS_DIR`	Directory for snapshot files	`~/.config/projectionlab/snapshots`
`PROJECTIONLAB_BASE_URL`	ProjectionLab base URL	`https://app.projectionlab.com/`

Security

The API key never leaves the browser. During setup, a script runs inside the browser tab to read the key from the DOM, store it in sessionStorage, and validate it against the Plugin API. The only value that returns to the conversation is a boolean.

All other scripts (export, restore) read the key from sessionStorage at runtime. Snapshots are redacted before writing — any field named key, apiKey, or pluginKey is replaced with [REDACTED].

Build

npm install
npm run build

License

This project is licensed under the MIT License. See LICENSE for details.

Available Tools

5 tools

pl_exportExport ProjectionLab DataA

Read-only

Returns a JavaScript string that exports all ProjectionLab data via the Plugin API. Execute this script in the browser using the Playwright or chrome devtools MCP.

The script reads the API key from sessionStorage, set during pl_setup. If the browser tab was closed since setup, run pl_setup again first.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds context beyond the readOnlyHint annotation by disclosing that the tool returns a script rather than performing the export directly, and that it reads the API key from sessionStorage set during pl_setup. This is useful behavioral information. It does not contradict the annotation, and while it doesn't detail return format, the added context is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, and every sentence adds necessary operational detail. There is no repetition of schema or annotation information, and no filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the zero-parameter input, the readOnlyHint annotation, and lack of output schema, the description adequately covers how to use the tool and its prerequisites. It explains the returned script's execution context and dependency on setup. It could mention the data format or error scenarios, but these are not essential for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the description correctly avoids discussing any. The parameter schema is empty, and the description doesn't need to compensate. Baseline for 0 params is 4, which is appropriate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Returns a JavaScript string that exports all ProjectionLab data via the Plugin API.' This clearly distinguishes it from sibling tools like pl_setup, pl_snapshot, pl_list_snapshots, and pl_restore, which handle setup and snapshot lifecycle. The purpose is unambiguous and informative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear execution context: 'Execute this script in the browser using the Playwright or chrome devtools MCP.' It also states the prerequisite that pl_setup must have run and that rerunning is necessary if the tab was closed. This is practical guidance, though it does not explicitly mention alternatives or when not to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pl_list_snapshotsList SnapshotsA

Read-only

List all saved local snapshots, sorted newest first. Returns filename, path, creation time, and size.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the annotation: it discloses the sorting order and the exact return fields (filename, path, creation time, size). The readOnlyHint annotation already signals safety, and the description enriches that with specifics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that conveys the essence: what it does ('List all saved local snapshots'), ordering ('newest first'), and output (four specific fields). No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no parameters and no output schema, so the description carries the full burden. It mentions the sorting, the scope ('all'), and the exact return fields, making the tool's behavior and results fully predictable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and an empty schema, the description necessarily carries no parameter info, but baseline 4 applies per the rubric. The description's mention of return fields gives a sense of what the tool operates on, which is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Purpose is explicitly stated with a specific verb and resource: 'List all saved local snapshots'. It also specifies the ordering ('sorted newest first') and distinct return fields, clearly distinguishing it from sibling tools that create, export, restore, or set up snapshots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use this tool: whenever you need to list snapshots. It doesn't explicitly mention exclusions or alternatives, but there are no other listing tools among the siblings, so the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pl_restoreRestore from SnapshotA

Read a local snapshot file and return JavaScript strings to restore the data via the Plugin API. Execute each script in the browser using the Playwright or chrome devtools MCP.

The scripts read the API key from sessionStorage, set during pl_setup. If the browser tab was closed since setup, run pl_setup again first.

Important: take a snapshot of the current state BEFORE restoring (run pl_export in the browser, then call pl_snapshot with the result).

ParametersJSON Schema

Name	Required	Description	Default
`snapshotPath`	Yes	Absolute path to the snapshot file to restore

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses that the tool returns JavaScript strings, reads the API key from sessionStorage, depends on prior setup, and warns to snapshot before restoring. It does not explicitly state that the restore overwrites/destroys current data, but the strong safety warning implies it. This is substantial beyond what the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then each subsequent sentence earns its place: execution instructions, sessionStorage/setup dependency, and a safety warning. It is compact with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description explains the overall workflow: reading a snapshot, returning scripts, executing them in a browser, handling setup expiration, and taking a pre-restore snapshot. The only notable gap is the lack of an explicit statement about the destructive nature of the restore operation, but the caution addresses it indirectly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes snapshotPath as 'Absolute path to the snapshot file to restore' with 100% coverage. The description only refers to 'a local snapshot file' without adding any new detail about the parameter's format, constraints, or behavior. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence uses a specific verb and resource: 'Read a local snapshot file and return JavaScript strings to restore the data via the Plugin API.' It clearly differentiates from siblings like pl_snapshot (creating a snapshot) and pl_export (exporting current state) by focusing on restoring from a snapshot via generated scripts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear execution context: run the returned scripts in the browser using Playwright or Chrome DevTools MCP. It also states a prerequisite (run pl_setup again if the tab closed) and a strong recommendation to snapshot before restoring. It lacks explicit 'when not to use' or alternative tool references, but the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pl_setupSetup ProjectionLabA

Guided setup for the ProjectionLab Plugin API key.

Two-step flow:

Call with no args — returns instructions and a browser script that extracts, stores, and validates the key entirely in the browser.
Call with validationResult — confirms the key is valid and setup is complete.

The API key NEVER leaves the browser. The extractScript reads it from the DOM, stores it in sessionStorage, and validates it — all client-side. The only value that comes back to the conversation is a success/failure boolean.

The extractScript should be executed in the browser via the Playwright or chrome devtools MCP.

ParametersJSON Schema

Name	Required	Description	Default
`validationResult`	No	Result from executing the extractScript in the browser

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: the API key never leaves the browser, uses sessionStorage, runs client-side validation, and returns only a success/failure boolean. It also clarifies the two-step state machine, making the tool's internal behavior predictable and safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with a concise summary, followed by numbered steps and security details. Every sentence contributes useful information without redundancy, and the format is easy to parse for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional param, no output schema), the description covers all necessary context: the two-step flow, security model, what the script does, how to execute it, and the return value. No critical gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the schema's minimal 'Result from executing the extractScript'. It explains that validationResult confirms key validity and completes setup, and clarifies that calling with no args triggers the first step. This is essential contextual information for correctly using the optional parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Guided setup for the ProjectionLab Plugin API key' with a specific verb and resource. It distinguishes setup from sibling tools like pl_export and pl_snapshot by focusing on API key initialization and validation rather than data operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit step-by-step usage: call with no args first, then call with validationResult. It also directs the user to execute the extractScript via Playwright or chrome devtools MCP. It lacks explicit when-not-to-use or alternative guidance, but the flow is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pl_snapshotSave SnapshotA

Save ProjectionLab export data as a local snapshot file. Pass the data you got from running the pl_export script in the browser. API keys are redacted before writing.

ParametersJSON Schema

Name	Required	Description	Default
`data`	No	The export data from ProjectionLab (result of running the pl_export script)
`label`	No	Optional label appended to the snapshot filename

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It discloses a notable behavioral trait: 'API keys are redacted before writing.' However, it does not mention overwrite behavior, file location, or return values, though these are less critical for a simple snapshot save.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose. Every sentence adds value: the first states the action and target, the second explains how to obtain data and the redaction behavior. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no output schema and no annotations, the description is largely complete: it states the action, what data to pass, and an important post-processing detail (redaction). Missing return value/error info is a minor gap, but the tool's simplicity reduces the risk of misuse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 extra meaning by specifying that 'data' comes from running the pl_export script in the browser, which clarifies how to obtain and pass the parameter. The 'label' parameter is already described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Save ProjectionLab export data as a local snapshot file,' using a specific verb and resource. It distinguishes from sibling tools (pl_export, pl_list_snapshots, pl_restore) by indicating this tool writes data to a local snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The instruction 'Pass the data you got from running the pl_export script in the browser' provides clear context of when to use this tool, tying it to the pl_export workflow. It does not explicitly mention exclusions or alternatives, but the sibling names make the intended use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.3.4Jul 31, 2026
- First observedpl_export
- First observedpl_list_snapshots
- First observedpl_restore
- First observedpl_setup
- First observedpl_snapshot

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clearly distinct role: setup handles API key configuration, export retrieves data from the browser, snapshot saves data locally, list_snapshots shows saved files, and restore reloads data. There is no overlap or ambiguity between them.

Naming Consistency4/5

All tools share the 'pl_' prefix and use snake_case, which is consistent. The pattern varies slightly: some are bare verbs (pl_setup, pl_export, pl_restore) while others combine verb and noun (pl_snapshot, pl_list_snapshots), but the naming remains predictable and readable.

Tool Count5/5

Five tools is well-scoped for this server's purpose—managing ProjectionLab data backups and restores. Each tool is necessary for the workflow, and there are no redundant or unnecessary additions.

Completeness4/5

The set covers the core lifecycle: setup, export, save, list, and restore. The only notable gap is the lack of a delete-snapshot tool, but this is a minor omission that does not prevent the primary backup/restore workflow from working.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113398
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
Bonsave
app.bonsave
Query your real net worth, spending, transactions, budgets and portfolio from any MCP client.
Finance
1
savvly A
com.savvly
Savvly MCP: query fund data, model projections, and compare against alternative retirement products.
Finance
832

Related MCP Servers

monarch-mcp
Finance
bkichler
F
license
B
quality
D
maintenance
MCP server that bridges Claude to Monarch Money for personal-finance analysis and lightweight edits.
Updated 4 months ago (2026-05-04 02:13 UTC)
18
-
pocketledger
ektamishra4321
F
license
Not graded
quality
B
maintenance
MCP server for personal finance management. Enables natural language expense logging, budgeting, recurring charge detection, and statement import with deterministic local calculations.
Updated 2 months ago (2026-07-21 12:01 UTC)
-
RetireGolden MCPofficial
Finance AI & Machine Learning
RetireGolden
A
license
B
quality
B
maintenance
Headless MCP server for the RetireGolden retirement-planning calculator, providing typed tools to build/validate plans, run projections, Monte Carlo simulations, and optimization via stdio.
Updated 2 days ago (2026-09-05 00:50 UTC)
14
330
AGPL 3.0
agnifolio-mcp
Finance Cryptocurrency
nivela-tech
A
license
A
quality
A
maintenance
Official MCP server for Agni Folio, a free multi-currency wealth & portfolio tracker. 23 tools for holdings, performance, FIRE planning, crypto P&L, and confirm-gated writes — hosted endpoint with OAuth 2.1, plus a Docker stdio bridge in this repo.
Updated a month ago (2026-08-07 15:58 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mormubis/projectionlab-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ProjectionLab MCP Server

Why this approach

Features

Prerequisites

API

Tools

Resources

Usage with Claude Desktop

NPX

Local (from source)

Usage with VS Code

Configuration

Security

Build

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

RetireGolden MCPofficial

Latest Blog Posts

MCP directory API