Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_resolve_category

Read-onlyIdempotent

Resolve an expense category name to its Splitwise subcategory ID, returning ranked fuzzy matches so you can pass the correct ID to create or update an expense.

Instructions

Turn a category name into the subcategory id an expense needs, with ranked fuzzy candidates.

Reads the categories from GET /get_categories through the same 24 h in-process cache as splitwise_get_categories (refresh: true refetches). Every subcategory is scored with difflib.SequenceMatcher on case- and accent-folded text — the best of its name, each piece of the name split on / and spaces ("phone" → TV/Phone/Internet), and "Parent Subcategory" (so "transportation other" picks the right "Other").

Subcategories are listed first and are the only ones that can be resolved: exactly one exact (1.000) match, or — with no exact match — exactly one scoring ≥ 0.85 (unique_strong; a wrong category is cheap to fix with splitwise_update_expense). Either way no other subcategory may start with the query ("tax" next to Taxi and Taxes is ambiguous), a fuzzy match needs a query of 4+ characters, and digits in the query must match. The closest parent categories follow, flagged "parent — not usable for expenses", with their subcategories so you can pick one; a parent scores the better of its own name and its best subcategory (so "groceries" surfaces "Food and drink").

The names scored are the ones Splitwise returns for this account's locale: on a Spanish account "groceries" finds nothing but "supermercado" resolves. Query in the language the user sees in their Splitwise app, or browse splitwise_get_categories.

When to Use:

  • Before splitwise_create_expense / splitwise_update_expense, when the user named a category ("groceries", "taxi").

When NOT to Use:

  • To browse the whole tree — use splitwise_get_categories.

  • For people or groups — use splitwise_resolve_friend / splitwise_resolve_group.

Returns: The resolution line, a markdown table of the top limit subcategories (rank, Name (id N), parent, score, matched on), then up to 3 parents with their subcategories; or, with response_format json, {query, resolution, ambiguous_count, reason, resolved, subcategories: [...], parents: [...]} where resolution is exact | unique_strong | ambiguous | none, ambiguous_count (always present, 0 unless ambiguous) says how many candidates are in contention, and parents carry usable_for_expenses: false.

Examples: params = {"query": "groceries"} params = {"query": "transportation other", "response_format": "json"}

Error Handling: A 401 means the API key is missing or was regenerated. A failed fetch is never cached. Several subcategories share the name "Other" — "other" alone is reported as ambiguous; qualify it with the parent.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context beyond them: the shared 24 h cache and what refresh does, the exact resolution thresholds (1.000 exact, unique_strong ≥ 0.85), the ambiguity rules (prefix collision, 4+ char fuzzy minimum, digit matching), locale-dependent naming, and error handling (401 = missing/regenerated key, failed fetches never cached). This is far richer than the annotations alone.

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?

Front-loaded one-line summary, then clearly headed sections (When to Use / When NOT to Use / Returns / Examples / Error Handling). Highly dense and mostly earns its length, but the deep dive into scoring internals (difflib on accent-folded text, the 'phone' → TV/Phone/Internet example) is more than an agent strictly needs to invoke the tool.

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?

For a fuzzy-resolution tool with an output schema, everything an agent needs is present: prerequisite sequencing before expense creation, cache/refresh behavior, locale caveats, ambiguity outcomes, and error handling. The Returns section is redundant with the output schema but harmless.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although coverage is reported low, the description adds real meaning beyond the schema: refresh is explained in terms of the 24 h cache, response_format is tied to the concrete json/markdown shapes, and query is given crucial semantics the schema lacks — query in the user's Splitwise locale language, 4+ characters required for fuzzy matching, digits must align, and 'other' alone is ambiguous and must be qualified with a parent.

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 opening line states a precise verb and resource ('turn a category name into the subcategory id an expense needs') plus the scope of output ('ranked fuzzy candidates'). It is immediately distinguishable from splitwise_get_categories, which the description explicitly routes the browser to. An agent can tell which tool to pick without opening either 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?

Dedicated 'When to Use' and 'When NOT to Use' sections name the exact upstream callers (splitwise_create_expense / splitwise_update_expense) and the alternative tools for browsing and for people/groups. The condition that selects each alternative is stated, not implied.

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