CDF Finance

Criar meta

create_goal

Cria uma meta financeira (ex: 'Viagem', 'Reserva de emergência'). category e color são obrigatórios no banco — se omitidos, a meta é criada com esses campos vazios (string ''), então prefira sempre informá-los. Não dispara recalculo de analytics/insights (diferente de create_budget/create_debt).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Nome/título da meta
`color`	No	Cor de exibição (hex, ex: '#22C55E'). Campo obrigatório no banco — omitir grava string vazia
`category`	No	Categoria/tipo da meta (texto livre, ex: 'Viagem', 'Casa'). Campo obrigatório no banco — omitir grava string vazia
`currency`	No	Moeda (ISO 4217, ex: 'BRL'). Default: BRL
`deadline`	No	Prazo da meta (data ISO, ex: YYYY-MM-DD). Default: sem prazo (null)
`targetAmount`	Yes	Valor alvo a ser atingido
`currentAmount`	No	Valor já acumulado hoje. Default: 0

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`name`	No
`color`	No
`userId`	No
`category`	No
`currency`	No
`deadline`	No
`createdAt`	No
`updatedAt`	No
`targetAmount`	No
`currentAmount`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed9 schema fields changedSep 1, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "Categoria/tipo da meta (texto livre, ex: 'Viagem', 'Casa'). Campo obrigatório no banco — omitir grava string vazia",
+  "type": "string"
+}

addedInput schema / properties / color / description

Added value: +"Cor de exibição (hex, ex: '#22C55E'). Campo obrigatório no banco — omitir grava string vazia"

addedInput schema / properties / currency

Added value: +{
+  "description": "Moeda (ISO 4217, ex: 'BRL'). Default: BRL",
+  "type": "string"
+}

addedInput schema / properties / currentAmount / description
```
Added value: +"Valor já acumulado hoje. Default: 0"
```

addedInput schema / properties / deadline

Added value: +{
+  "description": "Prazo da meta (data ISO, ex: YYYY-MM-DD). Default: sem prazo (null)",
+  "type": "string"
+}

removedInput schema / properties / icon

Removed value: -{
-  "type": "string"
-}

addedInput schema / properties / name / description
```
Added value: +"Nome/título da meta"
```
addedInput schema / properties / targetAmount / description
```
Added value: +"Valor alvo a ser atingido"
```
removedInput schema / properties / targetDate
```
Removed value: -{
-  "type": "string"
-}
```

First observedSep 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (which only indicate non-read-only and non-idempotent), the description discloses a critical database behavior: category and color are required at the DB level but get silently stored as empty strings if omitted, with a recommendation to always provide them. It also explicitly states that no analytics/insights recalculation is triggered, a useful side-effect trait for the agent.

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 compact and well-structured: purpose first, then a critical behavioral warning, then a differentiation note. Every sentence adds distinct value with no repetition or filler.

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?

Given the presence of a complete input schema and output schema, the description covers the essential operational nuances not evident from structured data: the DB-level required fields and the absence of analytics recalculation. An agent has enough context to invoke the tool correctly without needing additional details.

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 all seven parameters are already documented with meaningful descriptions. The tool description mostly repeats the category/color DB-required caveat already present in the schema, adding only the advice to prefer providing them. Since the schema carries the heavy lifting, a baseline score of 3 is appropriate.

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 states a specific verb ('Cria') and resource ('meta financeira') with concrete examples ('Viagem', 'Reserva de emergência'). It also differentiates from create_budget and create_debt by noting the analytics recalculation difference, making the tool's scope clear even among many create_* siblings.

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?

The description explicitly names create_budget and create_debt as alternatives in the context of analytics recalculation, providing a clear criterion for choosing this tool over those when no recalculation is desired. It does not, however, explain the broader semantic differences between a goal, budget, and debt, so some inference is still required.

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

All CDF Finance tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/5

The tools are individually well-described and many cross-reference their closest neighbors, but the set contains several easily confused clusters: create_transaction/confirm_new_transaction, update_equity/add_equity_valuation, the invoice tools (current_invoice, next_invoice, list_pending_invoices, get_invoice), and the many analytics/projection tools. The descriptions help a careful reader, but with 81 tools an agent is likely to misselect among these overlapping surfaces.

Naming Consistency3/5

CRUD operations consistently use create_/list_/update_/delete_ plus a resource noun, and all names are snake_case. However, there is a large second group of noun-phrase analytics tools (cashflow_forecast, spending_projection, categories_insights, transport_routine) plus one-off verbs such as can_afford, pay_invoice, and validate_current_invoices, so the naming convention is mixed even though it remains readable.

Tool Count1/5

81 tools is far beyond the practical MCP tool surface and exceeds the rubric's 50+ extreme-mismatch threshold. Even if each tool maps to a real finance endpoint, the volume overwhelms an agent's context window and makes selection much harder.

Completeness4/5

The server covers the finance lifecycle extensively: accounts, cards, invoices, transactions, recurring rules, budgets, goals, debts, equities, categories, tags, cost centers, profile, projections, and insights all have working read/write paths. Minor gaps remain, such as no update/delete for tags and no direct update/delete for system-generated invoices, but agents can usually work around these.

Criar meta

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources