split-bill-mcp

by elyor-sh

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Create a release to enable server coherence scoring.
Create a release to enable tool definition quality scoring.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says a status is updated, leaving side effects, permissions, idempotency, and error behavior undisclosed. The enum values are already present in the schema and add no additional behavioral context.
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?
The description is a single efficient sentence with no filler or redundancy, and the allowed status values are compactly parenthesized. It is appropriately short, though its brevity leaves other dimensions under-served.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no annotations and no output schema, this description is incomplete: an agent cannot infer the response format, authorization requirements, idempotency, or possible side effects. The schema provides the required parameters, but the description adds little operational context beyond the basic update target.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only 'participant' described. The description clarifies the update target ('on a bill') but does not explain billId, lang, or how status values are applied beyond repeating the schema enum. It does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update') and a specific resource ('participant payment status on a bill'), listing the allowed status values. It is distinguishable from sibling tools like create_bill and get_bill because no sibling targets payment status, though it does not explicitly contrast with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor are there stated prerequisites, exclusions, or scenarios that would warrant calling update_payment. The only usage signal is the imperative 'Update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions search criteria and purpose but does not describe case sensitivity, partial matching, pagination, result limits, or whether it searches globally or only within the user's context. This leaves meaningful gaps for an agent deciding how to interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the core action and purpose. Every word adds value, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter documentation, the description is too thin. It leaves unresolved how results are returned, what the 'lang' parameter does, and what the search behavior is, which an agent needs to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters. It explains the 'query' parameter by specifying it accepts a name or email, but it does not explain the 'lang' parameter at all, and it omits minimum length or formatting implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), resource ('SplitBill users'), and search criteria ('by name or email'), and it adds a purpose ('to resolve participant IDs'), which clarifies intent. It is distinguishable from siblings like list_friends and get_bill, though it does not explicitly differentiate itself from every possible alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use it when you need to find users by name or email, particularly to resolve participant IDs. However, it does not explicitly state when not to use it or name alternative tools such as list_friends for browsing known friends.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does communicate a read-only aggregate and names the output categories, but it remains silent on whether the optional lang parameter affects results, the time scope of bills, or whether 'amounts owed and owing' are totals or breakdowns. This is partial disclosure, not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the main purpose and lists the key output fields. Every word earns its place, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic return categories but omits any explanation of the optional lang parameter, the assumed scope of bills, and the return shape. Because there is no output schema and no annotations, these missing details leave the agent with incomplete information to call the tool correctly and interpret its response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, lang, appears in the schema with no description and is not mentioned in the tool description. Since schema description coverage is 0%, the description fails to clarify whether lang is a language code, locale, or something else, leaving the agent to guess. This is a critical gap in an otherwise simple tool.
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 description uses a specific verb ('Get'), names the resource ('SplitBill dashboard totals'), and enumerates exact contents (bill count, amounts owed and owing). This clearly distinguishes it from sibling tools like list_bills or get_bill, which are about individual bills rather than aggregated totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as list_bills or get_bill. The description implies a dashboard context but does not state whether this tool aggregates across all bills, whether it requires authentication, or how it relates to the other bill/stat endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List my friends' and gives a use case; it does not disclose whether the result includes pending friend requests, how the 'include_requests' parameter changes behavior, whether pagination exists, or what fields are returned. The uncovered behavior around requests is significant.
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?
The description is a single front-loaded sentence with no filler, and every word contributes to the core purpose. However, it is arguably too short given the schema's lack of parameter descriptions, so it could have used a bit more space to explain behavior without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, this description is not complete enough. It does not explain include_requests, which appears to be a key behavioral switch, nor does it clarify how lang affects results. It also gives no guidance on choosing this tool over search_users, leaving gaps that an agent would need to guess about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate by explaining either 'lang' or 'include_requests'. The only parameter hint is the parenthetical about bill participants, which is unrelated to the actual parameters. An agent has no way to know what these parameters do.
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 description states a specific verb 'List' and resource 'my SplitBill friends', and immediately frames the purpose ('for picking bill participants'). This clearly distinguishes it from siblings like list_bills (which lists bills) and search_users (which searches arbitrary users), leaving no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: it is for picking bill participants from one's own friend list. However, it does not explicitly mention alternatives or when not to use it, such as when searching for users outside the friend list with search_users would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does convey that this is a read operation returning a single bill with participants and payment statuses, but it omits any detail about error handling, authentication, or exact response shape. This is adequate for a simple get-by-ID, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler: it names the action, the resource, the key identifier, and the returned content. It is well front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description gives only a high-level view of the return value ('participants and payment statuses') and does not explain the optional lang parameter. For a simple read operation, this is minimally sufficient, but an agent would still need to guess at response structure and language semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies that the tool retrieves a bill by ID, which maps to billId. The 'lang' parameter is entirely unaddressed in both the schema and the description, leaving its purpose and expected values ambiguous. The description does not adequately compensate for the lack of parameter documentation.
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 description uses a specific verb 'Get' with a clear resource 'one SplitBill bill by ID' and indicates what is included: participants and payment statuses. It is clearly distinct from siblings like list_bills, create_bill, and update_payment, so an agent can identify the correct tool without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by 'Get one SplitBill bill by ID' — an agent can infer this is for retrieving a single bill when the billId is known. However, it does not explicitly name alternatives like list_bills or state when not to use this tool, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the verb 'List' and the scope 'my' signal a read-only, user-scoped operation, which is valuable behavioral context. It does not disclose defaults, auth requirements, or response characteristics, but nothing contradicts the read-only implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence states the operation before listing filters, with no filler or redundancy. It is appropriately sized for the tool's function and communicates the key information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description leaves significant gaps: it does not describe the returned bill fields, sorting behavior, default filter values, or what 'my' precisely includes (creator, payer, debtor). The filter vocabulary helps, but an agent lacks enough operational detail to fully predict the call's behavior.
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?
Despite 0% schema-description coverage, the description maps most parameters to semantic concepts: payment status (status), my role (role), title search (search), date range (date_from/date_to), and pagination (page/limit). This adds meaning beyond raw parameter names, though 'lang' remains unexplained.
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 description names a specific verb and resource ('List my SplitBill bills') and enumerates filter dimensions, making the operation unambiguous. It is clearly distinguishable from siblings like get_bill (single bill) and create_bill (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the core use case—listing the current user's bills—so an agent can infer when to call it. However, it does not explicitly name alternatives or state when not to use this tool, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions that raw_receipt mode 'splits' receipt positions, but it does not describe side effects, permissions, irreversibility, VAT handling, or success/error behavior for this mutating create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The main action is front-loaded and the mode distinction is explained efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains how to choose between the two modes and the schema supplies the remaining parameter details. However, with no annotations and no output schema, it leaves out important context about return values, permissions, and what 'splits them' concretely produces. This is a noticeable gap for a complex creation tool.
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 coverage is 100%, so the schema already documents the parameters. The description adds useful semantic meaning by explaining what distinguishes the two mode branches: ready_split uses pre-split participants with totals, while raw_receipt uses receipt positions with consumers and splits them. This goes beyond the bare schema.
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 description clearly states the action and resource: 'Create a SplitBill bill.' It then differentiates the two modes of creation, so an agent can distinguish this tool from list_bills, get_bill, and update_payment. The purpose is unambiguous and mode-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance for choosing mode=ready_split versus mode=raw_receipt, which is the key branching decision for this tool. It does not name sibling alternatives, but the sibling list contains only non-creation operations, so the usage context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

split-bill-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![split-bill-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/elyor-sh/split-bill-mcp/badges/card.svg)](https://glama.ai/mcp/servers/elyor-sh/split-bill-mcp)

Score Badge

Copy to your README.md:

[![split-bill-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/elyor-sh/split-bill-mcp/badges/score.svg)](https://glama.ai/mcp/servers/elyor-sh/split-bill-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elyor-sh/split-bill-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server