Which integrations are available for this server?

Provides integration with QuickBooks Online, enabling AI agents to access financial data, generate reports, create invoices and expenses, and manage bookkeeping tasks through the QuickBooks platform.

How do I use penni-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., "@penni-mcp what's my profit and loss for last quarter?" 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.

de en es ja ko ru zh

penni-mcp

by CWhittemore1010

Overview Schema Related Servers Score Discussions

JavaScript

Remote

penni-mcp

Penni — AI bookkeeper for small businesses. Connect your QuickBooks and manage your books through Claude Desktop or Cursor.

Quick Start

npx penni-mcp

On first run, you'll be prompted for your API key. Get yours at app.penni.so/dashboard/mcp.

Related MCP server: quickbooks-mcp-server

Claude Desktop Setup

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "penni": {
      "command": "npx",
      "args": ["penni-mcp"]
    }
  }
}

Config file location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Then restart Claude Desktop and ask: "What's my bank balance?"

Cursor Setup

Settings → MCP → Add Server:

Name: penni
Command: npx penni-mcp

What You Can Do

Free (connect QBO and go)

"What's my bank balance?" — real-time balances from QuickBooks
"Show me my P&L for this month" — Profit & Loss report
"Who owes me money?" — open and overdue invoices

Paid ($149/mo at penni.so)

"Create a $500 expense for AWS under Software" — post expenses to QBO
"Invoice Acme Corp $2,000 for consulting, due May 1st" — create and send invoices
"Ask Penni: what's my biggest expense category?" — AI-powered bookkeeping Q&A

How It Works

Penni connects to your QuickBooks Online account through a secure API. Your data lives in YOUR QuickBooks — not on our servers. If you stop using Penni, your books are exactly where they've always been.

API Key

You can also set your API key via environment variable:

PENNI_API_KEY=your_key_here npx penni-mcp

Or pass it as a flag:

npx penni-mcp --key your_key_here

The key is saved to ~/.penni/config.json after first run.

License

MIT

Available Tools

6 tools

penni_askA

Ask Penni a bookkeeping question about your QuickBooks data

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	Your question about your finances or books

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or rate limits, leaving the agent uninformed about tool behavior.

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, clear sentence with no unnecessary words, efficiently conveying the tool's purpose.

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 Q&A tool with one well-documented parameter, the description is sufficient; however, it could be improved by hinting at the response format or providing an example question.

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?

Schema coverage is 100% and the description adds no extra meaning beyond the schema's parameter description, meeting the baseline but not exceeding it.

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 the tool's action ('Ask') and resource ('Penni a bookkeeping question about your QuickBooks data'), distinguishing it from sibling tools that perform specific actions like create or get.

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

Usage Guidelines3/5

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

The description implies usage for bookkeeping questions but does not explicitly state when to use this tool versus siblings, nor does it provide exclusions or alternatives.

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

penni_create_expenseB

Create an expense entry in QuickBooks (requires Penni subscription)

ParametersJSON Schema

Name	Required	Description
`vendor`	Yes	Vendor name
`amount`	Yes	Amount in dollars
`category`	Yes	Expense category (e.g. Meals & Entertainment, Software & Subscriptions)
`date`	No	Date YYYY-MM-DD (defaults to today)
`memo`	No	Memo or description

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only mentions the action and a requirement, lacking details on idempotency, error behavior, side effects, or validation. A create operation needs more behavioral context.

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

Conciseness4/5

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

The description is a single concise sentence, front-loading the key information. It could be slightly more structured, but it is efficient and to the point.

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

Completeness2/5

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

For a tool with 5 parameters and no annotations, the description is too brief. It lacks information on return values, error scenarios, restrictions on categories, or duplicate handling, making it incomplete.

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?

Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it does not elaborate on any parameters.

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 the action (create), resource (expense entry in QuickBooks), and a key prerequisite (Penni subscription). It distinguishes itself from sibling tools like penni_create_invoice by specifying the target resource.

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

Usage Guidelines3/5

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

