Skip to main content
Glama
gabrielbssantos

Pluggy Finance MCP

get_expenses_by_category

Read-only

Retrieve expense totals grouped by category and original currency for a specific month or date range, following monthly expense rules.

Instructions

Gastos por categoria original e moeda; mesmas regras dos gastos mensais.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
monthNo
date_toNo
date_fromNo
account_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataNo
metaYes
toolYes
errorNo
warningsYes
paginationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying grouping by original category and currency and referencing monthly expense rules, but it does not disclose output formatting, pagination, or currency conversion behavior beyond that.

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 sentence with no filler, and the core output dimension (original category and currency) is stated first. It is efficient but arguably too terse, sacrificing helpful detail for brevity.

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 four optional parameters, 0% parameter documentation, and no explicit usage guidance, the description is underspecified. The output schema exists, but it does not compensate for missing parameter semantics or the lack of a clear pointer to get_monthly_expenses as the source of the shared rules.

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%, and the description does not explain month, date_from, date_to, or account_ids. The 'same rules as monthly expenses' reference may indirectly hint at parameter behavior, but it does not provide concrete semantics for any of the four 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 states the resource as expenses grouped by original category and currency, and references 'mesmas regras dos gastos mensais' to anchor its behavior to the sibling monthly expenses tool. It is clear enough to identify the tool's output, though it lacks an explicit verb and does not name the sibling tool directly.

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?

There is no guidance on when to use this tool instead of get_monthly_expenses or any other sibling. The phrase 'mesmas regras dos gastos mensais' implies shared behavior but does not explain selection criteria, exclusions, or alternatives.

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