Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_get_categories

Read-onlyIdempotent

Browse Splitwise expense categories and their subcategories with IDs to select the correct subcategory ID before creating or recategorizing an expense.

Instructions

List Splitwise's expense categories: each parent with its subcategories and their ids.

Calls GET /get_categories once and caches the answer in-process for 24 h (the list is static); refresh: true refetches. Expenses must use a subcategory id as category_id — a parent id is not accepted. When nothing fits, use the "Other" subcategory under the closest parent (or "General" under "Uncategorized"). Names come back in the account's locale (a Spanish account sees "Supermercado", "Taxi", "Avión" — not the English names from Splitwise's docs); the ids are the same everywhere.

When to Use:

  • To browse the categories before creating or recategorising an expense.

  • To list one parent's subcategories (parent: "food").

When NOT to Use:

  • To turn a category name into an id — use splitwise_resolve_category, which ranks subcategories by similarity and says when one is a clear match.

  • For currencies — use splitwise_get_currencies.

Returns: A markdown table with one row per parent (flagged as not usable for expenses) and its subcategories as Name (id N), capped at 50 parents; or the raw {"categories": [...]} objects (with icons and nested subcategories) when response_format is json.

Examples: params = {} params = {"parent": "transport"} params = {"refresh": true, "response_format": "json"}

Error Handling: A 401 means the API key is missing or was regenerated. A failed fetch is never cached (a failed refresh keeps the previous cached list); a parent filter that matches nothing lists the parent names to pick from.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world and non-destructive, but the description adds substantial behavior beyond them: a 24 h in-process cache with refresh override, the rule that failed fetches are never cached and a failed refresh retains the prior list, locale-dependent names with globally stable ids, and a 401 meaning an invalid/regenerated key. This is exactly the extra context annotations cannot carry.

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?

Long but front-loaded and sectioned (behavior, When to Use, When NOT to Use, Returns, Examples, Error Handling). Every block carries distinct, non-redundant information – caching rules, subcategory-id constraint, locale caveat, call examples – so no sentence is 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?

The tool's output shape is spelled out (markdown table vs raw JSON with icons and nested subcategories) even though an output schema exists, the caching/auth failure modes are covered, and the subcategory-id requirement closes the main misuse risk. Nothing an agent needs to invoke this correctly 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 schema already documents parent (substring/numeric id match), refresh (bypass cache) and response_format (markdown vs json), so the description's marginal value is mostly on refresh cache semantics, the empty-parent-match fallback, and the 50-parent cap. It reinforces but rarely surpasses the schema text for the individual parameters.

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?

Opens with a specific verb+resource ('List Splitwise's expense categories: each parent with its subcategories and their ids') and immediately distinguishes itself from splitwise_resolve_category and splitwise_get_currencies by name. An agent knows exactly what this tool returns and what it is not for without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to Use' / 'When NOT to Use' sections with named alternatives: name-to-id lookup goes to splitwise_resolve_category, currencies go to splitwise_get_currencies. It even states the prerequisite workflow (browse categories before creating/recategorising an expense).

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