The description implies usage for creating expenses but does not explicitly state when to use this tool versus alternatives like penni_create_invoice. No guidance on when not to use or prerequisites beyond the subscription.

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

penni_create_invoiceB

Create and optionally send an invoice through QuickBooks (requires Penni subscription)

ParametersJSON Schema

Name	Required	Description
`customer_name`	Yes	Customer name
`line_items`	Yes	Invoice line items
`due_date`	Yes	Due date YYYY-MM-DD
`send`	No	Send the invoice to customer via email (default: false)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral traits. It only notes that sending is optional and requires a subscription, but does not disclose side effects (e.g., what happens in QuickBooks), permissions, rate limits, or return values. This is insufficient for a mutation tool.

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

Conciseness4/5

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

The description is a single 12-word sentence that efficiently conveys the core purpose and a key prerequisite. It is front-loaded with the action, but could benefit from slightly more structure without becoming verbose.

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

Completeness2/5

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

Given 4 parameters (one optional boolean) and no output schema, the description leaves gaps: it does not explain what the tool returns after creation, how the 'send' option works in detail, or any error conditions. The agent lacks sufficient context to use it reliably.

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?

All 4 parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description adds no extra meaning or context beyond what the schema already provides, such as format hints or relationships between parameters.

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 the action ('Create and optionally send an invoice') and the resource ('through QuickBooks'). It distinguishes itself from sibling tools like penni_get_invoices (viewing) and penni_create_expense (expenses) by specifying the exact operation and target system.

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

Usage Guidelines3/5

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

The description mentions a prerequisite ('requires Penni subscription') but provides no explicit guidance on when to use this tool versus alternatives. It implies usage when an invoice needs to be created, but lacks exclusions or references to sibling tools for different tasks.

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

penni_get_balanceB

Get current bank account balances from QuickBooks

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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 only states the action (get balances) but does not mention side effects, authentication requirements, rate limits, or whether it is read-only. As a simple retrieval tool, the lack of additional transparency is a gap.

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 concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easily scannable.

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 tool has no parameters, no output schema, and no annotations, the description is complete enough to understand the tool's purpose. It might benefit from noting what 'current' means or that it returns multiple account balances, but it is adequate for a simple retrieval tool.

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 input schema has zero parameters, so the description does not need to add parameter-level details. The schema description coverage is 100% trivially, and the description adequately implies the lack of parameters.

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

Purpose4/5

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

The description clearly states it gets current bank account balances from QuickBooks, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like penni_get_invoices or penni_get_pnl, so the distinction is implicit.

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

Usage Guidelines2/5

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, nor does it mention any prerequisites or exclusions. The usage context is purely implied by the tool's name and description.

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

penni_get_invoicesA

Get open and overdue invoices from QuickBooks

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

The description accurately identifies the operation as a read ('Get') with a specific filter ('open and overdue'). No annotations are provided, but the description itself is transparent about the behavior. It does not disclose any potential side effects, but none are expected for a read operation.

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 sentence that conveys the essential purpose without any extraneous words. It is front-loaded and efficient.

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 parameters and no output schema, the description is adequate. It explains what the tool does and what it returns. However, it could mention the return format or data structure to be fully complete.

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 input schema has zero parameters, so the description does not need to add parameter meaning. The baseline for no parameters is 4, and the description sufficiently implies the tool returns all open and overdue invoices without filters.

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 it retrieves 'open and overdue invoices' from QuickBooks, specifying a specific verb and resource. It distinguishes from siblings like 'penni_create_invoice' and 'penni_get_balance' by focusing on a specific subset of invoices.

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

Usage Guidelines2/5

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. For example, it does not explain when to use this over 'penni_get_balance' or other tools, nor does it mention any prerequisites or context.

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

penni_get_pnlB

Get Profit & Loss report from QuickBooks

ParametersJSON Schema

