Skip to main content
Glama
Sign In
drebedengi-mcp

drebedengi-mcp

by hawk911
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Список операций

get_transactions
Read-only

Retrieve expenses, incomes, transfers, and currency exchanges for a period using filters; returns matching transactions and expense/income totals by currency.

Instructions

Операции (расходы, доходы, переводы, обмен валют) за период с фильтрами. Суммы: расход < 0, доход > 0. Возвращает также суммы расходов/доходов по валютам по всем найденным операциям.

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": "get_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoТолько операции с этими тегами
typeNoТип операций (по умолчанию all)
limitNoСколько операций вернуть (по умолчанию 100)
periodNoПериод: today, this_month (по умолчанию), last_month, this_quarter, this_year, last_year, all_time, last_20. Игнорируется, если заданы date_from/date_to.
searchNoПоиск подстроки в комментарии/категории/счёте
date_toNoКонец периода YYYY-MM-DD (включительно)
accountsNoТолько эти счета (id или названия)
date_fromNoНачало периода YYYY-MM-DD
categoriesNoТолько эти категории расходов / источники доходов (id или названия)
max_amountNoМаксимальная сумма по модулю
min_amountNoМинимальная сумма по модулю

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

With readOnlyHint=true already covering safety, the description still adds genuinely useful behavior: the sign convention (expense < 0, income > 0) and the fact that per-currency expense/income totals are computed across ALL matching operations, not just the returned page. Those details materially affect how an agent interprets results. It stops short of 5 because it says nothing about ordering or how the limit interacts with the returned aggregates.

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?

Three compact sentences, front-loaded with purpose, then the sign convention, then the aggregate return. Every sentence carries distinct, non-redundant information and nothing repeats the schema.

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

Completeness3/5

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

There is no output schema, and the tool has 11 parameters and returns both a transaction list and per-currency totals. The description explains the aggregate return and the sign convention, which is the hardest part, but it says nothing about the shape of individual transaction records or result ordering. For a no-output-schema read tool of this complexity, more return detail is expected.

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 every one of the 11 parameters is already documented, including defaults, enums, and the note that period is ignored when date_from/date_to are set. The description adds no syntax, format, or interaction detail beyond that. Baseline 3 is correct when the schema carries the parameter burden.

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 names a specific resource (operations) and enumerates the transaction kinds it covers (expenses, incomes, transfers, currency exchange), plus the period/filter scoping. An agent can distinguish this read tool from get_report, get_balance, and the add_*/update_* siblings. It does not explicitly name a sibling, so it stops short of a 5.

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 only implied: the phrase 'за период с фильтрами' signals this is the tool for pulling a filtered transaction list. There is no explicit when-to-use vs when-not guidance, no mention of get_report or get_balance as alternatives, and no statement of prerequisites. Adequate but leaves routing to inference.

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