Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_get_currencies

Read-onlyIdempotent

List Splitwise-accepted currency codes and units, optionally filtered by a substring, to check a code or find it from a symbol before setting expenses or defaults.

Instructions

List the currency codes Splitwise accepts, optionally filtered by a substring.

Calls GET /get_currencies once and caches the answer in-process for 24 h (the list is static); refresh: true refetches. Codes are mostly ISO 4217 plus a few colloquial ones (e.g. BTC); each comes with its display unit ($, S/, €).

When to Use:

  • To check that a currency code is accepted before using it as currency_code on an expense or as a user's default_currency.

  • To find a code from its symbol (query: "€").

When NOT to Use:

  • For balances per currency — use splitwise_get_balances.

  • For categories — use splitwise_get_categories.

Returns: A markdown table of Code | Unit (capped at 50 rows; narrow with query), or the raw {"currencies": [{currency_code, unit}]} objects when response_format is json.

Examples: params = {} params = {"query": "pen"} params = {"query": "eur", "response_format": "json"}

Error Handling: A 401 means the API key is missing or was regenerated. A failed fetch is never cached; a query that matches nothing says so instead of returning an empty table.

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Despite readOnlyHint/idempotentHint already covering safety, the description adds substantial behavior: a 24 h in-process cache, refresh semantics, the 50-row cap, 401 meaning a missing/regenerated key, and the fact that failed fetches are never cached and empty results are messaged rather than silently empty.

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 with the core action and organized under clear headers; the examples are concrete and useful. It is on the long side, and the Returns block partially restates what the output schema already carries, but no section is padding.

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?

Covers caching, refresh, filtering, output shape (including the row cap), auth failure mode, and no-match behavior — everything an agent needs to call this correctly and interpret the result, even with a nested params object and no per-parameter coverage in the context.

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?

Schema description coverage is reported as 0%, so the description must compensate, and it does: it explains that query is a case-insensitive substring match over code or unit (with a symbol example), that refresh bypasses the 24 h cache, and that response_format selects table vs raw objects.

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 sentence states a specific verb and resource: listing currency codes accepted by Splitwise. It also distinguishes itself from siblings by explicitly naming splitwise_get_balances and splitwise_get_categories as the tools for other per-currency/category needs.

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' and 'When NOT to Use' sections give concrete scenarios (validating a currency_code before an expense, resolving a symbol like "€") and name the alternative tools for out-of-scope needs. Nothing is left to inference.

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