Skip to main content
Glama
georgebashi

lunchmoney-mcp

by georgebashi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_category

Create a new category or a category group to organize Lunch Money transactions. Use is_group to build groups with existing or new sub-categories.

Instructions

Create a new category or a category group. Set is_group=true to create a category group; supply children as an array of existing category IDs and/or strings (names of new sub-categories to create).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the category. 1-100 characters.
archivedNoWhether the category should be archived.
childrenNoOnly valid when is_group is true. Array of existing category IDs (numbers) and/or names of new sub-categories to create (strings).
group_idNoIf set, assigns the new category to an existing category group. Cannot be set if is_group is true.
is_groupNoIf true, creates a category group instead of a category. When true, group_id may not be set; use children to assign existing categories.
is_incomeNoWhether transactions in this category should be treated as income.
descriptionNoOptional description. Up to 200 characters.
exclude_from_budgetNoWhether transactions in this category should be excluded from budgets.
exclude_from_totalsNoWhether transactions in this category should be excluded from calculated totals.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

A4.2/5.0
Behavior4/5

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

The only annotation is idempotentHint=false, so the description must carry behavioral weight. It discloses a notable side effect: passing strings in children creates new sub-categories during the same call. It does not cover return values or failure modes, but the core recursive behavior is clearly stated and does not contradict the 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?

Two short, front-loaded sentences with no filler. The first sentence states the core purpose and the second covers the mode-specific behavior. Every word contributes to invocation understanding.

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?

Given 9 parameters, no output schema, and minimal annotations, the description captures the most important invocation nuances: the is_group switch and the dual ID/string behavior of children. The remaining parameters are fully documented in the schema. Return-value details are absent, but the description is sufficient for correctly selecting and calling the tool.

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 the baseline is 3. The description restates the is_group and children behavior seen in the schema rather than adding new parameter meaning. It usefully frames the category versus category-group decision, but does not go beyond the schema's own parameter descriptions.

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 and resource: 'Create a new category or a category group.' It clearly distinguishes the dual purpose of the tool and immediately explains how the two modes are selected. This is enough to tell it apart from sibling tools like create_tag or create_transaction_group.

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?

No explicit when-not-to-use or alternative is named, but there is no close sibling for category creation. The description gives clear context for the two main usage modes: set is_group=true for a category group, and use children to add existing IDs or names of new sub-categories. This effectively communicates usage without leaving mode selection to inference.

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