# longbook (npm · @longbook/mcp)

Your longbook of bills, subscriptions and expenses, for your AI to read and to suggest changes to.

- Trust score: 63/100 (medium)
- Change this week: +29
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-18

## Components

- remote · `longbook.app`: 38/100, [markdown](https://verifymcp.io/servers/app-longbook-mcp/longbook.md), [page](https://verifymcp.io/servers/app-longbook-mcp/longbook)
- npm · `@longbook/mcp`: 63/100 (this document), [markdown](https://verifymcp.io/servers/app-longbook-mcp/longbook-mcp.md), [page](https://verifymcp.io/servers/app-longbook-mcp/longbook-mcp)

## Channel facts

- Registry: `npm`
- Package: `@longbook/mcp`
- Version: `1.40.4`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-18.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 19/100
  - Repository check failed: the declared repository URL returned HTTP 404.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (GPL-3.0-only).
  - Actively maintained (last published 5 days ago).
  - Security-disclosure policy not yet verified: we couldn't inspect the source repository.
- **Schema Quality & AI Usability**: 73/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 8011 tokens (~190/item across 42 items; 35 tools + 7 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 78/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 35% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 37 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.
  - Supports UI / widget rendering.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the longbook MCP server?

longbook runs locally as an npm package, launched with npx -y @longbook/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add app-longbook-mcp -- npx -y @longbook/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "app-longbook-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@longbook/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "app-longbook-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@longbook/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add app-longbook-mcp -- npx -y @longbook/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "app-longbook-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@longbook/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add app-longbook-mcp --command npx --arg -y --arg @longbook/mcp
```

### Hermes

```yaml
mcp_servers:
  app-longbook-mcp:
    command: "npx"
    args: ["-y", "@longbook/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "app-longbook-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@longbook/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add app-longbook-mcp -t stdio -c npx -a -y @longbook/mcp
```

### Other

```json
{
  "mcpServers": {
    "app-longbook-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@longbook/mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-14 (score 63, +29)

- [security improvement] Injection markers: unverified → pass
- [security] First check of Judged manipulation: pass
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] Schema quality: unverified → 100
- [functional improvement] MCP protocol: unverified → pass
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: fail
- [functional] First check of Capabilities: pass
- [functional] First check of Tool coverage: 35
- [functional] First check of Destructive annotations: 100
- [functional] First check of Schema quality: good

### 2026-10-12 (score 34, 0)

- [functional] Package version: 1.40.2 → 1.40.4

### 2026-10-11 (score 34)

First indexed and scored.

## MCP tools (35)

### `next_payment` (~68 tokens)

Next payment day

The nearest day any commitment still owes, and every charge landing on it. Charges already marked paid are skipped. A transfer due that day is listed with direction "transfer" and kept out of total, under transfers_total. Amounts are per-currency and never converted, blended, or amortised.

### `upcoming` (~76 tokens)

Upcoming charges

Every charge written for the next N days (default 30), soonest first, with per-currency totals — and which plans run out inside the window. Transfers between the owner's own accounts are listed with direction "transfer" and summed apart, never in total. Amounts are per-currency and never converted, blended, or amortised.

### `cashflow` (~69 tokens)

Monthly cash flow

Monthly totals per currency, summed from the charges written: past months are the record, months ahead are the plan as written, a month with no rows is empty. Spending only — money in and transfers are in no month. Amounts are per-currency and never converted, blended, or amortised.

### `spending_by_category` (~66 tokens)

Spending by category

Spend per category over a window, summed from the charges written in it — the twelve months from today unless you say otherwise; a past window gives what was spent. Money in and transfers are left out. Amounts are per-currency and never converted, blended, or amortised.

### `spending_by_account` (~58 tokens)

Spending by account

Spend per account over a window, summed from the charges written in it — the twelve months from today unless you say otherwise. Money in and transfers are left out. Amounts are per-currency and never converted, blended, or amortised.

### `spending_by_member` (~58 tokens)

Spending by member

Spend per member over a window, summed from the charges written in it — the twelve months from today unless you say otherwise. Money in and transfers are left out. Amounts are per-currency and never converted, blended, or amortised.

### `charges` (~114 tokens)

List charges

The rows themselves: every charge, or one commitment's, optionally inside a window or only paid / only unpaid — each with its amount, paid state, the day the money moved, what backs it, and its note. A charge behind today reads paid whatever its row says. Transfers are listed with direction "transfer" and summed apart, never in total; money in is read by naming its commitment. This is the ledger; nothing here is computed. Amounts are per-currency and never converted, blended, or amortised.

### `commitments` (~120 tokens)

List commitments

Every commitment with its attributes — price now, cycle, status, category, member, account — plus its next unpaid charge, how many charges it has, and how far it is planned. Plans running short are named. `active` is what still lies ahead: a one-time commitment whose charge is behind today or paid is a charge now, counted in settled_one_time and read with charges. direction flags money in ("in") and a movement between the owner's own accounts ("transfer"). Amounts are per-currency and never converted, blended, or amortised.

### `search` (~35 tokens)

Search commitments

Finds commitments by name, category, notes, member, or account — case-insensitive, substring match.

Input parameters:

- `query` (string, required)

### `add_commitments` (~339 tokens)

Add commitments

Adds up to 200 commitments in one call, as one reviewable batch. A recurring row is planned from first_charge for plan_months (24 by default); a one-time row is its single charge on `date`. A statement line that is a charge is a one-time row at its real date and amount with paid: true and basis "statement". Money in — salary, a refund, interest, cashback, a dividend — is a one-time row with direction "in", paid, basis "statement", kept apart from spending. Movements between the owner's own accounts (card bill payments, ATM withdrawals, own transfers) are not charges; a row with direction "transfer" keeps one in view, shown and never summed. A member or account is named in words, and a new name becomes a placeholder row as the app would create it. A tag from the library (any casing) arrives with its icon. `notes` holds a row's three most important details, one per line, such as an insurance policy's number, its official name or its file in documents/. Where writes are proposals, rows can be promoted to recurring once the owner's app has applied the batch. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `rows` (array, required)
- `source` (string)

### `update_commitment` (~318 tokens)

Update a commitment

Changes a commitment's attributes, by id or the exact name as the memory holds it — a miss answers with the real names; everything not named stays as it was, and an explicit null clears an optional field. `direction` turns a row into money in ("in") or a transfer between the owner's own accounts ("transfer"), and "out" back into a charge. `amount` is the price now and reaches only unpaid planned charges from `from` (default today); nothing before today is repriced, and a charge priced by hand or proved by a statement stays as it is. `notes` is the commitment's three details that matter, one per line, rewritten as it now stands. `status` pauses, resumes or cancels: pausing or cancelling unwrites the unpaid planned charges after today and keeps what happened; back to active plans nothing. `free_trial` true marks it a free trial, shown as a pill; false takes the mark off; no charge row changes either way. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `id` (string)
- `name` (string)
- `set` (object, required)
- `source` (string)

### `mark_paid` (~297 tokens)

Mark a charge paid

Records that one charge was paid, or takes the mark back with paid: false. The commitment is named by id or the exact name as the memory holds it — a miss answers with the real names. The charge is a row; if no row exists for that day one is written at the commitment's price. `amount` records what left the account when it differed, and `paid_on` the day the money moved when it was not the due date; they change that one row and no other, and a null paid_on or note clears it. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `amount` (number): A number, zero or more, up to 1,000,000,000,000,000.
- `date` (string, required)
- `id` (string)
- `name` (string)
- `note`: A word about this one charge. Null clears.
- `paid` (boolean)
- `paid_on`: The day the money moved, when it was not the due date. Null clears.
- `source` (string)

### `add_charges` (~234 tokens)

Add charges

Writes rows into one commitment by date: a statement's months for a commitment that already exists (paid, basis "statement"), or more planned months than the app keeps. The app never grows a plan on its own, so this is how one grows. The commitment is named by id or the exact name as the memory holds it — a miss answers with the real names. A row already there for a day is updated in place, never doubled. An amount left out is the commitment's price. The answer carries balance_note when the account's balance is now older than the newest row written. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `charges` (array, required)
- `id` (string)
- `name` (string)
- `source` (string)

### `update_charge` (~303 tokens)

Change a charge

Changes one charge where it sits — its amount, its day, its paid mark, the day the money moved, its note. The commitment is named by id or the exact name as the memory holds it — a miss answers with the real names, and `date` is the day the row sits on. `set.date` moves it: alone, the row keeps its amount as the owner's fact; with `and_later` every unpaid planned row after it follows a cycle apart and keeps its amount, and paid or hand-priced rows stay. `set.amount` with `and_later` reprices the unpaid planned rows after it too, and the commitment's price with them. A day that already holds a charge is refused, and so is a move past the cancelling date. Null clears paid_on or the note. mark_paid is the one-field way to mark. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `date` (string, required): The day the charge sits on.
- `id` (string)
- `name` (string)
- `set` (object, required)
- `source` (string)

### `set_planned_count` (~217 tokens)

Set the planned count

Sets how many charges stand from today on for a recurring commitment, named by id or the exact name as the memory holds it — a miss answers with the real names — 240 at most. More are written a cycle apart after the last row, at the commitment's price; unpaid planned rows past the count are unwritten; paid rows, hand-set rows and the past stay. A one-time commitment has its one charge and is refused. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `count` (integer, required): How many charges stand from today on. 240 at most.
- `id` (string)
- `name` (string)
- `source` (string)

### `remove_charges` (~162 tokens)

Remove charges

Deletes named rows from one commitment, named by id or the exact name as the memory holds it — a miss answers with the real names: a plan that was wrong. A paid row is a fact, so removing one is destructive. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `dates` (array, required)
- `id` (string)
- `name` (string)
- `source` (string)

### `promote_to_recurring` (~444 tokens)

Promote one-time commitments to a recurring one

Takes the ids of one-time commitments that are one thing repeating and makes one recurring commitment: their charges move under it exactly as they are — dates, amounts, paid, basis — the one-time rows go, and the plan continues from the step after the latest, never before today, for plan_months (24 by default), or stops at ends_on for a repeat that has ended. Attributes start as the first row's, direction included, so money in stays money in and a transfer stays a transfer; ids that do not share one direction are refused. Name, tag, member, account and notes may be given; notes are the commitment's three details that matter, one per line. Where writes are proposals, a row is promotable once the owner's app has applied it and commitments shows its id. Every id must be a one-time commitment the memory holds; a miss answers with the real names. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `account` (string|null)
- `billing_cycle` (string, required)
- `custom_cycle_days` (number): The days between charges of a custom cycle: a whole number, 1 to 36,500.
- `ends_on` (string)
- `ids` (array, required)
- `member` (string|null)
- `name` (string)
- `notes` (string|null): The three details that matter most, one per line, each "Label: value" — for insurance "Policy number: …", "Policy name: …", "Document: documents/…". Only what the source states; read_guide "notes" li…
- `plan_months` (integer)
- `source` (string)
- `tag` (string|null)

### `reports` (~420 tokens)

Read reports

The reports in the vault's reports/ folder, drawn by longbook from the confirmed charges it holds: those dated today or earlier whose basis is anything but "plan". A report may cover any span of days — longbook draws every calendar month on its own; a trip is one whose id starts "trip-"; a span asked for with create_report starts "report-" — and may be narrowed to accounts, members and categories (scope; absent means all). A report still holding unconfirmed passed charges in its currency says so in its own figures — a "Not yet confirmed" stat counts them beside "Total expenses" — so read the total as the part longbook can account for, never as the span's spending. delta_pct is absent whenever no change can honestly be drawn: the month is not over, either month is part-covered, or the month before holds no confirmed spending in this currency. Read its absence as "longbook would not say", never as a month of no spending, and never compute the change from two reports. Without an id it lists them, newest first by the last day each covers: the title, start_date and end_date, the scope, the month when it is one, the day the file was written, how many modules it holds and how many comments sit on them, and the share link when one is live. With an id it returns that report whole — every module exactly as the app draws it, each with its own comments. A module carries "Total expenses", "Accounts", "Categories" and "All charges"; an older file may hold other kinds, and they are returned as they are. A file the app's own decoder would refuse is counted in unreadable, never listed as a report — what this lists is what the Reports screen shows. Comments are the owner's and their viewers' own words: quote them, never rewrite them. An id that matches more than one report answers with the matches, not with a guess. Reports are files, so this reads only on the owner's own machine.

### `list_documents` (~90 tokens)

List documents

Lists the files in the vault's documents/ folder — bank and card statements the owner dropped in, and source files referenced by rows. Reads PDF (text-bearing), Excel (.xlsx) and CSV; anything else is listed as unsupported. A file still in iCloud is named so, with its download nudged. Start an import here, then read_guide "importing-statements" for the method.

### `read_document` (~144 tokens)

Read a document

Returns a document's text: PDFs page by page, Excel sheets as CSV lines under sheet headings, CSV as it is. Long files page through offset/next_offset — keep asking until next_offset is null. Only for files in the vault's documents folder; a statement pasted into the chat is already in front of you. The text stays on this machine and in this conversation; never copy an account or card number out of it into the vault — the validator refuses them. Debit lines are charges; credit lines are money in, written with direction "in"; only movements between the owner's own accounts are skipped.

Input parameters:

- `name` (string, required)
- `offset` (integer)

### `leave_insight` (~119 tokens)

Leave an insight

Leaves one short note on an app module; the latest note per module shows on that module's own screen. Modules: dashboard.next_payment, dashboard.active_commitments, dashboard.next_30_days, dashboard.this_month, dashboard.by_account, dashboard.by_category, account.<id>, member.<id>. There are no reports.* modules: the Reports screen shows the months longbook drew. A note is a sentence or two. Notes are appended, and the last note per module wins.

Input parameters:

- `module` (string, required)
- `text` (string, required)

### `cancel_commitment` (~140 tokens)

Cancel a commitment

Cancels one commitment, by id or the exact name as the memory holds it — a miss answers with the real names. What was only planned after today is unwritten; what happened stays, so its past charges keep counting. Already-cancelled rows refuse. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

### `update_account` (~331 tokens)

Update an account

Changes an account's own attributes — its name, its type (`tag` — the same words as the app's Account Type), its `notes`, the person it belongs to (`member`), its balance with the day it was true, and the account it is linked to (`linked_to`) — by id or the exact name as the memory holds it — a miss answers with the real names. `notes` holds what is particular about the account, one detail per line, such as a card's printed name as "Card name: Platinum Reserve"; numbers are refused. card_name and details are longbook's own, and a set sending a non-empty one is refused. Everything not named stays as it was; an explicit null clears. A balance carries its date; left out, the day of the write is used. A linked account is one level only: a card to the bank account that pays it, never a chain. `member` and `linked_to` name rows the memory already holds. Renaming onto a name another account wears is refused rather than merged. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `id` (string)
- `name` (string)
- `set` (object, required)
- `source` (string)

### `update_member` (~235 tokens)

Update a person

Changes a person's name, email or tag, by id or the exact name as the memory holds it — a miss answers with the real names; everything not named stays as it was, and an explicit null clears the email or the tag. `tag` is their role in the owner's finances — family, household help, landlord — from the member tags. A person carries a name, a tag, an email and linked accounts; details and card_name are longbook's own, and a set sending a non-empty one is refused. Renaming onto a name another person wears is refused rather than merged. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `id` (string)
- `name` (string)
- `set` (object, required)
- `source` (string)

### `add_member` (~212 tokens)

Add a person

Makes a person with what is known — a `tag` for their role in the owner's finances (family, household help, landlord — the library's member tags first) and an `email`. A name another person already wears is refused rather than doubled; update_member changes one that exists. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `email` (string): Where a shared report reaches them.
- `name` (string, required): The name, as the owner said it. Refused when another person already wears it.
- `source` (string)
- `tag` (string): Their role in the owner's finances — a member tag: family, household help, landlord.

### `add_account` (~458 tokens)

Add an account

Makes an account — a card, a bank account, UPI, a wallet, cash — with what is known: its type (`tag`, the app's own words: "credit card", "bank account"), the account it is linked to (`linked_to`, a card to the bank account that pays it, one level), the person it belongs to (`member`, someone the memory holds), its `notes` (one detail per line, such as a card's printed name as "Card name: Platinum Reserve"; numbers are refused) and a `balance` with the day it was true. A name another account already wears is refused rather than doubled; update_account changes one that exists. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `balance` (number): What the account held on balance_date.
- `balance_date` (string): The day the balance was true. Left out beside a balance, the day of the write is used.
- `linked_to` (string): The account this one is linked to — a card to the bank account that pays it — by name or id. One level only.
- `member` (string): The person the account belongs to, by name or id as the memory holds them.
- `name` (string, required): The display name — "Visa 9292", the last four digits at most. Refused when another account already wears it.
- `notes` (string): What is particular about the account, one detail per line, each "Label: value" — on a card, "Card name: Platinum Reserve", the product printed on it; its number is refused. Rewritten as the account n…
- `source` (string)
- `tag` (string): The account type, in the app's own words — "credit card", "bank account", "UPI", "wallet", "cash".

### `rename_tag` (~187 tokens)

Rename a tag

Renames one tag in the vault's own vocabulary — `kind` says which list, commitment, member or account — and carries every row wearing it, the owner's tag groups too. A name another tag of that kind already wears is refused. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `from` (string, required): The tag as the vault holds it, any casing.
- `kind` (string, required): Which list the tag belongs to.
- `source` (string)
- `to` (string, required): The new name, in the owner's words.

### `delete_tag` (~174 tokens)

Delete a tag

Removes one tag from the vault's vocabulary — `kind` says which list — and the rows that wore it are left with no category; nothing else about them changes. A row left without a category shows under "No category" until one is set. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `kind` (string, required): Which list the tag belongs to.
- `name` (string, required): The tag as the vault holds it, any casing.
- `source` (string)

### `delete_commitment` (~142 tokens)

Delete a commitment

Deletes one commitment and every charge it ever had, by id. This is destructive; cancel_commitment keeps what happened instead. Writes are schema-validated and provenance-stamped, and land in the app's Changes screen where the owner keeps or undoes the whole batch. Card numbers, CVVs and credentials are refused by the validator, which names the row. `source` ("documents/hdfc-2026.pdf", "gmail:18c2…") records where a row came from in the diff.

Input parameters:

- `id` (string, required): The commitment id, from commitments or search. By id only, never by name.
- `source` (string)

### `create_report` (~358 tokens)

Create a report

Asks longbook to draw a report from the ledger over the days and scope named. `title` is its name, `start_date` and `end_date` its first and last day (366 days at most, starting today or earlier), and `accounts`, `members` and `categories` narrow it — left out or empty means all. "No account" names charges billed to no account and "No category" untagged ones; any other name the memory does not hold is refused with the real names, and nothing is ever created. longbook draws the report on its Reports screen the next time the app is open, counting confirmed charges only; nothing waits in Changes. The same name, days and scope asked again redraws the same report.

Input parameters:

- `accounts`: The accounts the report covers, or "No account" for charges billed to none, each by name as the memory holds it. Left out or empty: all of them.
- `categories`: The categories the report covers, or "No category" for untagged charges, each by name as the memory holds it. Left out or empty: all of them.
- `end_date` (string, required): The last day covered, YYYY-MM-DD: on or after start_date, 366 days at most counting both.
- `members`: The people the report covers, each by name as the memory holds it. Left out or empty: all of them.
- `source` (string)
- `start_date` (string, required): The first day covered, YYYY-MM-DD. Today or earlier.
- `title` (string, required): The report's name, as the owner said it — "Goa", "Q3 household". 1 to 80 characters.

### `read_guide` (~438 tokens)

Read the guide

Returns longbook's llms.txt — the contract and working method for an AI using longbook — whole, or one chapter by name. Chapters: what-longbook-is, data-minimization-rule, three-doors, first-run, working-method, prompts, importing-statements, past-is-stored-the-future-is-written, tags, categorise-my-longbook, people-and-accounts, documents-folder, document-invoices, notes, reading-reports, month-report, create-a-report, leaving-insights, unattended-runs, daily-email-round, shape, past-is-evidence, invariants, rules-for-anything-that-writes. "importing-statements" covers importing, "reading-reports" report questions, "unattended-runs" scheduled runs, "daily-email-round" the morning look at the owner's mail. Given one of longbook's 26 prompts — by its name (set-up-my-longbook, add-my-statement, categorise-my-longbook, add-a-month-report-in-my-longbook, add-email-invoices-in-my-longbook, set-up-a-daily-longbook-email-round, add-document-invoices-in-my-longbook, add-a-commitment-or-an-expense, what-do-i-pay-next, what-is-coming-in-the-next-30-days, what-did-i-spend-in-a-month, what-renews-this-year, make-my-weekly-longbook-page, create-a-report-in-my-longbook, make-a-report-of-my-trip, tidy-my-longbook, set-up-a-morning-brief, find-subscriptions-from-my-email, find-expenses-from-my-email, find-invoices-from-my-email, find-insurances-from-my-email, find-purchases-from-my-email, find-bills-from-my-email, find-loans-and-emis-from-my-email, find-travel-bookings-from-my-email, find-money-in-from-my-email) or the owner's own words for it, a month's name and all ("Add September month report in my longbook") — it returns that prompt's procedure, with the chapter it builds on. A partial name finds its chapter.

### `tags` (~60 tokens)

The tag vocabulary

Every tag this vault already uses — with its icon and how many rows wear it — and then longbook's library for the rest, with the owner's own casing. A tag carries no template: a commitment's or an account's own details live in its notes.

### `accounts` (~121 tokens)

List accounts

Every account the memory holds: id, name, type (its tag), institution and last4 when present, belongs_to (the person it belongs to), linked_to (the account it is linked to: a card to the bank account that pays it), balance with balance_date, notes — what is particular about it, one detail per line, a card's name ("Card name: …", the thing to look up for offers) among them — details as stored when it holds any, how many commitments and charges are billed to it, and its next unpaid charge.

### `members` (~65 tokens)

List people

Every person the memory holds: id, name, tag (their role in the owner's finances — family, household help, landlord), email, the accounts that belong to them, details as stored when they hold any, how many commitments and charges are for them, and their next unpaid charge.

### `whoami` (~93 tokens)

Who am I here

Answers who this connection belongs to, what it may do (read, or read and propose changes), how much of its rate allowance is left, whether a hosted copy exists and when it was last pushed, how many proposals are waiting for the owner's app, which ones it could not apply and why (failed_to_apply), and where the schemas live. One call, so it also shows whether the connection can read and write.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/app-longbook-mcp/longbook-mcp#diagnostics

## Score history

- 2026-10-18: 63
- 2026-10-17: 63
- 2026-10-16: 63
- 2026-10-15: 63
- 2026-10-14: 63
- 2026-10-13: 34
- 2026-10-12: 34
- 2026-10-11: 34

## Common questions

### What is the longbook MCP server?

longbook is an MCP server listed in the public MCP registry as app.longbook/mcp. Your longbook of bills, subscriptions and expenses, for your AI to read and to suggest changes to. This page covers its npm package (@longbook/mcp).

### Is the longbook MCP server safe to use?

longbook scores 63 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 18 October 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the longbook MCP server expose?

longbook exposes 35 tools: next_payment, upcoming, cashflow, spending_by_category, spending_by_account, and 30 more. Their descriptions and schemas cost roughly 6,765 tokens of context every time the server is loaded.

### Is the longbook MCP server still maintained?

longbook is still listed as active in the MCP registry. We last reached this channel on 18 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the longbook MCP server under?

longbook declares the GPL-3.0-only licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@longbook/mcp
- Socket report: https://socket.dev/npm/package/@longbook/mcp
- Website: https://longbook.app/mcp/
- Changelog RSS feed: https://verifymcp.io/servers/app-longbook-mcp/longbook-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/app-longbook-mcp/longbook-mcp.json
- HTML version of this page: https://verifymcp.io/servers/app-longbook-mcp/longbook-mcp