Skip to main content
Glama
Sign In

Mofi

by br.com.omofi
OverviewDiscussionsAdmin

Get statements

mofi_statements_get
Read-onlyIdempotent

Find or filter statements with observed linked-transaction totals by currency. Difference compares the statement total with posted and pending debits minus credits; canceled and removed rows are excluded. Coverage is always unknown, so a match does not prove the bill is complete or paid. Period and payment status remain unknown. Use the encrypted nextCursor unchanged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mode": "<mode>"
    },
    "name": "mofi_statements_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYesfindOne requires statementId; query requires where; findAll accepts page.
pageNoOpaque keyset pagination.
whereNoRequired only for query.
statementIdNoRequired only for findOne.

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNo
modeNo
pageNo
errorNoTyped error (code, message, retryable, details); set when isError is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, which already establish that this is a safe read-only operation, the description discloses meaningful domain behavior: canceled and removed rows are excluded, coverage is always unknown, and a match does not prove the bill is complete or paid. It also notes that period and payment status remain unknown, which is useful for interpreting results.

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?

The description is dense but efficient. It front-loads the purpose, then layers in calculation semantics, data-quality caveats, and cursor handling without unnecessary wording.

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?

The output schema and annotations cover return values and safety, while the description supplies the key caveats an agent needs to interpret results correctly. It is nearly complete, though it does not explicitly route the agent among sibling lookup tools or explain the mode choices beyond what the schema provides.

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 schema already carries the main parameter documentation. The description adds one important operational detail beyond the schema: the encrypted nextCursor must be passed unchanged, which helps prevent pagination errors.

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: "Find or filter statements," then narrows the scope to statements with observed linked-transaction totals by currency. This is clearly distinct from sibling account, card, transaction, and recurring lookup tools.

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?

The description implies the tool is for finding or filtering statements and gives important caveats about coverage and unknown fields, but it does not explicitly say when to choose this over sibling tools such as mofi_transactions_get or when not to use it. The usage context is inferable rather than stated.

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

All Mofi toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources