Loading ToolBench
An MCP server that reads and writes Settle Up shared expense data through the Firebase REST API
Strong foundation with clear naming conventions (verb_noun pattern), comprehensive parameter schemas with type constraints, and good descriptions. All 10 tools follow consistent patterns. However, output schemas are not explicitly documented in the source, and error handling guidance is minimal. Tool descriptions are well-structured (100-200 chars typical) with dependency hints ('Use settleup_list_groups to find it'), meeting LLM-optimization baselines. Parameter constraints (minLength, maxLength, min/max for integers) are properly declared. Risk annotations (READ_ONLY, WRITE) are present but not formally mapped to tool annotations in the code.
Create one new group. Add yourself as the first member. The tool makes 5 writes. It creates the group, the permission, your member, the group link, and the current tab.
Give the debts and the net balance of each member in one group. The Settle Up server calculates the debts. A positive net balance means that the other members owe money to this member.
Give the settings and the counts of one group. Use this tool to read the currency, the member count, and the transaction count before a write.
List the custom category names of one group. A category is an emoji. A group can give a name to each emoji. Use an emoji from this list in settleup_add_expense.
List the changes in one group. The Settle Up server writes 1 entry for each change. Use this tool to find who added, changed, or deleted an entity.
Output schemas not documented in source code. Tool descriptions state what is returned (e.g., 'Give the debts and the net balance') but formal response schemas are not visible. LLMs cannot plan downstream tool calls without knowing return field names and types.
Error handling and recovery guidance absent. No tool description explains what to do if a group_id is invalid, if permissions are insufficient, or if a write operation fails. Agents have no actionable next steps on errors.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in feature flags but not visible in tool registration code. Risk field is present in metadata but not formally mapped to MCP tool annotations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
List each Settle Up group that the account can read. Use this tool first. The other tools need a group id from this list.
List the members of one group. A member is a person in the group. Each expense refers to member ids.
List the user accounts that can access one group. A permission belongs to a user account. It does not belong to a member. The levels are 30 (owner), 20 (read and write), and 10 (read only).
Ask the Settle Up server to calculate the debts again. The server does this automatically after each change. Use this tool only when the balances look wrong.
Change the name, the debt setting, or the invite link. Give only the fields that change. This tool does not change the currency. Use settleup_change_currency for that.
Pagination limit defaults to 50 but maximum is 200. No guidance on when to use higher limits or how to handle large result sets. Description does not warn about context window impact of returning 200 items.
settleup_recalculate_debts description is vague ('Use this tool only when the balances look wrong'). No guidance on how to detect when recalculation is needed, what triggers the need, or what success looks like.