Skip to main content
Glama
ignaciohermosillacornejo

Copilot Money MCP

by ignaciohermosillacornejo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_accounts

Read-only

Fetches all account balances plus net worth, asset, and liability totals, optionally filtered by account type.

Instructions

Get all accounts with balances, plus summary fields: total_balance (net worth = assets minus liabilities), total_assets, and total_liabilities. Optionally filter by account type (checking, savings, credit, investment). Checks both account_type and subtype fields for better filtering (e.g., finds checking accounts even when account_type is 'depository'). By default, hidden accounts are excluded. name is your Copilot nickname when set, else the provider label — it is user-editable, so key on account_id, never on name. Default rows are terse: account_id, name, account_type, subtype, current_balance, institution_name, iso_currency_code, item_id, plus user_hidden / user_deleted when set (the flags include_hidden controls). That drops the other ~35 document fields. PARTIAL list of what goes, not exhaustive: the embedded holdings array (get_holdings covers it), institution logo images plus their logo_content_type (base64-encoded, several KB each — this PAIR is where the removed include_logos flag went, and the flag gated both, so request them together), mask (the last-4 digits humans identify an account by), available_balance, limit, institution_id, creation_timestamp (when the account was created in Copilot, YYYY-MM-DD — written only on newer rows, so absent means unknown, not old), the denormalized official_name / original_* name dupes, and user_id. Any document field is requestable by name: fields: ["default", "mask", "available_balance"], or "all" / "*" for full rows. include_logos was removed in v3.0.0 — passing it now raises an error naming this migration.

Input Schema

NameRequiredDescriptionDefault
fieldsNoReturn only these fields per account row (e.g. ["account_id", "name", "current_balance"] for get_accounts, or ["id", "name", "balance"] for get_accounts_live — field names differ between the two modes). "default" expands to a terse baseline covering identity, name, type, balance, institution, and item — see each tool's own description for its exact field list and what "default" excludes. "all" or "*" returns the full row. Unknown names are omitted and reported via _field_warning.
account_typeNoFilter by account type (checking, savings, credit, loan, investment, depository). Note: summary totals (total_assets, total_liabilities, total_balance) reflect only the filtered subset.
include_hiddenNoInclude hidden accounts (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "Return only these fields per account row (e.g. [\"account_id\", \"name\", \"current_balance\"] for get_accounts, or [\"id\", \"name\", \"balance\"] for get_accounts_live — field names differ between the two modes). \"default\" expands to a terse baseline covering identity, name, type, balance, institution, and item — see each tool's own description for its exact field list and what \"default\" excludes. \"all\" or \"*\" returns the full row. Unknown names are omitted and reported via _field_warning.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv2.0.1

TDQS

A4.6/5.0
Behavior5/5

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

With readOnlyHint=true already covering safety, the description adds substantial behavioral context: default rows omit roughly 35 fields, hidden accounts are excluded unless include_hidden is set, name is user-editable and must not be used as a key, and include_logos was removed in v3.0.0 and now raises an error.

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 core purpose, filtering behavior, and default projection are front-loaded, and most detail is relevant. The long parenthetical inventory of excluded fields is informative but dense, making the description longer than strictly necessary.

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?

No output schema exists, but the description specifies the default return fields, the summary fields, the kinds of fields omitted by default, and how to request any document field by name. Combined with readOnlyHint and full schema coverage, this is enough for an agent to call the tool correctly.

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 the baseline is 3, but the description meaningfully expands parameter semantics. It explains how fields supports 'default', 'all', '*', and explicit names; how account_type filtering checks both account_type and subtype; and how include_hidden controls the user_hidden/user_deleted flags.

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: 'Get all accounts with balances, plus summary fields.' It also clarifies scope and identity versus siblings by noting that embedded holdings are covered by get_holdings and by explaining the default field projection.

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?

Usage context is clear: optional filtering by account type, hidden accounts excluded by default, and fields projection via 'default', 'all', or explicit names. It also routes the agent away for holdings data by naming get_holdings, though it does not systematically compare against all relevant siblings such as get_balance_history.

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