Skip to main content
Glama
Sign In
Quicken Mac MCP

Quicken Mac MCP

by dweekly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_portfolio

Retrieves current investment holdings across brokerage and retirement accounts, with shares, cost basis, market value, and gain/loss from stored Quicken quotes.

Instructions

List current investment holdings across all brokerage/retirement accounts. Shows shares, cost basis, and enriches with stored Quicken quotes to compute market value and gain/loss. Positions with a negative share count are included: a short position, or shares removed with no recorded purchase. Includes the security's currency when the Quicken file records one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_portfolio"
  }
}

Input Schema

NameRequiredDescriptionDefault
account_namesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description does real work: it explains that values are computed from stored Quicken quotes (implying quote staleness is possible), that market value and gain/loss are derived, and that negative share counts are deliberately included for shorts or purchases without a recorded buy. That is substantive behavioral context an agent could not get from the schema.

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?

Four short sentences, each carrying distinct information (scope, returned fields, negative-share edge case, currency), with the main purpose front-loaded. 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?

With no output schema and no annotations, the description covers what the tool returns and the notable edge cases (negative positions, currency) well, and it doesn't need to explain return values. The remaining gap is the undocumented account_names parameter and the absence of any explicit guidance about alternatives.

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

Parameters2/5

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

Schema description coverage is 0% for the single parameter account_names, and the description says holdings are listed 'across all brokerage/retirement accounts', which reads as no filtering at all. It neither documents the filter nor clarifies whether the parameter restricts or merely labels the accounts returned.

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?

States a specific verb and resource ('List current investment holdings') and immediately scopes it to brokerage/retirement accounts. It also distinguishes itself from the sibling tools (list_accounts, query_transactions) by describing holdings-level output: shares, cost basis, market value, gain/loss.

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?

Usage is implied rather than stated: an agent can infer this is the tool to call for position-level data, but there is no explicit when-to-use/when-not guidance versus list_accounts or query_transactions. The description also never says the scope can be narrowed, so the intended usage of the one filter parameter is left implicit.

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

Deploy Server

Other Tools