Papaya Bill Pay
Server Details
Ready for a new way to bill pay? Pay any bill in a snap, right from a chat with Claude or ChatGPT. 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. Powered by Papaya (papayapay.com).
- 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.
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.
Tool Definition Quality
Average 4.1/5 across 6 of 6 tools scored. Lowest: 3.5/5.
Each tool has a clear, distinct purpose covering the bill payment lifecycle: bill creation, card check, payment confirmation, status check, token refresh, and cancellation. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_bill, confirm_payment_intent). The verbs are imperative and the nouns clearly indicate the target, making the naming predictable.
With 6 tools, the set is well-scoped for a bill payment service. It covers all essential steps without unnecessary redundancy or missing crucial operations.
The tool surface provides end-to-end coverage for bill payment: creating a bill, setting a payment method, confirming payment, checking status, handling authentication errors, and cancellation. No obvious gaps in the core workflow.
Available Tools
6 toolsanalyze_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.
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool reads and creates a bill, returns a payment_link, includes fees, and requires user interaction for the amount. It also warns about consequences of missing remit-to address. While it doesn't detail all side effects, it is comprehensive for a mutation tool.
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 clear paragraphs and front-loads the main purpose. While it is lengthy, the complexity of the tool justifies the detail. Some repetition could be trimmed, but overall it is organized and informative.
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 schema, no annotations, but with output schema), the description covers key aspects: the flow, required user input, and return values (fees, payment_link). It could mention more about return structure but is sufficient for an agent to execute correctly.
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 adds significant meaning beyond the input schema: it explains the critical importance of remit-to address, how to handle payUrl and otherInfo, the need to ask the user for amount_to_pay and user_amount_statement, and reuse of user_id/auth_token. This compensates for the schema's low coverage (0% as indicated in context) and provides an agent with clear instructions.
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: 'Read a bill from the user's description and create it for payment.' It uses a specific verb ('read' and 'create') and resource ('bill'), and positions itself as 'the first step' in a payment flow, distinguishing it from sibling tools that handle later stages like checking payment methods or confirming intents.
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 offers extensive guidance on when and how to use the tool: it must be called before other payment steps, requires asking the user for the amount, and specifies that the remit-to address is critical. It also covers reusing user_id/auth_token for existing users. However, it does not explicitly state when not to use it or compare to siblings for exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_payment_methodAInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| check_input | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: returns last 4 digits and name or PENDING status; mentions it's optional and non-required. Discloses all relevant traits without contradiction.
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 purpose, then usage context, return info, and parameter list. It is slightly lengthy but well-organized; each sentence earns its place.
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 simplicity, the presence of an output schema, and good schema parameter descriptions, the description covers all necessary context: when to use, return values, and invocation. No gaps remain.
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 lists the parameters under 'Args' but provides no new meaning beyond the input schema, which already describes bill_id and user_id as identifiers. Schema coverage is high, so baseline 3 is appropriate; no additional value added.
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 checks whether a card is on the bill, using a specific verb and resource. It distinguishes from siblings by outlining the normal workflow (analyze_bill -> user fills form -> confirm_payment_intent) and labeling this as optional.
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?
Explicitly states when to use: 'only if you need to confirm the card landed (e.g. the user asks)' and when not: 'it is not a required step'. Provides context that the normal path is analyze_bill -> confirm_payment_intent, giving clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_payment_intentAInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| confirm_input | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is a submission step, requires user confirmation and refresh_token, and warns that submission will fail if extra_infos needed. It also specifies not to guess email and to reuse prior tokens. Output schema exists, so return values need not be explained.
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 key instructions and structured with headings, but it is somewhat verbose. Each sentence adds value, but some repetition exists (e.g., mentioning refresh_token in both description and schema). Could be marginally more concise.
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 complexity of payment confirmation, the description covers the full usage flow: prerequisites, required user interaction, error conditions (extra_infos), and correction mechanisms. Schema descriptions are thorough, and output schema exists. No gaps identified.
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?
Despite high schema description coverage, the description adds meaning beyond schema: e.g., 'Use entered_account / entered_provider only to correct a mis-extracted value' and 'Pass the user's current refresh_token...'. It also emphasizes not to invent user_amount_statement and to avoid guessing email.
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', specifying the verb (submit) and resource (bill for payment). It distinguishes from siblings like analyze_bill and check_payment_method by being the final action after card setup and amount confirmation.
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?
Explicitly instructs when to use: after card set, after confirming amount with user, and quotes user confirmation in user_amount_statement. Also warns not to call until asked, and provides guidance on extra_infos, entered_account/entered_provider for corrections, and refresh_token usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_bill_statusAInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| bill_status_input | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, description fully bears transparency burden. It explains that the tool is read-only, describes the meaning of each output field, and explains that statusEvaluatedDescription only appears on failure. It does not mention error handling or token expiration, but is sufficient for expected use.
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?
Description is well-structured with overview, output behavior explanation, and Args/Returns sections. The explanation of statusEvaluatedDescription is useful but slightly lengthy. Could be trimmed without losing clarity.
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 status check tool, description covers main behavior: input binding, return fields, and special case for failures. It lacks error scenarios but is acceptable given the tool's simplicity.
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?
Input schema already provides detailed descriptions for bill_id (pattern, source) and auth_token (pattern, source). The description's 'Args' line adds minimal summary, not new insight. With schema coverage 0%, description should add more value but fails to elaborate on input structure beyond what's in schema.
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 it checks payment status of a submitted bill. Distinct from siblings like analyze_bill, check_payment_method, etc., which have different purposes.
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?
Implies usage after bill submission to check status, but does not explicitly state when to use or when to avoid. No direct contrast with siblings, but the description of the statusEvaluatedDescription field provides guidance on interpreting results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_new_auth_tokenAInspect
Get a fresh auth token when a call fails with an authorization error.
Args:
new_token_input: contains the user's refresh token
| Name | Required | Description | Default |
|---|---|---|---|
| new_token_input | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool gets a fresh auth token but does not disclose behavioral aspects such as whether the old token is invalidated, rate limits, or if it requires specific permissions. The description is minimal.
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 extremely concise: one sentence for the purpose and one line for the parameter. It is front-loaded with the main action and trigger condition, with no unnecessary words.
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?
An output schema exists, so return values need not be described. The description covers the purpose and one input, but does not explain how the tool behaves in edge cases or any side effects. It is minimally complete for a simple token refresh operation.
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 adds the context that 'new_token_input contains the user's refresh token', but the input schema already provides a detailed description for the 'refresh_token' parameter. With 0% schema description coverage (likely a metric issue), the description provides marginal additional value beyond the schema.
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 'Get a fresh auth token' which gives a specific verb and resource, and it specifies the trigger condition 'when a call fails with an authorization error'. This distinguishes it from sibling tools that are billing operations, though not explicitly.
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 explicitly says 'when a call fails with an authorization error', providing a clear context for when to use this tool. It does not mention when not to use or alternatives, but the context is sufficient given the sibling tools are all billing-related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bill_cancellationAInspect
Cancel a bill.
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It states 'Cancel a bill' but does not describe side effects (e.g., whether cancellation is irreversible, required permissions, or if it triggers further actions). The return value is mentioned but not the impact on the bill's state.
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 extremely concise: three short sentences covering purpose, inputs, and outputs. Every word earns its place with 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?
Given the siblings (e.g., fetch_bill_status, get_new_auth_token) and the need for an auth token, the description could mention that a valid token is required and how to obtain it. Output schema is not shown but described. The description is adequate but could be more helpful.
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 says 'the bill identifier and auth token' for the input parameter, which is already detailed in the schema's property descriptions. Since schema coverage is effectively high (nested properties have descriptions), the description adds minimal new information. 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 states 'Cancel a bill.' which is a specific verb and resource. It clearly distinguishes from siblings like fetch_bill_status, check_payment_method, and analyze_bill, which perform different actions. No ambiguity.
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 gives minimal guidance on when to use this tool. It implies cancellation, but does not specify prerequisites (e.g., need an auth token) or when not to use (e.g., if bill is already cancelled). No explicit comparison to alternatives like fetch_bill_status or get_new_auth_token.
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!