TropiPay MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools target distinct resources (balance, profile, accounts, movements, payment cards, beneficiaries), but test_connection overlaps with get_default_account_balance by also retrieving the balance, and the three create_*_beneficiary tools are very similar in function though differentiated by beneficiary type. Agents may struggle to pick between these without careful reading.
Naming Consistency4/5
Tools generally follow a verb_noun pattern in snake_case (get_profile_data, list_deposit_accounts), but there is inconsistency with compound nouns: 'list_paymentcards' and 'create_paymentcard' lack the expected underscore between 'payment' and 'card', unlike 'get_default_account_balance' and 'list_deposit_accounts'. This is a minor deviation from an otherwise predictable pattern.
Tool Count5/5
With 11 tools, the set is well-sized for a payment server covering balance, profile, accounts, movements, payment cards, and beneficiaries. Each tool addresses a distinct need without excessive granularity or bloat.
Completeness3/5
The read side is solid (profile, balance, accounts, movements, cards, beneficiaries) and creation is supported for payment cards and all beneficiary types. However, there are no update/delete operations for cards or beneficiaries, nor any transfer/payment initiation tools, leaving clear gaps in the expected lifecycle for a payment platform.
Average 3.7/5 across 11 of 11 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?
There are no annotations, and the description only says 'Get list', implying a read operation but not explicitly stating any behavioral traits such as read-only nature, pagination, or authentication requirements. The description adds little beyond what the name already conveys.
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 extraneous information. It is front-loaded and to the point.
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 zero-parameter tool with no output schema, the description provides a basic understanding of what it returns. However, it lacks details about the return structure or how it differs from similar sibling tools like list_deposit_accounts, making it somewhat incomplete.
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?
The tool has no parameters, so the schema description coverage is 100%. The baseline for zero-parameter tools is 4, and the description does not need to explain any parameter behavior.
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 that it retrieves a list of TropiPay accounts associated with the user, using a specific verb and resource. It does not explicitly differentiate from sibling tools like list_deposit_accounts, but the name and scope make the purpose apparent.
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, nor any exclusions or conditions. An agent cannot determine if this is the right tool for a given use case besides the name.
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. It states a create operation but does not disclose response format, idempotency, duplicate handling, authorization requirements, or any side effects beyond creation. This is a significant gap for a mutation.
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 concise: a single sentence, a required-field list, and a code example. Every element is purposeful, and the front-loaded purpose makes it easy to scan.
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 tool has 11 parameters and no output schema, yet the description only provides required fields and an example. It omits the return value, possible errors, and any special behavior, leaving an agent uncertain about the outcome after invocation.
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?
The schema already has 100% parameter coverage. The description adds value with a concrete JSON example, providing sample values for accountNumber, currency, and network, which clarifies expected formats. It also lists required fields, though these are already in the 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 'Create a new crypto wallet beneficiary using TropiPay API,' with a specific verb and resource. The 'crypto wallet' qualifier distinguishes it from sibling tools like create_external_beneficiary and create_internal_beneficiary.
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 explicit guidance on when to use this tool versus the sibling beneficiary tools. The description does not mention alternatives or exclusions, only lists required parameters, which is not usage guidance.
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, the description carries full burden for behavioral disclosure. It implies a read-only operation via 'Get', but does not explicitly state read-only semantics, authentication requirements, or what exactly is returned beyond 'profile information'. No additional behavioral context is provided.
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, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently.
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 simple tool with no parameters and no output schema, the description is minimally adequate but lacks details about the return payload (what exact profile fields are included) and any prerequisites. It would benefit from stating that it retrieves the authenticated user's own profile or clarifying the data shape.
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?
The tool has zero parameters, and schema coverage is 100% (empty schema). Baseline for 0 params is 4. The description adds no parameter details, but none are needed.
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 verb ('Get') and resource ('user profile information from TropiPay account'), which is distinct from sibling tools that deal with balances, accounts, payment cards, beneficiaries, and movements. It leaves no ambiguity about what the tool does.
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. The sibling tools are listed, but there is no explanation of selection criteria or exclusionary context.
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 description carries full burden. It provides a detailed response structure and clarifies that accounts can be internal or external, but does not explicitly state whether the operation is read-only, requires authentication, or has any side effects. The 'Get list' verb implies safety, but transparency is limited.
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 well-structured with a clear summary, a helpful tip, and a bulleted response structure. It is longer than minimal but each section adds value given there is no output schema.
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?
Despite having no output schema, the description fully compensates by providing a comprehensive response structure with all field meanings and types. It also explains the internal/external distinction, making it complete for a list operation.
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?
The tool has zero parameters, so schema coverage is 100%. The description does not need to explain parameters, and the baseline for 0 params is 4.
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 'Get list of deposit accounts (a.k.a beneficiaries)' with a specific verb and resource. It distinguishes from siblings by focusing on deposit accounts/beneficiaries, but does not explicitly contrast with similar sibling tools like get_accounts_list.
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 explicit guidance on when to use this tool versus alternatives. It provides a tip about terminology but does not mention when to choose this over list_paymentcards or get_accounts_list, nor any 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 of behavioral disclosure. It only states that it creates a beneficiary and lists required fields/example. It does not disclose side effects, potential errors, permissions required, or behavior on success/failure. This is a significant gap for a 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?
The description is concise and well-structured: one sentence stating purpose, a bolded required-fields line, and a compact JSON example. Every element earns its place with no unnecessary verbosity.
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?
Despite having 15 parameters and no output schema, the description is minimal. It does not explain the expected response, how to handle errors, or how parameters like email and searchValue interrelate beyond the example. The example partially compensates, but overall completeness is lacking 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?
The input schema has 100% coverage with descriptions for all parameters. The description adds value by highlighting the required parameters and presenting a concrete example showing the relationship between searchValue, searchBy, and alias. While it repeats some schema info, the example clarifies parameter usage beyond the schema alone.
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 'Create a new internal TropiPay beneficiary' with a specific verb and resource. The word 'internal' distinguishes it from sibling tools like create_external_beneficiary and create_crypto_beneficiary, making the purpose unambiguous.
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 through the tool name and the word 'internal', but it does not explicitly state when to use this tool versus the external or crypto beneficiary alternatives. It provides required fields and an example, which gives some context, but there is no direct guideline on when not to use it.
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, the description carries full responsibility for behavioral disclosure. It discloses that user interaction is required and that payment card info will be returned, but it contains internal contradictions: it says 'DO NOT generate or assume default values for required fields' yet later says 'reasonId - set 21 if not provided' and 'serviceDate - will be set today date by the mcp if not provided.' These contradictions mislead the agent about whether defaults are allowed. The description also lists some fields as optional while the schema marks them REQUIRED (e.g., favorite, singleUse), creating further confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive. It uses bold sections, emojis, and repeated REQUIRED warnings. The 'IMPORTANT' section restates the 'DO NOT' rules later, and the optional field list duplicates schema properties. While it has a clear sectioned structure, it could be significantly shortened to essential guidance without losing 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?
The description covers the overall process (ask user → collect info → create → return info), which is helpful given 15 parameters and no output schema. However, it lacks specifics on response format or error handling, and the contradictions (required vs optional, default generation) leave gaps in the agent's understanding of correct invocation. It is not as complete as needed for a tool with zero 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?
Input schema coverage is 100%, so the schema already provides detailed parameter descriptions (e.g., amount in cents, currency allowed values). The description adds value by grouping parameters into required and optional lists and emphasizing user collection. However, it introduces contradictions about which fields are required, and it doesn't clarify parameter interactions beyond what the schema already states.
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 'Create a new payment card (payment link) using TropiPay API.' This is a specific verb+resource combination that distinguishes it from sibling tools like create_external_beneficiary. The name and description align, and the purpose is unambiguous.
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?
The description provides explicit usage guidance: 'NEVER create payment cards without first asking the user for required information' and lists the exact fields to collect (amount, currency, concept, description). It also includes a step-by-step process flow, clarifying when to ask for optional fields and when to create. This exceeds baseline guidance.
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 bears full responsibility for disclosing behavioral traits. The verb 'Get' implies a read-only operation, but the description does not state whether there are side effects, authentication requirements, rate limits, or what happens if no default account is selected. This is minimal behavioral disclosure beyond the name.
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 immediate verb ('Get') and no filler. It is concise, front-loaded, and every word contributes to the meaning. It is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description is sufficiently informative. It states the operation and the target resource. However, it could be slightly more complete by mentioning that the balance is in the default account's currency or that it may return null if no default exists, but given the simplicity, it is largely complete.
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?
The tool has zero parameters, and the schema is empty, so parameter coverage is complete. The description adds meaning by specifying that the balance is for the 'current selected as default account', which clarifies what the no-argument call actually returns. This goes beyond the empty schema, so a baseline of 4 is appropriate.
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 tool's function: 'Get the current selected as default account balance from TropiPay'. It uses a specific verb 'Get' and identifies the resource ('default account balance from TropiPay'), which distinguishes it from sibling tools like get_accounts_list (which lists accounts) or get_movement_list (which lists movements).
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention scenarios, exclusions, or compare with sibling tools. A user must infer from the name alone that this is for checking the balance of the default account, but no explicit usage context is 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?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only states the action and gives an example, without mentioning side effects, response format, permissions, or any post-creation conditions. This is insufficient for a create operation with no output schema.
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 concise and well-structured: a single action sentence, a bolded required list, and a code example. Every element adds value, and the purpose is front-loaded. No wasted words or fluff.
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 provides the essential purpose, required fields, and an example, which is adequate for constructing a valid request. However, with no output schema, it fails to explain what the response or result looks like, and it omits any post-conditions or caveats. Given the tool's complexity (26 parameters), this is a minor but notable gap.
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?
The schema covers all 26 parameters with descriptions, but the tool description adds a required-fields summary including the OR condition between countryDestinationId and countryISO, which is not in the schema's required array. The example JSON also demonstrates a realistic parameter combination, providing practical guidance beyond the schema's per-field descriptions.
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 ('Create') and resource ('external bank account beneficiary'), clearly distinguishing it from sibling tools like create_internal_beneficiary and create_crypto_beneficiary. The addition of 'using TropiPay API' is redundant but does not introduce ambiguity.
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 clearly indicates when to use this tool by specifying 'external bank account beneficiary' and listing required fields, which provides context for selection. However, it does not explicitly mention alternatives or exclusions, though the sibling tool names are implied by the 'external' qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 details the response structure extensively, including field meanings, type classifications, and state codes, which helps the agent interpret results. It also mentions authorization scope. It does not discuss rate limits or error conditions, but for a straightforward read operation, this is sufficient.
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 well-structured with bullet points and clear sections, making it easy to scan. It is somewhat lengthy due to the detailed response field explanations, but this is justified because there is no output schema to rely on. The included tip is an extra but may be useful. Every sentence serves a purpose, though it could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description compensates by providing a comprehensive breakdown of the response structure, including nested fields, enums, and behaviors. It also states the required scope. The lack of alternative tool references and parameter behavior beyond schema is a minor gap, but overall the description is complete for a read-only list operation.
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 covers both parameters (limit, offset) with descriptions, so schema coverage is 100%. The tool description does not add additional meaning beyond the schema's own parameter descriptions; it only mentions the response fields. Since the schema already handles parameter semantics, a baseline of 3 is appropriate.
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 'Get list of account movements/transactions', identifying both the action (get) and the resource (movements/transactions). This distinguishes it from sibling tools like get_accounts_list or list_paymentcards, which target different resources. The scope requirement adds precision.
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: when you need to retrieve account movements, this is the tool. It also mentions the required scope (ALLOW_GET_MOVEMENT_LIST), which is a prerequisite. However, it does not explicitly compare with alternatives or state when not to use it, so guidance is only 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 must fully disclose behavior. It mentions retrieving the default account balance as part of the test, but does not state whether this is a read-only operation, what happens on authentication failure, or the expected return format. This leaves important behavioral aspects undisclosed.
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, concise sentence that front-loads the primary purpose ('test the connection') and clearly explains the verification method. No unnecessary words or repetition.
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 tool is simple with no parameters and no output schema. The description conveys the core purpose but does not explain the return value, error handling, or what 'selected default account' specifically refers to. This is a moderate gap for a connectivity test, but the description is minimally sufficient for basic understanding.
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?
The tool has zero parameters, so there is nothing to explain. According to the rubric, a baseline of 4 is appropriate for tools with no parameters, and the description does not need to add parameter information.
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 tool's function: testing the connection to the TropiPay API and verifying authentication. It uses specific verbs ('test', 'verify') and identifies the resource (API, authentication). It distinguishes itself from sibling tools like get_default_account_balance by focusing on connectivity rather than just returning a balance.
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 implies this tool is used when you need to test the connection or verify authentication status. It provides clear context for when to use it, but does not explicitly mention alternatives or exclusion scenarios (e.g., when to use get_default_account_balance instead). Thus, it has clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explicitly states that only paymentcards created by the user are returned, which is a meaningful behavioral trait. However, it omits details about read-only safety, pagination, or error behavior, though these are less critical for a simple list 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?
The description is a single, direct sentence that briefly states the tool's purpose without repetition or extraneous detail. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with no output schema, the description adequately covers what the tool does and the filtering criterion (created by the user). It could mention return format or limits, but such details are not essential given the tool's simplicity.
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?
The input schema is empty with zero parameters, and the description implicitly confirms no inputs are needed. Per the rubric, zero-parameter tools receive a baseline of 4, and there is no additional parameter semantics to explain.
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 tool retrieves a list of paymentcards using the verb 'Get' and the resource 'paymentcards', adding 'paylinks' and 'created by the user' for ownership scope. This distinguishes it from sibling tools like create_paymentcard and other account 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 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 such as list_deposit_accounts or get_accounts_list. It does not specify any exclusions or preferred contexts, leaving usage decisions to the agent.
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:

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

Score Badge

Copy to your README.md:

[![tropipay-mcp-server MCP server](https://glama.ai/mcp/servers/yosle/tropipay-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/yosle/tropipay-mcp-server)

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/yosle/tropipay-mcp-server'

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