A
license-
qualityB
maintenanceAccept crypto payments from AI agents: create an invoice in one call and get a hosted checkout link (USDC/USDT on Celo, Base, Arbitrum, Polygon, BSC). No API key, instant self-custody settlement.
Last updated
MIT
Papaya Pay Any Bill (US)
Ownership verified
Server Details
Pay any US bill in a snap, right from your chat — utilities, medical, rent, parking tickets & more.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.3/5.0
Tool DescriptionsA
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.6/5.
Server CoherenceA
Disambiguation5/5
Each tool has a distinct purpose in the bill payment workflow: analyze_bill initializes, check_payment_method optionally checks card status, confirm_payment_intent finalizes, fetch_bill_status checks status, get_new_auth_token handles auth refresh, request_bill_cancellation cancels. No ambiguity.
Naming Consistency5/5
All tool names 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. Predictable and clear.
Tool Count5/5
6 tools is well-scoped for a bill payment service: it covers the main workflow (create, pay, check status, cancel) plus auth token management. Not excessive or sparse.
Completeness5/5
The tool surface covers the full bill payment lifecycle: analyzing a bill, checking payment method, confirming payment, fetching status, and cancellation. Auth token refresh handles edge cases. No obvious gaps for the intended domain.
Available Tools
6 toolsanalyze_billAnalyze BillAInspect
Read 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| bill_description | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false. The description explains it creates a bill for payment (write operation), returns payment_link and fees. It adds context like fee behavior and link usage, beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and detailed but well-structured. It is front-loaded with the purpose but contains some redundancy. Every sentence adds value, but could be more 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?
Given the complexity (nested objects, many params), the description is thorough, covering data capture, payment amount, fee handling, and return values. Output schema exists, so return value explanation is adequate.
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 high (most parameters have descriptions). The description repeats some schema details but adds context (e.g., importance of remit-to address). Baseline 3, minor added value.
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 reads a bill and creates it for payment, specifying it as the first step. It details what to capture (addresses, identifiers). It does not explicitly differentiate from siblings, but the purpose is specific and actionable.
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 detailed usage guidance: capture all identifiers, ask user for amount, include remit-to address, handle missing data. It does not explicitly state when not to use or alternatives, but covers the context well.
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 MethodARead-onlyInspect
Optional: 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| check_input | Yes | Identifiers to look up whether a card has been set on a bill yet. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is consistent and adds specifics about return values (card details or PENDING). No contradictions; it could mention idempotency but fine given readOnlyHint.
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?
Well-structured with clear main description and Args section. Slightly lengthy but no wasted words.
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?
The description fully covers the tool's purpose, usage, and return info. With an output schema available, it's sufficiently complete 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%, so the parameter is well-documented in schema. The description's Args section adds little beyond restating the purpose; no new semantic details.
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 it checks whether the user has finished the secure form and a card is on the bill, and specifies return values (last 4 digits/name or PENDING). It distinguishes from sibling tools like confirm_payment_intent by noting the normal path.
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?
Explicitly tells when to use (e.g., user asks) and notes it's not a required step, contrasting with the normal path (analyze_bill → user fills form → confirm_payment_intent).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_payment_intentConfirm PaymentADestructiveInspect
Final 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| confirm_input | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, indicating mutation. The description adds context like 'Final step' and prerequisites, but does not elaborate on irreversible consequences or side effects of wrong usage. It mentions failure conditions (missing extra_infos) but lacks deeper behavioral detail. Still adds value beyond annotations.
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 relatively concise, using a short paragraph and a bulleted 'Args' block. It front-loads the core purpose and conditions. However, it could be more structured, e.g., separating preconditions from parameter behavior. The 'Args' section is minimal but effective.
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 complexity of a nested input object with many required fields, the description covers key aspects: preconditions, dependencies on other tools (analyze_bill), and the need for user confirmation. It does not mention the output schema, but since one exists, the agent can infer return values. Some nuance about destructive nature is missing, but overall adequate.
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 description summarizes confirm_input as containing 'identifiers, the amount to pay, contact info and any extra info', adding context beyond the schema's property types. Although schema descriptions for nested fields are comprehensive (0% coverage at tool level), the description's summary helps the agent understand the high-level structure, earning a score above baseline 3.
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 identifies the tool as 'Final step: submit the bill for payment' and distinguishes it from siblings like analyze_bill (analysis) and check_payment_method (checking method). The verb 'submit' and resource 'payment' are specific, and the context of being final step differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit conditions are given: must have set a card, must confirm amount with user and provide quote, supply extra_infos if needed, only use entered fields for correction, and pass refresh token. The instruction 'do not call this until you have asked' and warning that submission will fail if extra info is missing provide clear when-to-use and when-not-to-use guidance.
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 StatusARead-onlyInspect
Check 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| bill_status_input | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable behavioral context: it explains that 'statusEvaluatedDescription' is only present for declined/failed payments and should be treated as a reason for failure. This goes beyond the annotation's readonly flag by disclosing conditional output behavior.
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 efficiently structured with an opening statement, a behavioral note, and clear Args/Returns sections. It avoids unnecessary text, though the conditional explanation could be more 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 simple fetch tool, the description adequately covers the main behavior and conditional output. However, it lacks explicit mention of default status values or pagination, and the input parameter is not fully unpacked. Given the presence of an output schema (implied by Returns description), this is mostly complete.
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?
With 0% schema description coverage, the description must compensate for parameter meaning. It only vaguely mentions 'bill_status_input: the bill identifier and auth token' without detailing the nested fields or their formats. The schema itself provides descriptions for 'bill_id' and 'auth_token', but the description adds minimal value beyond aggregation.
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 purpose: 'Check the payment status of a submitted bill.' This specifies a concrete action (check) on a specific resource (payment status of a bill). It distinguishes from sibling tools like 'analyze_bill' or 'confirm_payment_intent' by focusing solely on status retrieval.
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 does not provide any guidance on when to use this tool versus alternatives like 'analyze_bill' or 'check_payment_method'. It implies usage after bill submission but gives no explicit context, prerequisites, or exclusions.
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 TokenAInspect
Get 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| new_token_input | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a new token pair and errors for missing/invalid refresh tokens, which is sufficient. Annotations indicate non-destructive and non-read-only, and the description does not contradict them. Minor omission: no mention of whether old tokens are invalidated.
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, uses two short paragraphs with a clear Args/Returns structure, and contains no filler. Every sentence adds value.
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?
Given the simple tool with one parameter and clear purpose, the description provides all necessary context. The presence of an output schema (though not shown) and explicit return value description complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the single parameter 'new_token_input' contains the user's refresh token, and the schema provides additional detail. Together they fully clarify the parameter's purpose.
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 obtains a fresh auth token in response to authorization failures. The name and title align, and it is distinct from sibling tools which handle billing and payment operations.
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 explicitly instructs to call only on auth failure, not preemptively. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bill_cancellationCancel BillADestructiveInspect
Cancel 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
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| bill_cancel_input | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so destructive nature is known. Description adds that cancellation may be rejected if payment progressed, and to relay errors. This enriches behavioral context beyond annotations.
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?
Very concise: purpose, usage guidance, args, and returns in a few sentences. No fluff, front-loaded core information.
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?
Covers main purpose, usage, return values. Could mention permission requirements or that cancellation may not be reversible, but overall sufficient given tool complexity and annotations.
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 description must compensate. However, it only vaguely mentions 'the bill identifier and auth token' without detailing the nested structure, required fields, or patterns. The schema provides these details but the description adds little value.
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 it cancels a submitted bill to prevent payment, using specific verb 'cancel' and resource 'bill'. It distinguishes from sibling `analyze_bill` by noting it's not for correcting details.
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?
Explicitly says when to use (user wants to stop a bill), what to do if rejection occurs (relay error), and what not to use it for (correcting details, redirecting to `analyze_bill`).
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseBqualityDmaintenancePayment & Transaction Tools that allow AI agents to send, receive, and request paymentsLast updated11252Apache 2.0
- Alicense-qualityCmaintenanceEnables cross-border SMB invoice settlement on USDT/USDC rails with $0 wire fee and same-block settlement, including fee schedule comparison, invoice creation, status tracking, and dispute arbitration via HiveLaw.Last updatedMIT
- Alicense-qualityAmaintenanceGive your AI agent a prepaid card to pay per call for hundreds of paid services — no per-vendor signups or API keys.Last updated32MIT
