Papaya Pay Any Bill (US)
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.
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 3.9/5 across 6 of 6 tools scored. Lowest: 2.6/5.
Each tool has a distinct and non-overlapping purpose: analyze_bill creates a bill, check_payment_method optionally checks card status, confirm_payment_intent submits payment, fetch_bill_status checks payment status, get_new_auth_token handles auth errors, and request_bill_cancellation cancels a bill. No two tools could be confused.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., analyze_bill, confirm_payment_intent). The verbs are descriptive and the nouns clearly indicate the target object, making the naming predictable and easy to follow.
With 6 tools, the set is well-scoped for a bill payment service. Each tool covers a necessary step in the workflow (create, verify card, confirm, check status, refresh auth, cancel) without unnecessary bloat or missing core functionality.
The tool set covers the essential lifecycle: bill creation, payment confirmation, status checking, cancellation, and auth token refresh. A minor gap is the lack of a retry mechanism for declined payments beyond fetching status, but the workflow is otherwise complete for the stated purpose.
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 provided, so description carries full burden. Discloses that it captures bill details, requires user input, and returns fees and payment link. Could be more explicit about creating/persisting something, but overall transparent about the workflow.
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 long but well-structured into paragraphs. Front-loaded with main purpose. Every sentence adds value, though some details could be tightened. Overall appropriate for the tool's 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?
Given the tool's complexity (many fields, steps), description covers bill capture, remit-to address research, user amount negotiation, account reuse, and explains key outputs (fees, payment link). Could add error handling but is largely 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?
Schema description coverage is 0% per context, so description must compensate. It adds significant meaning beyond the schema, explaining the importance of remit-to address, how to set amount_to_pay and user_amount_statement, and handling user_id/auth_token. This compensates well for the lack of schema descriptions.
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 reads a bill from the user description and creates it for payment, and positions it as the first step. It distinguishes from sibling tools like fetch_bill_status by focusing on creation and capturing payment 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 extensive guidance on when to use, what to capture, and how to handle missing remit-to addresses. Explicitly instructs to ask user for amount before calling. Lacks explicit exclusion of when not to use, but context is very clear.
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 provided, the description carries full responsibility for behavioral disclosure. It reveals the two return states (card details or PENDING) and implies a non-destructive, read-only check. However, it does not explicitly state that the tool has no side effects or that it is idempotent, which would be beneficial for agents.
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 and return information, followed by usage guidance and an Args section. It is concise (roughly 80 words) without unnecessary details, though the 'Optional:' at the start could be integrated more naturally.
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 moderate complexity (1 parameter nested with 2 fields, no enums), the description covers purpose, return values, usage context relative to sibling tools, and input structure. The presence of an output schema likely details the return type further, so the description's mention of return states suffices. It is fully adequate for an agent to decide when and how to use.
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?
Schema description coverage is 0% per context, so the description must compensate. The Args section merely says 'the user_id and bill_id to look up', which adds little beyond the schema's own brief descriptions like 'identifier for the bill'. It does not explain the pattern constraints (e.g., 10-character alphanumeric) or that both are required, leaving agents to infer from 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 the tool checks if a card is on the bill yet, with a specific verb ('check') and resource ('payment method'). It distinguishes itself from sibling tools like 'confirm_payment_intent' by positioning itself as an optional confirmation step. The phrase 'Returns the card's last 4 digits and name when one is set, or a PENDING status' defines its exact role.
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 ('Use only if you need to confirm the card landed (e.g. the user asks)') and when-not-to-use ('it is not a required step; the normal path is analyze_bill -> user fills the form -> confirm_payment_intent'). This directly guides the agent to use the tool only in specific scenarios.
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?
No annotations exist, so the description bears full disclosure burden. It covers key behaviors: submission fails without extra_infos, refresh_token must be from prior calls, and user_amount_statement is required. However, it doesn't explicitly state the mutation nature (payment submission), but it's strongly implied.
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 and prerequisites, then enumerates arguments. Some redundancy with the schema exists (e.g., listing args again), but it remains clear and well-organized. Minor wordiness reduces conciseness slightly.
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 that an output schema exists and the tool has moderate complexity, the description covers all necessary context: user confirmation, optional corrections for extracted values, extra info handling, and token usage. No gaps apparent.
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 the input schema has per-property descriptions, the tool description adds crucial context beyond schema: warns never to invent email, explains extra_infos failure condition, and stresses user_amount_statement must quote actual user speech. This adds significant value over structured data.
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' and distinguishes from siblings like analyze_bill by emphasizing it's the conclusion after confirmation. It uses specific verbs and resources, making 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?
Explicit prerequisites are given: user must confirm the amount, do not call without asking, supply extra_infos if needed, and use entered_account only for corrections. It clearly tells when to use and when not to, with explicit alternatives implied by sibling tools.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool is a read operation, details the conditional presence of statusEvaluatedDescription, and explains that its presence indicates failure. No mention of auth requirements beyond token or rate limits, but these are less critical for this simple check.
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 a clear first sentence, field behavior notes, and Args/Returns sections. It is concise but the Returns section partially duplicates earlier info, which prevents a perfect score.
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 existence of an output schema and the description's explanation of return fields, the tool definition is complete for a simple status check. It covers how to interpret status and failure reasons, though it could mention error handling.
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 detailed descriptions for bill_id and auth_token (e.g., format, origin), so schema coverage is high. The description only repeats 'bill identifier and auth token' without adding new meaning, resulting in baseline score.
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 uses a specific verb 'Check' and resource 'payment status of a submitted bill', clearly distinguishing it from siblings like check_payment_method or confirm_payment_intent. It also explains how to interpret the response.
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 clear guidance on when to use (after a bill is submitted) and how to interpret results (status field and conditional statusEvaluatedDescription). However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_new_auth_tokenBInspect
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 token, but does not disclose side effects (e.g., invalidating the old token), authentication requirements, rate limits, or return format. The description is too brief to provide adequate behavioral context.
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 very short (one sentence plus an Args line) with no wasted words. It is concise but could benefit from a more structured presentation, e.g., separating usage context from parameter description.
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 tool has an output schema, but the description does not mention what the tool returns. It also lacks details on error conditions or prerequisites. Given the tool's importance (authentication), the description is incomplete and leaves significant gaps.
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?
Schema description coverage is 0%, meaning the description adds no parameter details beyond 'contains the user's refresh token.' However, the schema itself includes a comprehensive description for the refresh_token parameter. The description adds marginal value, and given low coverage, it does not compensate.
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 a call fails with an authorization error.' It specifies the trigger (authorization error) and the resource (auth token), and this is distinct from sibling tools which focus on bills and payments.
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 to use the tool ('when a call fails with an authorization error'), providing clear context. It does not mention when not to use it or suggest alternatives, but the sibling tools are unrelated, so no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bill_cancellationCInspect
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?
With no annotations, the description carries full disclosure burden. It fails to mention destructiveness, required permissions, irreversibility, or rate limits—critical for a cancellation operation.
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 very short and structured with Args/Returns. While concise, it omits essential information, making it less efficient for the agent. Every sentence earns its place, but there is too little content.
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?
Despite having an output schema (per context) and a single nested parameter, the description lacks details on return structure, prerequisites (e.g., bill state), and error conditions. It is incomplete for a mutation 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?
Schema description coverage is 0%, yet the description merely restates 'bill identifier and auth token' without adding format, constraints, or scenarios. The schema already provides patterns, but the description adds no new meaning.
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 'Cancel a bill' with a specific verb and resource. However, it does not differentiate from sibling tools like fetch_bill_status or get_new_auth_token, missing an opportunity to clarify unique scope.
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?
No guidance on when to use this tool versus alternatives (e.g., fetch_bill_status), no prerequisites mentioned (e.g., bill must be cancellable), and no exclusions or context provided.
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!