Skip to main content
Glama

CDF Finance

by io.github.VessellTech

Atualizar categoria

update_category
Idempotent

Atualiza campos de uma categoria (parcial — campo omitido/vazio mantém o valor atual). Mesmas validações de create_category: parentId precisa ser de uma categoria própria do usuário com o mesmo type (e não pode ser a própria categoria), e vínculo com catálogo global exige type compatível.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesID da categoria a atualizar
iconNoNome do ícone, ex: 'shopping-cart'
nameNoNovo nome da categoria/subcategoria
typeNoEXPENSE ou INCOME
colorNoCor hex, ex: #3B82F6
parentIdNoID de outra categoria do usuário para tornar esta uma subcategoria dela
globalCategoryIdNoID de uma categoria do catálogo global para vincular
globalSubcategoryIdNoID de uma subcategoria do catálogo global para vincular

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNo

Schema Changelog

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

  1. Changed8 schema fields changed
    • addedInput schema / properties / color / description
      Added value: +"Cor hex, ex: #3B82F6"
    • addedInput schema / properties / globalCategoryId
      Added value: +{
+  "description": "ID de uma categoria do catálogo global para vincular",
+  "type": "string"
+}
    • addedInput schema / properties / globalSubcategoryId
      Added value: +{
+  "description": "ID de uma subcategoria do catálogo global para vincular",
+  "type": "string"
+}
    • addedInput schema / properties / icon / description
      Added value: +"Nome do ícone, ex: 'shopping-cart'"
    • addedInput schema / properties / id / description
      Added value: +"ID da categoria a atualizar"
    • addedInput schema / properties / name / description
      Added value: +"Novo nome da categoria/subcategoria"
    • addedInput schema / properties / parentId / description
      Added value: +"ID de outra categoria do usuário para tornar esta uma subcategoria dela"
    • addedInput schema / properties / type / description
      Added value: +"EXPENSE ou INCOME"
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds value beyond these by disclosing partial-update semantics (omitted/empty fields retain current values) and validation constraints on parentId and global-catalog links, which are meaningful behavioral details not inferable from annotations.

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 two compact sentences, with the most important behavioral trait (partial update) front-loaded in the first sentence and validation constraints in the second. There is no filler, redundancy, or unnecessary repetition of schema details.

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 exists and annotations cover the safety profile, so the description does not need to explain return values. It covers partial-update behavior and validation rules well. Minor gaps remain around how to clear nullable fields like parentId or globalCategoryId and around error behavior, but these are secondary given the richness of the schema and annotations.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds cross-parameter semantics not present in the schema, such as the partial-update rule, parentId ownership/type/self-reference validation, and global-catalog type compatibility requirements. This meaningfully helps the agent use the parameters correctly.

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 uses a specific verb ('Atualiza') and resource ('campos de uma categoria'), and immediately adds the partial-update trait, distinguishing it from create_category and delete_category. There is no ambiguity about what operation the tool performs.

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 use for an existing category by saying it updates fields, and it points to create_category for validation rules. However, it never explicitly states when to prefer this over create/delete or lists conditions or exclusions, so usage timing is left mostly to inference.

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

All CDF Finance toolsInspect
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.

Resources