Name	Required	Description	Default
`start_date`	No	Start date YYYY-MM-DD
`end_date`	No	End date YYYY-MM-DD

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description must cover behavior. It says 'Get' implying read-only, but no confirmation of idempotency, side effects, or constraints like date range limits or permissions. Minimal disclosure.

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

Conciseness4/5

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

Extremely short single sentence with no fluff. Every word earns its place, but could benefit from slight expansion. Still effective for a simple tool.

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

Completeness2/5

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 simple but not trivial parameters, the description omits what the report contains, period behavior, and error handling. Incomplete for confident use.

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?

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning to the start_date and end_date parameters beyond what the schema already provides.

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 the verb 'Get', the resource 'Profit & Loss report', and the source 'QuickBooks'. It uniquely identifies this tool among siblings like get_balance or get_invoices.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided. The description lacks context for appropriate usage.

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.

6 tool updatesv1.0.0May 1, 2026
- First observedpenni_ask
- First observedpenni_create_expense
- First observedpenni_create_invoice
- First observedpenni_get_balance
- First observedpenni_get_invoices
- First observedpenni_get_pnl

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: asking questions, creating expenses, creating invoices, getting bank balances, listing invoices, and getting profit & loss reports. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'penni_verb_noun' pattern using snake_case (e.g., penni_ask, penni_create_expense, penni_get_balance). Perfectly predictable.

Tool Count5/5

With 6 tools covering core bookkeeping operations (read, create, list, report), the count feels well-scoped for a specialized MCP server without being too few or too many.

Completeness4/5

The tool surface covers essential bookkeeping tasks (query, create expense/invoice, get balances, list invoices, P&L). Missing update/delete operations for expenses and invoices, but the core workflows are covered.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

Caribooks (QuickBooks Online)OAuth
com.caribooks
QuickBooks Online in Claude and ChatGPT: 221 tools, full ledger, multi-company, Canada + US, FR/EN.
Finance Payments & Billing ERP Systems
1
HelloBooks AI Agents MCP Server A
io.github.HelloBooksAIAgents
AI agents for bookkeeping, reconciliation, and financial close for SMBs.
Finance Autonomous Agents
2921
DeepLedger — AI Accountant for QuickBooksOAuth
ai.deepledger
AI Accountant for Quickbooks- recording, reconcile, month-end close
Finance App Automation
2
AgenticBIOAuth
io.github.AgenticBIHQ
Connect Claude, Cursor, or ChatGPT to your business data. Ask questions, get answers.
Search RAG Systems Databases
2

Related MCP Servers

QuickBooks Online MCP Server
Finance ERP Systems
hakeemrabiuDFW
A
license
A
quality
D
maintenance
Enables AI assistants to query and manage QuickBooks Online data through natural language, including customers, invoices, bills, vendors, accounts, and financial reports.
Updated 8 months ago (2026-01-11 19:24 UTC)
7
MIT
quickbooks-mcp-server
Finance ERP Systems
NyxToolsDev
A
license
Not graded
quality
D
maintenance
Connect Claude Desktop and Claude Code to QuickBooks Online for natural-language accounting. Ask questions about invoices, expenses, reports, and more using plain English.
Updated 5 months ago (2026-04-06 20:59 UTC)
MIT
LedgerLink MCP
Finance Payments & Billing
bpmj-martin
A
license
Not graded
quality
D
maintenance
Connects AI assistants to QuickBooks Online, enabling management of invoices, customers, expenses, and reports through natural language.
Updated 7 months ago (2026-02-17 20:45 UTC)
MIT
QuickBooks MCP
Finance ERP Systems
laf-rge
A
license
A
quality
A
maintenance
Enables financial professionals to interact with QuickBooks Online using natural language for reports, journal entries, bills, expenses, and more.
Updated 14 days ago (2026-08-24 21:53 UTC)
36
893
11
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/CWhittemore1010/penni-mcp'

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

penni-mcp

Quick Start

Claude Desktop Setup

Cursor Setup

What You Can Do

Free (connect QBO and go)

Paid ($149/mo at penni.so)

How It Works

API Key

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API