Skip to main content
Glama
Sign In
1fluxo Bridge

1fluxo Bridge

by jpcesar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

list_months

List existing months in 1fluxo from oldest to newest, with open/closed status and net balance, so you can see gaps before requesting summaries or movements.

Instructions

Lista os meses que existem no 1fluxo, do mais antigo ao mais recente, com o estado de cada um (open = em curso, closed = fechado pelo utilizador) e o saldo líquido do mês. O utilizador cria os meses um a um, por isso pode haver meses em falta. Use isto antes de pedir resumos ou movimentos.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful traits: deterministic ordering, what the state field means (open/closed), and the important caveat that months may be missing because users create them one at a time. It does not explicitly state read-only/permission behavior, but 'Lista' strongly implies a read.

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?

Three front-loaded sentences: what it returns first, then the state semantics and data-completeness caveat, then the usage pointer. Every sentence earns its place, though the state glosses add modest length.

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, so the description must describe the return payload, and it does: the set of months, their open/closed state, and each month's net balance, plus the caveat about gaps. Nothing an agent needs in order to call and interpret this tool is missing.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related for the description to clarify, and the schema is trivially complete.

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?

States a specific verb (lista) and resource (meses), plus scope details: ordering (oldest to newest), per-month state with enum meanings, and net balance. An agent can distinguish this from get_month_summary or list_movements without inspecting schemas.

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?

Explicitly says to use it before requesting summaries or movements, which routes the agent away from get_month_summary/list_movements for this step. It gives clear context but no hard exclusions or prerequisites (e.g., auth, empty-state handling).

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