Skip to main content
Glama
trustxai

amazing-splitwise-mcp

by trustxai

splitwise_get_comments

Read-onlyIdempotent

List comments on a Splitwise expense to read discussion or edit history and retrieve comment IDs before deleting one.

Instructions

List the comments on one Splitwise expense.

Calls GET /get_comments?expense_id=… and renders one row per comment: its id, the author as First Last (id N), the type (System = written by Splitwise, e.g. an edit log; User = written by a person), when it was created, and the text.

When to Use:

  • To read the discussion or the edit history on an expense.

  • To find a comment's id before deleting it with splitwise_delete_comment.

When NOT to Use:

  • To read the expense itself (cost, shares) — use splitwise_get_expense.

  • To see recent activity across all expenses and groups — use splitwise_get_notifications.

  • To find an expense id from a description — use splitwise_get_expenses.

Returns: Markdown: a table | Id | Author | Type | Created | Content | (at most 50 rows, the rest counted; each text capped at 2,000 characters, the cut counted). JSON: {"expense_id", "count", "comments": [raw comment objects]}.

Examples:

  • params = {"expense_id": 51023}

  • params = {"expense_id": 51023, "response_format": "json"}

Error Handling: 404 means the expense id does not exist or was deleted; 403 means you are not part of that expense. Errors come back as an Error ... string, never raised.

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 declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the System vs User comment-type semantics, truncation behavior (50 rows, 2,000 chars, with counts of what was cut), and error semantics (404 = nonexistent/deleted expense, 403 = not a member, errors returned as strings never raised).

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 a one-line purpose, then clearly sectioned into When to Use / When NOT / Returns / Examples / Error Handling. Every section earns its place, though the Returns paragraph restates part of what the output schema already carries, making it slightly longer than strictly necessary.

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 read-only list tool with an output schema, the description closes the remaining gaps an agent would hit: authorization failure modes, the meaning of each comment type, and the truncation limits on the rendered output. Nothing needed to call it 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?

Schema descriptions exist for both fields, but the description adds meaning: it explains that response_format chooses between a rendered table and raw comment objects, and provides two concrete worked payloads for expense_id. It stops short of describing any constraint on expense_id beyond what the schema already says.

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 specific verb and resource ('List the comments on one Splitwise expense') and immediately disambiguates from siblings like splitwise_get_expense and splitwise_get_notifications. The agent can distinguish this from every other get_* tool 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' (read discussion/edit history, find a comment id before splitwise_delete_comment) and 'When NOT to Use' sections that name three concrete alternative tools and the condition that selects each. This is exactly the routing guidance an agent needs.

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