xendit-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource type (e.g., balance, disbursement, invoice, transaction) and action (get vs. list), but there is some overlap between 'xendit_get_disbursement' and 'xendit_get_disbursement_by_external_id' as both retrieve disbursements, which could cause confusion. Descriptions help clarify the distinction, but the purpose overlap exists.
Naming Consistency5/5
All tool names follow a consistent 'xendit_verb_noun' pattern with snake_case, using 'get' for single resource retrieval and 'list' for collections. This predictable naming scheme makes it easy for agents to understand and navigate the tool set without ambiguity.
Tool Count5/5
With 13 tools, the count is well-scoped for a payment processing domain, covering key resources like balance, disbursements, invoices, transactions, and refunds. Each tool serves a specific purpose, and the number is neither too sparse nor overwhelming for the server's functionality.
Completeness4/5
The tool set provides comprehensive read operations (get and list) for all major payment-related resources, which is suitable for investigation and monitoring use cases. However, there are gaps in write operations (e.g., create, update, or delete for invoices or disbursements), limiting full lifecycle coverage, though this may be intentional for the server's focus.
Average 3.2/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), implying it's likely safe and non-destructive, but doesn't address authentication requirements, rate limits, error conditions, or what specific details are returned. This leaves significant gaps for an agent to understand how to use it effectively.
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, clear sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned (e.g., invoice status, amount, date), potential errors, or how this tool fits into the broader Xendit API context with its siblings. For a read operation with no structured output documentation, more behavioral and contextual information would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the single parameter 'invoiceId'. The description adds no additional semantic context about the parameter, such as format examples or where to find invoice IDs, but doesn't need to since the schema is comprehensive. This meets the baseline for high 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 clearly states the action ('Get details') and resource ('specific invoice'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'xendit_list_invoices' or 'xendit_get_transaction', which might also retrieve invoice-related information.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'xendit_list_invoices' for listing multiple invoices or 'xendit_get_transaction' which might overlap in functionality, nor does it specify prerequisites or contextual constraints for usage.
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. It states it 'Get refund details' which implies a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'details' include (e.g., status, amount). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 and no output schema, the description is incomplete. It doesn't explain what 'refund details' include (e.g., fields like status or amount), potential errors, or usage context. For a tool with zero structured coverage beyond input schema, this leaves critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'refundId' fully documented in the schema as 'Xendit refund ID (rfd_...)'. The description adds no additional meaning beyond this, such as format examples or sourcing instructions, so it meets the baseline of 3 where the schema does the heavy lifting.
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 clearly states the verb 'Get' and the resource 'refund details', specifying it retrieves information by 'Xendit refund ID'. It distinguishes from siblings like 'xendit_list_refunds' by focusing on a single refund rather than listing multiple, though it doesn't explicitly mention this distinction.
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 alternatives. It doesn't mention prerequisites (e.g., needing a refund ID), exclusions, or compare it to sibling tools like 'xendit_list_refunds' for bulk retrieval or other get tools for different resources.
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 burden for behavioral disclosure. While 'Get details' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what details are returned (e.g., transaction status, amount, timestamp). For a tool with no annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple lookup tool and front-loads the core purpose immediately.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned (transaction status, amount, etc.), authentication needs, error handling, or how it differs from sibling tools. For a financial transaction tool with no structured output documentation, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by Xendit transaction ID' which aligns with the single parameter 'transactionId' in the schema. With 100% schema description coverage (the schema already documents the parameter as 'Xendit transaction ID (txn_...)'), the description adds minimal value beyond what's in the structured data. This meets the baseline for high 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 clearly states the action ('Get details') and resource ('specific transaction by Xendit transaction ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'xendit_list_transactions' or 'xendit_get_invoice', which would be needed for a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'xendit_get_transaction' versus 'xendit_list_transactions' (for multiple transactions) or other sibling tools like 'xendit_get_invoice' (for invoice-specific details). No usage context or exclusions are provided.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens on errors. It also doesn't describe the return format (e.g., pagination, structure), leaving significant gaps for an agent to infer behavior.
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, efficient sentence that front-loads the core action ('List refunds') and adds necessary filtering details. There's no wasted text, and it's appropriately sized for the tool's complexity.
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 0% schema description coverage, the description is incomplete. It covers the basic purpose and some parameters but lacks critical context like behavioral traits (e.g., safety, pagination), full parameter semantics, and return values. For a 4-parameter list tool with no structured support, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds value by naming three filter parameters ('payment_request_id', 'invoice_id', 'reference_id'), but it doesn't explain the 'limit' parameter or provide any details on parameter formats, constraints, or interactions. This partially compensates but leaves key parameters undocumented.
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 clearly states the verb ('List') and resource ('refunds'), and specifies optional filtering parameters. However, it doesn't explicitly differentiate from sibling tools like 'xendit_get_refund' (singular vs. plural), which could help an agent understand when to use this list operation versus retrieving a specific refund.
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?
The description mentions optional filtering but provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify when to use 'xendit_list_refunds' versus 'xendit_get_refund' (singular) or other list tools like 'xendit_list_invoices'. There's no mention of prerequisites, context, or exclusions.
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. It mentions 'optional filters' and a specific use case for 'reference_id', but lacks critical behavioral details: it doesn't specify whether this is a read-only operation, what permissions are needed, if there are rate limits, pagination behavior (beyond the 'limit' parameter in schema), or what the output looks like. For a list tool with no annotation coverage, this is inadequate.
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 extremely concise with two sentences: the first states the core purpose, and the second provides a specific usage tip. Every word earns its place, and it's front-loaded with the main action. No wasted verbiage.
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 the complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, most parameter meanings, output format, and differentiation from siblings. While concise, it doesn't provide enough context for an agent to use the tool effectively without additional assumptions.
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. It only adds meaning for 'reference_id' ('for CareNow loan ID lookups'), leaving the other three parameters (paymentMethodId, customerId, limit) undocumented. The description does not explain what these parameters do, their formats, or how they interact, failing to adequately cover the parameter semantics beyond the schema.
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 clearly states the tool's purpose: 'List payment requests with optional filters.' It specifies the verb ('List') and resource ('payment requests'), and distinguishes it from siblings like 'xendit_get_payment_request' (singular) by implying a bulk retrieval. However, it doesn't explicitly differentiate from other list tools (e.g., 'xendit_list_invoices'), so it's not a perfect 5.
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 provides some usage guidance: 'Use reference_id for CareNow loan ID lookups.' This gives a specific use case, but it doesn't explain when to use this tool versus alternatives like 'xendit_list_transactions' or 'xendit_get_payment_request', nor does it mention prerequisites or exclusions. The guidance is implied rather than explicit.
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 mentions the tool is 'Critical for Wrong VA investigations,' hinting at a read-only, diagnostic use case, but doesn't explicitly state whether it's a read operation, what permissions are required, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 concise and front-loaded, with the core purpose stated first in a single sentence. The second sentence adds contextual value without redundancy. However, it could be slightly more structured by explicitly separating usage guidelines, but overall, it's efficient with minimal waste.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but lacks depth. It covers the basic purpose and hints at usage, but doesn't fully address behavioral aspects like error cases or response details, which are important for a tool with no structured output or annotations. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'vaId' documented as 'Xendit fixed VA ID.' The description adds minimal semantic context by reinforcing the parameter's purpose ('by Xendit VA ID'), but doesn't provide additional details like format examples or constraints beyond what the schema already covers. This meets the baseline for high 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 clearly states the tool's purpose: 'Get fixed virtual account details by Xendit VA ID.' It specifies the verb ('Get'), resource ('fixed virtual account details'), and key identifier ('Xendit VA ID'). However, it doesn't explicitly differentiate from sibling tools like 'xendit_get_va_payment' or 'xendit_get_transaction', which might also retrieve VA-related information, so it doesn't reach the highest score.
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 provides some usage context with 'Critical for Wrong VA investigations,' which implies this tool is used in error-checking scenarios. However, it doesn't offer explicit guidance on when to use this tool versus alternatives (e.g., compared to 'xendit_get_va_payment' or other sibling tools), nor does it specify prerequisites or exclusions, leaving usage somewhat implied rather than fully defined.
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. It states it's a 'Get' operation, implying read-only behavior, but doesn't disclose other traits like authentication needs, rate limits, error handling, or what details are returned. The API context note adds some value but lacks operational specifics.
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 concise with two sentences: the first states the purpose, and the second adds API context. It's front-loaded with the core function, though the second sentence could be more directly actionable. No wasted words, but slight room for improvement in structure.
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?
Given 1 parameter with full schema coverage and no output schema, the description is adequate but minimal. It covers the tool's purpose and API context but lacks details on return values, error cases, or behavioral traits. For a simple read tool, it's passable but could be more informative to compensate for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'paymentRequestId' fully documented in the schema. The description adds minimal value beyond the schema by reinforcing the ID format ('pr-...') and context, but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema handles most documentation.
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 clearly states the verb ('Get') and resource ('payment request details'), specifying it retrieves details by Xendit payment_request ID. It distinguishes from siblings by focusing on payment requests rather than balances, disbursements, invoices, etc., though it doesn't explicitly contrast with 'xendit_list_payment_requests'.
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 context by mentioning the new Payments API replacing legacy flows, suggesting this tool is for the updated system. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'xendit_list_payment_requests' or other get tools, nor does it specify prerequisites or exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the lookup action but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or response format. This leaves significant gaps for an agent to understand how to invoke and interpret results safely and effectively.
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, efficient sentence that front-loads the core action ('Look up a VA payment') and includes essential context about the parameter. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
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 the lack of annotations and output schema, the description is incomplete. It covers the basic purpose and parameter context but omits behavioral details (e.g., authentication, errors) and return value information. For a tool that likely involves sensitive payment data, this leaves the agent under-informed about critical operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'paymentId' documented as 'VA payment_id'. The description adds context by specifying it's 'the ID returned in the VA paid callback', which clarifies the source and purpose of the ID. This aligns with the baseline score of 3, as the schema already does the heavy lifting, and the description provides modest additional meaning.
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 clearly states the verb ('Look up') and resource ('a VA payment'), specifying it's for Virtual Account payments. However, it doesn't explicitly differentiate from sibling tools like 'xendit_get_transaction' or 'xendit_get_payment_request', which might also retrieve payment information but for different payment methods or contexts.
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 by mentioning 'payment_id (the ID returned in the VA paid callback)', suggesting it's for retrieving specific VA payments after a callback event. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'xendit_get_transaction' or 'xendit_list_transactions', leaving some ambiguity about context and exclusions.
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 burden. It mentions the return type ('Returns array of matching disbursements'), which is helpful, but lacks details on error handling, rate limits, authentication requirements, or what happens if no matches are found. For a lookup tool with zero annotation coverage, this leaves significant behavioral gaps.
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 two concise sentences with zero waste. The first sentence states the purpose and key parameter, while the second specifies the return value. It's front-loaded and efficiently communicates essential information without redundancy.
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?
Given no annotations, no output schema, and a simple single-parameter input schema, the description covers basic purpose and return type but lacks details on error cases, pagination, or example usage. It's minimally adequate for a lookup tool but could be more complete to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'externalId' well-documented in the schema. The description adds minimal value by noting it's 'usually CareNow reference', providing slight contextual meaning beyond the schema's 'external_id used when creating the disbursement'. Baseline 3 is appropriate as the schema does most of the work.
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 clearly states the tool's purpose: 'Look up disbursements by your external_id' specifies the verb (look up) and resource (disbursements). It distinguishes from sibling 'xendit_get_disbursement' by focusing on external_id lookup rather than general retrieval, though the distinction could be more explicit.
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 context by mentioning 'external_id (usually CareNow reference)', suggesting it's for retrieving disbursements created with a specific external identifier. However, it doesn't explicitly state when to use this versus alternatives like 'xendit_get_disbursement' or other sibling tools, leaving some ambiguity.
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 mentions filtering capabilities and investigation use cases, but lacks critical details: it doesn't specify if this is a read-only operation, whether it requires authentication, any rate limits, pagination behavior (beyond the 'limit' parameter), or what the output format looks like. For a list tool with 8 parameters and no annotations, this is a significant gap in transparency.
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 appropriately sized with three sentences that are front-loaded: the first states the purpose, the second provides usage context, and the third highlights a key parameter. There's no wasted text, and each sentence adds distinct value. It could be slightly more structured by explicitly separating purpose from guidelines, but it's efficient overall.
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?
Given the complexity (8 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, usage guidelines, and parameter emphasis adequately, but lacks behavioral details like safety profile, output format, or error handling. For a list tool with rich filtering options, more context on result behavior (e.g., pagination, default sorting) would improve completeness, but it meets minimum viable standards.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, providing good documentation for most parameters. The description adds value by emphasizing 'reference_id' as a key filter for finding specific transactions and linking it to 'CareNow loan ID' as an example, which clarifies semantics beyond the schema's generic description. However, it doesn't address parameters like 'currency' or provide additional context for 'createdGte'/'createdLte' beyond what the schema states. Baseline 3 is appropriate given the high 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 clearly states the tool's purpose with the verb 'List' and resource 'transactions', specifying the types included (payments, disbursements, fees, refunds, adjustments). It distinguishes itself from sibling tools like 'xendit_get_transaction' by indicating it's for listing multiple transactions rather than retrieving a single one. However, it doesn't explicitly contrast with other list tools like 'xendit_list_invoices' or 'xendit_list_refunds' beyond the transaction 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 provides clear context for when to use this tool: 'Core tool for payment discrepancy and wrong VA investigations' and 'Filter by reference_id to find a specific transaction.' This gives practical scenarios and a specific use case. It doesn't explicitly state when not to use it or name alternatives among siblings, but the context strongly implies it's for broad transaction listing versus more specific retrieval tools.
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?
With no annotations provided, the description carries full burden but only states it 'Returns available balance by account type.' It doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, whether this is a read-only operation, or what format the return value takes. This is inadequate for a financial API tool with zero annotation coverage.
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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides essential return value context. No wasted words, and the most important information is front-loaded.
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?
For a balance-checking tool with 2 parameters and no output schema, the description is minimally complete about what it does but lacks crucial context about authentication, error handling, and return format. The absence of annotations and output schema means the description should compensate more than it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'account type (CASH, HOLDING, TAX)' which aligns with the accountType parameter's enum values, but doesn't explain what these account types mean or add meaning beyond the 100% schema coverage. With complete schema documentation, the baseline is 3 even without additional parameter semantics in the description.
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 specific action ('Get Xendit account balance') and resource ('account balance'), distinguishing it from sibling tools that focus on disbursements, invoices, payments, refunds, and transactions rather than account balances. It provides the exact verb+resource combination needed.
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 context by mentioning account types (CASH, HOLDING, TAX), suggesting this tool is for checking different balance categories. However, it doesn't explicitly state when to use this vs. alternatives like transaction listings or provide any exclusions. The guidance is implied rather than explicit.
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 burden for behavioral disclosure. The description mentions filtering capabilities but doesn't disclose important behavioral traits like whether this is a read-only operation, pagination behavior, rate limits, authentication requirements, or what the return format looks like. For a list tool with 6 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves.
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 perfectly concise with just two sentences. The first sentence states the core functionality, and the second provides specific usage guidance. Every word earns its place, and the information is front-loaded with the primary purpose stated first.
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?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description provides adequate but incomplete context. It covers the purpose and gives specific usage guidance but lacks behavioral transparency about how the tool operates, what it returns, and limitations. For a list tool with filtering capabilities, more complete context would include information about pagination, response format, and operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (high), so the baseline is 3 even with minimal parameter info in the description. The description adds some value by explaining that external_id filtering is 'usually the CareNow loan ID' and mentioning the 'Wrong VA / Payment Discrepancy' use case, which provides context beyond the schema. However, it doesn't add significant semantic information for most parameters.
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 clearly states the verb ('List') and resource ('invoices') with optional filtering, which is specific and actionable. However, it doesn't explicitly distinguish this tool from sibling tools like 'xendit_get_invoice' (singular) or 'xendit_list_transactions', leaving some ambiguity about when to use this versus other list tools.
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 provides clear context for when to use this tool: 'For Wrong VA / Payment Discrepancy, filter by external_id (usually the CareNow loan ID).' This gives a specific use case and guidance on parameter usage. However, it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools, which would be needed for a perfect score.
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. It mentions the tool is for 'status lookups' (implying read-only), but does not disclose behavioral traits such as authentication needs, rate limits, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps.
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 two concise sentences with zero waste, front-loaded with the core purpose. Every word earns its place, making it easy to parse quickly.
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?
Given no annotations and no output schema, the description is minimal but covers the basic purpose and usage. However, for a tool that likely returns status data (implied by 'status lookups'), more detail on response structure or error cases would improve completeness, leaving it at an adequate but not fully helpful level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'disbursementId' parameter. The description adds no additional meaning beyond what the schema provides (e.g., format examples or constraints), meeting the baseline for high schema coverage.
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 specific action ('Get disbursement status') and resource ('by Xendit disbursement ID'), distinguishing it from siblings like 'xendit_get_disbursement_by_external_id' which uses a different identifier. The mention of 'refund/payout status lookups' further clarifies the use case.
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 provides clear context for when to use this tool ('for refund/payout status lookups'), but does not explicitly state when not to use it or name alternatives like 'xendit_get_disbursement_by_external_id' for external ID lookups. The guidance is helpful but lacks explicit exclusions.
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

Copy to your README.md:

[![xendit-mcp MCP server](https://glama.ai/mcp/servers/indratjhai/xendit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/indratjhai/xendit-mcp)

Score Badge

Copy to your README.md:

[![xendit-mcp MCP server](https://glama.ai/mcp/servers/indratjhai/xendit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/indratjhai/xendit-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/indratjhai/xendit-mcp'

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