OpenMonetis MCP

Exportar transações

export_transactions

Read-onlyIdempotent

Export filtered transactions to CSV or XLSX, save the file to the host export directory, and return the absolute path plus row count.

Instructions

Exporta as transações filtradas em CSV ou XLSX e grava o arquivo no diretório de exportação do host (padrão: ~/Downloads/openmonetis-mcp). Retorna o caminho absoluto e o número de linhas.

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

Input Schema

Name	Required	Default
`q`	No
`type`	No
`format`	No	csv
`period`	No
`tagIds`	No
`cardIds`	No
`dateEnd`	No
`condition`	No
`dateStart`	No
`maxAmount`	No
`minAmount`	No
`personIds`	No
`accountIds`	No
`settlement`	No
`categoryIds`	No
`paymentMethod`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Nov 13, 2026

TDQS

B3.3/5.0

Behavior4/5

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

With annotations supplied, the description still adds real behavioral context: it discloses the host-side file write, the default directory (~/Downloads/openmonetis-mcp), and the return payload (absolute path plus row count), which is valuable because no output schema exists. Some tension remains with readOnlyHint=true, since it writes a file to the host filesystem, but this is a data-export side effect rather than a mutation of records, so it is not a true contradiction; overwrite behavior for an existing file name is not stated.

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?

A single sentence with zero filler, front-loading the action and format before the destination and return values. The default path detail is useful rather than redundant; only the mixed Portuguese/English naming could be tightened.

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 16-parameter tool with no parameter descriptions and no output schema, the description is thin: it covers the output shape well but says nothing about how the many filters combine or what an empty result produces. Coverage of the return contract mitigates somewhat, but the filter semantics a caller must get right are absent.

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% across 16 parameters, and the description explains none of them beyond implicitly mapping 'CSV ou XLSX' to the format field. The other 15 filters (q, period, dateStart/dateEnd, amounts, tagIds, cardIds, accountIds, categoryIds, personIds, condition, settlement, paymentMethod, type) get no added meaning such as date-range precedence or whether period overrides dateStart/dateEnd.

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?

States a specific verb and resource ('Exporta as transações') plus the output formats (CSV/XLSX) and destination, which makes the file-producing nature clear. It does not name or contrast with the nearest sibling (list_transactions), so an agent must infer that this tool persists a file while list_transactions returns data inline.

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: 'transações filtradas' hints that filter parameters scope the export, but there is no explicit when-to-use guidance, no mention of when to prefer list_transactions, and no exclusion such as empty results or very large ranges. An agent can pick this for 'export to file' requests but has no stated rule for the boundary cases.

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

Deploy Server