Ready for a new way to bill pay? Pay any US bill in a snap, right from your AI assistant. Describe or snap a photo of your bill (electric, water, gas, internet, phone, medical, credit card, rent, parking tickets, traffic violations and more) and Papaya reads it, then hands you a secure link to pay by card. Fast, secure, and no juggling twelve logins, with full or partial payments and status updates. Available in the US only. Powered by Papaya (papayapay.com).
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 6 of 6 tools scored.
Each tool has a distinct role in the payment workflow: analyzing/creating a bill, checking card status, confirming payment, fetching payment status, refreshing auth tokens, and cancelling a bill. There is no meaningful overlap between these operations.
All six tools follow a consistent verb_noun snake_case pattern (analyze_bill, check_payment_method, confirm_payment_intent, fetch_bill_status, get_new_auth_token, request_bill_cancellation). The naming is uniform and predictable.
Six tools is well-scoped for a bill payment server, covering the full lifecycle without unnecessary redundancy or overwhelming complexity. Each tool serves a clear purpose in the workflow.
The tools cover the complete bill payment lifecycle: creating/analyzing a bill, verifying payment method, confirming payment, checking status, cancelling, and handling auth token refresh. No obvious gaps exist for the stated purpose.
analyze_billAnalyze BillAInspectRead a bill from the user's description and create it for payment. This is the
first step. Capture every address and identifier on the bill (remit-to address,
account/invoice number, any code or pin) - missing details can delay or fail
the payment. The remit-to address (where payment is sent) is especially important:
it is what identifies the correct biller, and a wrong or missing one can match the
bill to the wrong biller and cause a failed or delayed payment. Always include it. If
the bill does not show a remit-to address, research the biller's official remit-to /
payment address online and use that rather than omitting it. For the same reason,
capture the bill's online-payment URL in payUrl and any payment phone number in
otherInfo whenever the bill shows them - these strongly identify the correct biller.
Always secure a user identifier so the payment can be applied to the right account or
charge: capture the account/customer number in the account field, and any invoice,
ticket, or reference number in otherInfo - capture all that the bill shows, since some
billers need the account number plus another identifier. If the bill shows none, ask
the user for one rather than proceeding without it.
Before calling, ask the user how much they want to pay (the full
balance amountDue, or a partial amount), then pass it as amount_to_pay and quote
what they said in user_amount_statement - both are required (never invent the
amount). If the payment carries a fee, the result includes a fees list - show any
returned fee to the user before continuing. The result also includes a
payment_link: give this link to the user as-is so they can enter their card on the
secure form (the only way to set a payment method). If the user already exists from a
prior bill, pass their user_id and auth_token to reuse the account.
Args:
bill_description: structured bill details, including amountDue, amount_to_pay
and user_amount_statement
Returns:
bill/user identifiers, tokens, provider, amount due, the chosen amount_to_pay,
a payment_link to the secure card form, and any user-facing fees
| Name | Required | Description | Default |
|---|---|---|---|
| bill_description | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the minimal annotations: it mentions the result includes a fees list and a payment_link, instructs to show fees to the user, requires user_amount_statement as proof of user confirmation, and explains reuse of user_id/auth_token. There is no contradiction with readOnlyHint=false since it states the operation creates the bill for payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but dense with actionable instructions that are all relevant to correct invocation. It is front-loaded with the core purpose and then systematically covers identifiers, user confirmation, and result handling. It could benefit from bullet points for readability, but it remains appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the workflow prerequisites (asking the user for amount, quoting their statement), critical outputs (fees list, payment_link) and how to handle them, and reuse of existing user tokens. Since an output schema exists, it need not enumerate every return field; it focuses on the behavioral aspects essential for correct use, making it complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The top-level bill_description parameter has 0% schema description coverage, but the description compensates by naming key subfields (remitAddress, payUrl, account, otherInfo, amount_to_pay, user_amount_statement, user_id, auth_token) and providing operational guidance like researching missing remit-to addresses and quoting the user's stated amount. The nested schema already documents each field, so the description adds valuable context without over-repeating schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read a bill from the user's description and create it for payment' and explicitly labels it 'the first step', making the action and scope clear. This differentiates it from sibling tools like check_payment_method, confirm_payment_intent, fetch_bill_status, and request_bill_cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides strong usage context by stating this is the first step in the payment flow and instructs the agent to ask the user for the amount to pay before calling. However, it does not explicitly name alternative tools or state when not to use it, relying on the 'first step' framing rather than explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_payment_methodCheck Payment MethodAOptional: check whether the user has finished the secure form and a card is on the bill yet. Returns the card's last 4 digits and name when one is set, or a PENDING status when the form has not been completed. Use only if you need to confirm the card landed (e.g. the user asks) - it is not a required step; the normal path is analyze_bill -> user fills the form -> confirm_payment_intent.
Args:
check_input: the user_id and bill_id to look up
| Name | Required | Description | Default |
|---|---|---|---|
| check_input | Yes | Identifiers to look up whether a card has been set on a bill yet. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context beyond that: it describes the possible return states (card last4/name or PENDING) and clarifies this is an optional check, not a required step. This is useful context not present in the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but complete: every sentence adds value—optionality, return behavior, usage guidance, and argument mapping. It is front-loaded with the purpose and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool with an output schema, annotations, and a clear usage note, the description fully covers when and why to use it. It also communicates the normal workflow context without needing to explain return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for bill_id and user_id, so the description's phrase 'the user_id and bill_id to look up' adds little beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'check whether the user has finished the secure form and a card is on the bill yet.' It also explicitly distinguishes its role from sibling tools by referencing the normal path (analyze_bill -> user fills form -> confirm_payment_intent), making its niche unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use only if you need to confirm the card landed (e.g. the user asks) - it is not a required step.' It also names the normal workflow and thus implicitly tells 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.
confirm_payment_intentConfirm PaymentAFinal step: submit the bill for payment, after a card has been set. You must have confirmed the amount with the user first (amount_to_pay may be partial) and quote their confirmation in user_amount_statement - do not call this until you have asked. If analyze_bill reported a need for extra information, supply it in extra_infos or submission will fail. Use entered_account / entered_provider only to correct a mis-extracted value. Pass the user's current refresh_token (from analyze_bill or a prior confirm) - do not guess.
Args:
confirm_input: identifiers, the amount to pay, contact info and any extra info
| Name | Required | Description | Default |
|---|---|---|---|
| confirm_input | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint=true). The description adds valuable behavior context: it requires a card to be set, warns that submission fails without extra info, and instructs not to guess refresh_token. It does not contradict annotations and supplements them with practical failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the primary purpose, followed by critical prerequisites and constraints. Some redundancy (e.g., 'do not call this until you have asked' repeated in the user_amount_statement explanation) could be trimmed, but overall it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object, output schema present), the description covers prerequisites (card set, user confirmation), failure conditions (extra_infos), and special field handling (entered_account/entered_provider, refresh_token). It omits details about return values, but an output schema exists, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides rich descriptions for all parameters (e.g., user_amount_statement, refresh_token, entered_account), so the baseline is 3. The tool description only gives a high-level summary of confirm_input ('identifiers, the amount to pay, contact info and any extra info') without adding new parameter-level meaning, thus meeting but not exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Final step: submit the bill for payment' with a specific verb (submit) and resource (bill), and distinguishes it from siblings by framing it as the final step after bill analysis (referencing analyze_bill). This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for use: 'do not call this until you have asked' about the amount, 'If analyze_bill reported a need for extra information, supply it in extra_infos or submission will fail', and guidance to use correction fields only for mis-extracted values. This clear when-to-use and when-not-to-use guidance exceeds the baseline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_bill_statusFetch Bill StatusACheck the payment status of a submitted bill. Read value for the current status.
statusEvaluatedDescription is only present when the payment was declined or failed,
and then explains why - relay that reason to the user. It is omitted for every other
status, so treat its presence as a decline/failure.
Args:
bill_status_input: the bill identifier and auth token
Returns:
dictionary with keys value, statusDescription, and - only for declined/failed
bills - statusEvaluatedDescription explaining why the payment did not go through
| Name | Required | Description | Default |
|---|---|---|---|
| bill_status_input | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by disclosing that statusEvaluatedDescription is only present for declined or failed bills, and instructs the agent to relay that reason to the user. It also specifies the return dictionary keys, including the optional presence of statusEvaluatedDescription. This adds meaningful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with 'Args' and 'Returns' sections, making it easy to scan. Every sentence provides essential information—purpose, conditional behavior, and return structure—without fluff. It is slightly longer than necessary but remains focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description still usefully explains the return object and the conditional presence of statusEvaluatedDescription. It covers the core functionality and a key edge case (declined/failed). It does not mention error conditions or prerequisites beyond 'submitted bill,' but the overall picture is complete for a read-only status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description calls bill_status_input 'the bill identifier and auth token,' which is a minimal summary. The schema provides detailed descriptions, patterns, and source context for bill_id and auth_token, but schema description coverage is 0% at the top level. The description adds little additional meaning beyond what the schema already conveys, so it just meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check the payment status of a submitted bill.' It clearly distinguishes this from siblings like check_payment_method (which checks available methods) and confirm_payment_intent (which confirms a payment), by focusing on fetching the status of an already-submitted bill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use this tool after a bill has been submitted to obtain its payment status. It also provides guidance on how to interpret and relay the statusEvaluatedDescription for declined/failed bills. It does not explicitly name alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_new_auth_tokenRefresh Auth TokenAInspectGet a fresh auth token when another tool fails with an authorization error. Pass the user's current refresh_token; returns a new auth_token/refresh_token pair to use on the retried call and on later calls. Call this only in response to an auth failure, not preemptively.
Args:
new_token_input: contains the user's refresh token
Returns:
a new auth_token and refresh_token pair, or an error if the refresh token is
missing or invalid
| Name | Required | Description | Default |
|---|---|---|---|
| new_token_input | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only readOnlyHint=false and destructiveHint=false, so the description adds valuable context by explaining that it returns a new token pair and can error if the refresh token is invalid. It doesn't contradict annotations and goes beyond their minimal information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by concise usage instructions and return value expectations. Every sentence earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers when to use the tool, what input to provide, and what to expect as output. The presence of an output schema further helps, but the description itself is complete for this simple auth-refresh tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description explicitly mentions 'Pass the user's current refresh_token' and defines new_token_input as containing the refresh token. This compensates for any missing schema descriptions and gives clear semantic meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 a fresh auth token when another tool fails with an authorization error.' It specifies the verb (get), resource (auth token), and the triggering context, which distinguishes it from sibling billing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this only in response to an auth failure, not preemptively.' It also explains the input needed (refresh_token) and the expected outcome, giving a clear when-to-use scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bill_cancellationCancel BillACancel a submitted bill so it will not be paid. Use when the user wants to stop a bill they submitted; cancellation may be rejected if the payment has already progressed too far - relay any error to the user. Not for correcting bill details: re-run analyze_bill for that.
Args:
bill_cancel_input: the bill identifier and auth token
Returns:
the cancelled bill id and status, or error details
| Name | Required | Description | Default |
|---|---|---|---|
| bill_cancel_input | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, but the description adds context: cancellation may be rejected if payment progressed too far, and errors should be relayed to the user. This goes beyond the annotation to set expectations about outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with clear sections for purpose, usage, args, and returns. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's primary function, failure modes, and output format. Given the output schema exists and annotations provide safety flags, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for bill_id and auth_token, including patterns and origins. The description only says 'bill identifier and auth token', which adds little beyond the schema's internal documentation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool cancels a submitted bill to prevent payment. Distinguishes from analyze_bill by explicitly noting it's not for correcting bill details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case ('when the user wants to stop a bill they submitted'), names an alternative (analyze_bill), and describes a rejection scenario. This is strong guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!