Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_resolve_group

Read-onlyIdempotent

Converts a group name into its Splitwise group id with ranked fuzzy candidates and an exact, probable, or ambiguous verdict, so you confirm the right group before creating expenses.

Instructions

Turn a group's name into its Splitwise group id, with ranked fuzzy candidates.

Calls GET /get_groups (not cached — groups change) and scores every group name with difflib.SequenceMatcher on case- and accent-folded text. Returns the top limit candidates with their scores. Group id 0 is Splitwise's pseudo-group for non-group expenses (group_id: 0 = no group).

A group is resolved ONLY on an exact name match (1.000, for exactly one group, and no other group name starting with the query — "Peru trip" next to "Peru trip 2026" is ambiguous). A close-but-not-exact name is reported as probable and must be confirmed with the user; a query whose numbers differ ("peru trip 2025" vs "Peru trip 2026") or that is under 4 characters gets no fuzzy candidate at all.

When to Use:

  • Before splitwise_create_expense, splitwise_get_group, splitwise_get_expenses, splitwise_add_user_to_group or splitwise_delete_group, when the user named a group ("the Peru trip").

When NOT to Use:

  • To list every group with balances — use splitwise_get_groups.

  • For people or categories — use splitwise_resolve_friend / splitwise_resolve_category.

Returns: The resolution line plus a markdown table (rank, Name (id N), type, members, score); or, with response_format json, {query, resolution, ambiguous_count, reason, resolved, probable, candidates: [{id, name, group_type, members_count, pseudo_group, score}]} where resolution is exact | probable | ambiguous | none, ambiguous_count (always present, 0 unless ambiguous) says how many candidates are in contention, resolved is set only for exact, and probable only for probable.

Examples: params = {"query": "peru trip"} params = {"query": "home", "limit": 3, "response_format": "json"}

Error Handling: A 401 means the API key is missing or was regenerated. With no groups the tool says so. Anything but exact means: ask the user, do not pick.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent safety profile, but the description goes well beyond them: the endpoint is uncached because groups change, scoring uses difflib.SequenceMatcher on case/accent-folded text, resolution succeeds only on an exact unique match (with the 'Peru trip' vs 'Peru trip 2026' ambiguity rule), short/numeral-differing queries yield no fuzzy candidate, group id 0 is the pseudo-group, and a 401 means the API key is missing or regenerated. This is unusually rich behavioral disclosure.

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?

Well front-loaded with the core purpose first, then structured sections. It is long, and the 'Returns' block partially duplicates the output schema, but each section earns its place given the resolution semantics an agent must get right.

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 an output schema exists, the description still supplies the resolution-state machine (exact/probable/ambiguous/none), the always-present ambiguous_count, the conditional resolved/probable keys, error handling, and the fallback instruction ('ask the user, do not pick'). Nothing an agent needs to call or interpret this tool 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 itself documents limit (1-25 range) and response_format, and the description reinforces both with the example call and the JSON return shape. It adds real semantic value for `query` by explaining the folding/scoring and <4-character and numeral-mismatch behavior — meaning the schema cannot convey — though it does not spell out the maxLength=100 or required-only constraints.

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?

States a precise verb+resource+outcome ('turn a group's name into its Splitwise group id, with ranked fuzzy candidates') and explicitly distinguishes itself from sibling resolvers and from splitwise_get_groups. An agent can identify this as the name-to-id resolver without opening any 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?

Has dedicated 'When to Use' and 'When NOT to Use' sections naming the concrete downstream tools that require a resolved id (create_expense, get_group, get_expenses, add_user_to_group, delete_group) and routing list queries to splitwise_get_groups and person/category lookups to splitwise_resolve_friend / splitwise_resolve_category.

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