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).
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
| 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.
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 | 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.
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 |
| 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.
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 |
| 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 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.
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
| 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
analyze_bill8 fields changedInput schema / properties / bill_description / properties / remitAddress / anyOfRemoved value: -[
- {
- "properties": {
- "address": {
- "maxLength": 100,
- "minLength": 5,
- "pattern": "^[a-zA-Z0-9\\s\\-\\.',#]+$",
- "title": "Address",
- "type": "string"
- },
- "city": {
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "title": "City",
- "type": "string"
- },
- "name": {
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "title": "Name",
- "type": "string"
- },
- "stateCode": {
- "pattern": "^[A-Z]{2}$",
- "title": "Statecode",
- "type": "string"
- },
- "zip": {
- "pattern": "^\\d{5}(-\\d{4})?$",
- "title": "Zip",
- "type": "string"
- }
- },
- "required": [
- "name",
- "address",
- "city",
- "stateCode",
- "zip"
- ],
- "title": "BillingAddress",
- "type": "object"
- },
- {
- "type": "null"
- }
-]Input schema / properties / bill_description / properties / remitAddress / defaultRemoved value: -nullInput schema / properties / bill_description / properties / remitAddress / descriptionPrevious value: -"Biller remit-to address (where payment is sent). This is the key field for identifying the correct biller - an incorrect or missing remit-to address can cause the bill to be matched to the wrong biller, delaying or failing the payment. Always provide it from the bill. 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 leaving it empty."New value: +"Biller remit-to address (where payment is sent). REQUIRED - a bill cannot be analyzed without it. It is the key signal for safely identifying the biller; without a remit-to address (or another strong identifier) the biller may not be identifiable and the bill will be unpayable. Always provide it: take it from the bill, or if the bill does not show one, identify the biller and research their official remit-to / payment address online. Never omit it or invent a placeholder - if you cannot determine a real remit-to address, ask the user for it."Input schema / properties / bill_description / properties / remitAddress / propertiesAdded value: +{
+ "address": {
+ "maxLength": 100,
+ "minLength": 5,
+ "pattern": "^[a-zA-Z0-9\\s\\-\\.',#]+$",
+ "title": "Address",
+ "type": "string"
+ },
+ "city": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "City",
+ "type": "string"
+ },
+ "name": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "Name",
+ "type": "string"
+ },
+ "stateCode": {
+ "pattern": "^[A-Z]{2}$",
+ "title": "Statecode",
+ "type": "string"
+ },
+ "zip": {
+ "pattern": "^\\d{5}(-\\d{4})?$",
+ "title": "Zip",
+ "type": "string"
+ }
+}Input schema / properties / bill_description / properties / remitAddress / requiredAdded value: +[
+ "name",
+ "address",
+ "city",
+ "stateCode",
+ "zip"
+]Input schema / properties / bill_description / properties / remitAddress / titleAdded value: +"BillingAddress"Input schema / properties / bill_description / properties / remitAddress / typeAdded value: +"object"Input schema / properties / bill_description / requiredPrevious value: -[
- "billerName"
-]New value: +[
+ "remitAddress",
+ "billerName"
+]analyze_bill3 fields changedInput schema / properties / bill_description / properties / account / descriptionPrevious value: -"User Account on the bill, if none ticket number"New value: +"The user's account or customer number on the bill (the biller's identifier for the user's account). Capture it whenever the bill shows one. Put any invoice, ticket, or reference number in otherInfo (in addition to the account number - some billers need both), not here."Input schema / properties / bill_description / properties / otherInfo / descriptionPrevious value: -"Other information extracted from the bill that helps identify the provider or complete the payment (like code, pin, pass ...). If the bill shows a payment phone number, include it here (e.g. 'pay_by_phone': '1-800-555-1234') - like the remit-to address it helps identify the correct biller. For a web-payment URL use the payUrl field instead, not this map."New value: +"Other information extracted from the bill that helps identify the provider or complete the payment (like code, pin, pass ...). Also capture the user's charge identifiers here - invoice number, ticket number, or reference number (e.g. 'invoice_number': '12345', 'reference_number': 'A1B2C3') - whenever the bill shows them, even if it also has an account number: some billers' payment automation needs the account number plus one of these. If the bill shows a payment phone number, include it here too (e.g. 'pay_by_phone': '1-800-555-1234') - like the remit-to address it helps identify the correct biller. For a web-payment URL use the payUrl field instead, not this map."Input schema / properties / bill_description / properties / userAddress / descriptionPrevious value: -"User address"New value: +"The payer's identity: the user's name and billing address (who is paying). Billers use this to attribute the payment to the right person, so a missing or wrong payer identity can cause the payment to be rejected or misapplied. Take it from the bill's account-holder / addressee section if shown; otherwise ask the user for their name and billing address rather than leaving it empty."analyze_bill6 fields changedInput schema / $defsRemoved value: -{
- "BillDescription": {
- "properties": {
- "account": {
- "anyOf": [
- {
- "pattern": "^(([A-Za-z0-9\\s\\*\\.\\-#]{1,20})|(N/A))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "User Account on the bill, if none ticket number",
- "title": "Account"
- },
- "amountDue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Total balance due on the bill (the full amount owed), as read from the bill. This is NOT necessarily what the user will pay - see amount_to_pay.",
- "title": "Amountdue"
- },
- "amount_to_pay": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "The amount the user wants to pay now. May be a partial payment, distinct from amountDue (the bill total). Ask the user how much they want to pay before calling; set equal to amountDue to pay in full. Passing it previews any fee for that amount in the result.",
- "title": "Amount To Pay"
- },
- "auth_token": {
- "anyOf": [
- {
- "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "authorization token attached to the user (if a user already exists from a previous bill payment). MUST be the most recent/current auth_token (check latest call with the same user id, possibly in a previous session). Depending how long ago the previous payment was made, may first need to obtain a new token.",
- "title": "Auth Token"
- },
- "billerName": {
- "description": "Name of the biller",
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "title": "Billername",
- "type": "string"
- },
- "correspondenceAddress": {
- "anyOf": [
- {
- "$ref": "#/$defs/BillingAddress"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Biller correspondence address"
- },
- "dueDate": {
- "anyOf": [
- {
- "pattern": "\\d{1,2}\\s?(/|-)\\s?\\d{1,2}\\s?(/|-)\\s?(\\d{4}|\\d{2})",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Due date for the bill in MM/DD/YYYY format MM/DD/YY is acceptable",
- "title": "Duedate"
- },
- "otherInfo": {
- "default": {},
- "description": "Other information extracted from the bill that helps identify the provider or complete the payment (like code, pin, pass ...). If the bill shows a payment phone number, include it here (e.g. 'pay_by_phone': '1-800-555-1234') - like the remit-to address it helps identify the correct biller. For a web-payment URL use the payUrl field instead, not this map.",
- "patternProperties": {
- "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "integer"
- },
- {
- "maxLength": 75,
- "minLength": 2,
- "pattern": "^[a-zA-Z0-9 \\-\\./,'&@*#:?=+()]+$",
- "type": "string"
- }
- ]
- }
- },
- "propertyNames": {
- "maxLength": 50,
- "minLength": 2
- },
- "title": "Otherinfo",
- "type": "object"
- },
- "payUrl": {
- "anyOf": [
- {
- "maxLength": 120,
- "minLength": 4,
- "pattern": "^[a-zA-Z0-9\\-._~:/?#\\[\\]@!$&'()*+,;=%]+$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "The web address where the bill can be paid online (the 'pay at' / 'pay online' URL printed on the bill), e.g. https://www.biller.com/pay. Like the remit-to address it strongly identifies the correct biller, so include it whenever the bill shows one to reduce the risk of a misidentified, failed, or delayed payment. Must be a single URL of at most 120 characters (just the base 'pay online' address, no extra text); omit it rather than sending anything longer.",
- "title": "Payurl"
- },
- "remitAddress": {
- "anyOf": [
- {
- "$ref": "#/$defs/BillingAddress"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Biller remit-to address (where payment is sent). This is the key field for identifying the correct biller - an incorrect or missing remit-to address can cause the bill to be matched to the wrong biller, delaying or failing the payment. Always provide it from the bill. 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 leaving it empty."
- },
- "userAddress": {
- "anyOf": [
- {
- "$ref": "#/$defs/BillingAddress"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "User address"
- },
- "user_amount_statement": {
- "anyOf": [
- {
- "maxLength": 200,
- "minLength": 3,
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Required proof that you asked the user how much to pay and they answered: quote what the user actually said (e.g. 'pay the full 150' or 'just 50 this month'). You MUST have asked the user before setting amount_to_pay - never invent the amount or this quote.",
- "title": "User Amount Statement"
- },
- "user_id": {
- "anyOf": [
- {
- "pattern": "^[a-zA-Z0-9]{10}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "identifier for the user if a user already exists from a previous bill payment",
- "title": "User Id"
- }
- },
- "required": [
- "billerName"
- ],
- "title": "BillDescription",
- "type": "object"
- },
- "BillingAddress": {
- "properties": {
- "address": {
- "maxLength": 100,
- "minLength": 5,
- "pattern": "^[a-zA-Z0-9\\s\\-\\.',#]+$",
- "title": "Address",
- "type": "string"
- },
- "city": {
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "title": "City",
- "type": "string"
- },
- "name": {
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "title": "Name",
- "type": "string"
- },
- "stateCode": {
- "pattern": "^[A-Z]{2}$",
- "title": "Statecode",
- "type": "string"
- },
- "zip": {
- "pattern": "^\\d{5}(-\\d{4})?$",
- "title": "Zip",
- "type": "string"
- }
- },
- "required": [
- "name",
- "address",
- "city",
- "stateCode",
- "zip"
- ],
- "title": "BillingAddress",
- "type": "object"
- }
-}Input schema / properties / bill_description / $refRemoved value: -"#/$defs/BillDescription"Input schema / properties / bill_description / propertiesAdded value: +{
+ "account": {
+ "anyOf": [
+ {
+ "pattern": "^(([A-Za-z0-9\\s\\*\\.\\-#]{1,20})|(N/A))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "User Account on the bill, if none ticket number",
+ "title": "Account"
+ },
+ "amountDue": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Total balance due on the bill (the full amount owed), as read from the bill. This is NOT necessarily what the user will pay - see amount_to_pay.",
+ "title": "Amountdue"
+ },
+ "amount_to_pay": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The amount the user wants to pay now. May be a partial payment, distinct from amountDue (the bill total). Ask the user how much they want to pay before calling; set equal to amountDue to pay in full. Passing it previews any fee for that amount in the result.",
+ "title": "Amount To Pay"
+ },
+ "auth_token": {
+ "anyOf": [
+ {
+ "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "authorization token attached to the user (if a user already exists from a previous bill payment). MUST be the most recent/current auth_token (check latest call with the same user id, possibly in a previous session). Depending how long ago the previous payment was made, may first need to obtain a new token.",
+ "title": "Auth Token"
+ },
+ "billerName": {
+ "description": "Name of the biller",
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "Billername",
+ "type": "string"
+ },
+ "correspondenceAddress": {
+ "anyOf": [
+ {
+ "properties": {
+ "address": {
+ "maxLength": 100,
+ "minLength": 5,
+ "pattern": "^[a-zA-Z0-9\\s\\-\\.',#]+$",
+ "title": "Address",
+ "type": "string"
+ },
+ "city": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "City",
+ "type": "string"
+ },
+ "name": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "Name",
+ "type": "string"
+ },
+ "stateCode": {
+ "pattern": "^[A-Z]{2}$",
+ "title": "Statecode",
+ "type": "string"
+ },
+ "zip": {
+ "pattern": "^\\d{5}(-\\d{4})?$",
+ "title": "Zip",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "address",
+ "city",
+ "stateCode",
+ "zip"
+ ],
+ "title": "BillingAddress",
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Biller correspondence address"
+ },
+ "dueDate": {
+ "anyOf": [
+ {
+ "pattern": "\\d{1,2}\\s?(/|-)\\s?\\d{1,2}\\s?(/|-)\\s?(\\d{4}|\\d{2})",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Due date for the bill in MM/DD/YYYY format MM/DD/YY is acceptable",
+ "title": "Duedate"
+ },
+ "otherInfo": {
+ "default": {},
+ "description": "Other information extracted from the bill that helps identify the provider or complete the payment (like code, pin, pass ...). If the bill shows a payment phone number, include it here (e.g. 'pay_by_phone': '1-800-555-1234') - like the remit-to address it helps identify the correct biller. For a web-payment URL use the payUrl field instead, not this map.",
+ "patternProperties": {
+ "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "maxLength": 75,
+ "minLength": 2,
+ "pattern": "^[a-zA-Z0-9 \\-\\./,'&@*#:?=+()]+$",
+ "type": "string"
+ }
+ ]
+ }
+ },
+ "propertyNames": {
+ "maxLength": 50,
+ "minLength": 2
+ },
+ "title": "Otherinfo",
+ "type": "object"
+ },
+ "payUrl": {
+ "anyOf": [
+ {
+ "maxLength": 120,
+ "minLength": 4,
+ "pattern": "^[a-zA-Z0-9\\-._~:/?#\\[\\]@!$&'()*+,;=%]+$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "The web address where the bill can be paid online (the 'pay at' / 'pay online' URL printed on the bill), e.g. https://www.biller.com/pay. Like the remit-to address it strongly identifies the correct biller, so include it whenever the bill shows one to reduce the risk of a misidentified, failed, or delayed payment. Must be a single URL of at most 120 characters (just the base 'pay online' address, no extra text); omit it rather than sending anything longer.",
+ "title": "Payurl"
+ },
+ "remitAddress": {
+ "anyOf": [
+ {
+ "properties": {
+ "address": {
+ "maxLength": 100,
+ "minLength": 5,
+ "pattern": "^[a-zA-Z0-9\\s\\-\\.',#]+$",
+ "title": "Address",
+ "type": "string"
+ },
+ "city": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "City",
+ "type": "string"
+ },
+ "name": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "Name",
+ "type": "string"
+ },
+ "stateCode": {
+ "pattern": "^[A-Z]{2}$",
+ "title": "Statecode",
+ "type": "string"
+ },
+ "zip": {
+ "pattern": "^\\d{5}(-\\d{4})?$",
+ "title": "Zip",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "address",
+ "city",
+ "stateCode",
+ "zip"
+ ],
+ "title": "BillingAddress",
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Biller remit-to address (where payment is sent). This is the key field for identifying the correct biller - an incorrect or missing remit-to address can cause the bill to be matched to the wrong biller, delaying or failing the payment. Always provide it from the bill. 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 leaving it empty."
+ },
+ "userAddress": {
+ "anyOf": [
+ {
+ "properties": {
+ "address": {
+ "maxLength": 100,
+ "minLength": 5,
+ "pattern": "^[a-zA-Z0-9\\s\\-\\.',#]+$",
+ "title": "Address",
+ "type": "string"
+ },
+ "city": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "City",
+ "type": "string"
+ },
+ "name": {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "title": "Name",
+ "type": "string"
+ },
+ "stateCode": {
+ "pattern": "^[A-Z]{2}$",
+ "title": "Statecode",
+ "type": "string"
+ },
+ "zip": {
+ "pattern": "^\\d{5}(-\\d{4})?$",
+ "title": "Zip",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "address",
+ "city",
+ "stateCode",
+ "zip"
+ ],
+ "title": "BillingAddress",
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "User address"
+ },
+ "user_amount_statement": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "minLength": 3,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Required proof that you asked the user how much to pay and they answered: quote what the user actually said (e.g. 'pay the full 150' or 'just 50 this month'). You MUST have asked the user before setting amount_to_pay - never invent the amount or this quote.",
+ "title": "User Amount Statement"
+ },
+ "user_id": {
+ "anyOf": [
+ {
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "identifier for the user if a user already exists from a previous bill payment",
+ "title": "User Id"
+ }
+}Input schema / properties / bill_description / requiredAdded value: +[
+ "billerName"
+]Input schema / properties / bill_description / titleAdded value: +"BillDescription"Input schema / properties / bill_description / typeAdded value: +"object"check_payment_method7 fields changedInput schema / $defsRemoved value: -{
- "PaymentMethodCheckInput": {
- "description": "Identifiers to look up whether a card has been set on a bill yet.",
- "properties": {
- "bill_id": {
- "description": "identifier for the bill",
- "pattern": "^[a-zA-Z0-9]{10}$",
- "title": "Bill Id",
- "type": "string"
- },
- "user_id": {
- "description": "identifier for the user the bill belongs to",
- "pattern": "^[a-zA-Z0-9]{10}$",
- "title": "User Id",
- "type": "string"
- }
- },
- "required": [
- "user_id",
- "bill_id"
- ],
- "title": "PaymentMethodCheckInput",
- "type": "object"
- }
-}Input schema / properties / check_input / $refRemoved value: -"#/$defs/PaymentMethodCheckInput"Input schema / properties / check_input / descriptionAdded value: +"Identifiers to look up whether a card has been set on a bill yet."Input schema / properties / check_input / propertiesAdded value: +{
+ "bill_id": {
+ "description": "identifier for the bill",
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "title": "Bill Id",
+ "type": "string"
+ },
+ "user_id": {
+ "description": "identifier for the user the bill belongs to",
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "title": "User Id",
+ "type": "string"
+ }
+}Input schema / properties / check_input / requiredAdded value: +[
+ "user_id",
+ "bill_id"
+]Input schema / properties / check_input / titleAdded value: +"PaymentMethodCheckInput"Input schema / properties / check_input / typeAdded value: +"object"confirm_payment_intent6 fields changedInput schema / $defsRemoved value: -{
- "ConfirmInput": {
- "properties": {
- "amount_to_pay": {
- "description": "The amount the user has chosen to pay - this is what gets charged. May be a partial payment (less than the bill's full balance). Use the amount the user agreed to when the bill was analyzed, unless they have since changed it.",
- "title": "Amount To Pay",
- "type": "number"
- },
- "auth_token": {
- "description": "authorization token attached to the user as obtained when submitting the bill, searching for a biller or getting a new auth token",
- "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
- "title": "Auth Token",
- "type": "string"
- },
- "bill_id": {
- "description": "identifier for the specific bill that was provided as a result of a bill extraction",
- "pattern": "^[a-zA-Z0-9]{10}$",
- "title": "Bill Id",
- "type": "string"
- },
- "email": {
- "description": "The user's real email, used to send them payment-status updates. You MUST ask the user for it (or reuse an email they gave earlier in this conversation) and confirm the spelling. NEVER invent, guess, or derive it from their name or the bill - a made-up email means the user gets no updates and could send their payment notifications to a stranger.",
- "maxLength": 254,
- "pattern": "^[a-zA-Z0-9]+([a-zA-Z0-9._%+-]*[a-zA-Z0-9])?@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$",
- "title": "Email",
- "type": "string"
- },
- "entered_account": {
- "anyOf": [
- {
- "pattern": "^(([A-Za-z0-9\\s\\*\\.\\-#]{1,20})|(N/A))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "(optional) if the user wishes to change the value extracted for the account by the bill analysis or provided during maual creation, provide the new value here",
- "title": "Entered Account"
- },
- "entered_provider": {
- "anyOf": [
- {
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "(optional) if the user wishes to change the provider name extracted by bill analysis or use during manual bill creation provide the new value here",
- "title": "Entered Provider"
- },
- "extra_infos": {
- "default": {},
- "description": "dictionary of information provided by the user as {<fieldname1>:<value1> , <fieldname2>:<value2> ,...}",
- "patternProperties": {
- "^[a-zA-Z0-9_]{2,20}$": {
- "anyOf": [
- {
- "maxLength": 50,
- "minLength": 2,
- "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
- "type": "string"
- },
- {
- "pattern": "^(([A-Za-z0-9\\s\\*\\.\\-#]{1,20})|(N/A))$",
- "type": "string"
- },
- {
- "pattern": "\\d{1,2}\\s?(/|-)\\s?\\d{1,2}\\s?(/|-)\\s?\\d{4}",
- "type": "string"
- }
- ]
- }
- },
- "title": "Extra Infos",
- "type": "object"
- },
- "fee_approved": {
- "description": "True if any fees on the payment have been disclosed to the user and they accepted them",
- "title": "Fee Approved",
- "type": "boolean"
- },
- "phone": {
- "default": "2223334444",
- "description": "phone number for the user (use the default if you do not have a real one)",
- "pattern": "^(\\+?1[\\s.\\-]?)?(\\([2-9]\\d{2}\\)|[2-9]\\d{2})[\\s.\\-\\\\\\/]?\\d{3}[\\s.\\-\\\\\\/]?\\d{4}$",
- "title": "Phone",
- "type": "string"
- },
- "refresh_token": {
- "description": "Refresh token obtained when the user was created during a bill analysis or as input to a previous confirm_payment_intent tool call in previous bill payment sessions",
- "pattern": "^r:[a-z0-9]{32}$",
- "title": "Refresh Token",
- "type": "string"
- },
- "user_amount_statement": {
- "description": "Required proof that you asked the user and they confirmed the amount: quote what the user actually said about how much to pay (e.g. 'pay the full 150' or 'just pay 50 this month'). You MUST have confirmed amount_to_pay with the user before calling this - never invent this.",
- "maxLength": 200,
- "minLength": 3,
- "title": "User Amount Statement",
- "type": "string"
- },
- "user_id": {
- "description": "identifier for the user that was provided as a result of bill extraction",
- "pattern": "^[a-zA-Z0-9]{10}$",
- "title": "User Id",
- "type": "string"
- }
- },
- "required": [
- "user_id",
- "bill_id",
- "auth_token",
- "refresh_token",
- "amount_to_pay",
- "user_amount_statement",
- "email",
- "fee_approved"
- ],
- "title": "ConfirmInput",
- "type": "object"
- }
-}Input schema / properties / confirm_input / $refRemoved value: -"#/$defs/ConfirmInput"Input schema / properties / confirm_input / propertiesAdded value: +{
+ "amount_to_pay": {
+ "description": "The amount the user has chosen to pay - this is what gets charged. May be a partial payment (less than the bill's full balance). Use the amount the user agreed to when the bill was analyzed, unless they have since changed it.",
+ "title": "Amount To Pay",
+ "type": "number"
+ },
+ "auth_token": {
+ "description": "authorization token attached to the user as obtained when submitting the bill, searching for a biller or getting a new auth token",
+ "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
+ "title": "Auth Token",
+ "type": "string"
+ },
+ "bill_id": {
+ "description": "identifier for the specific bill that was provided as a result of a bill extraction",
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "title": "Bill Id",
+ "type": "string"
+ },
+ "email": {
+ "description": "The user's real email, used to send them payment-status updates. You MUST ask the user for it (or reuse an email they gave earlier in this conversation) and confirm the spelling. NEVER invent, guess, or derive it from their name or the bill - a made-up email means the user gets no updates and could send their payment notifications to a stranger.",
+ "maxLength": 254,
+ "pattern": "^[a-zA-Z0-9]+([a-zA-Z0-9._%+-]*[a-zA-Z0-9])?@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$",
+ "title": "Email",
+ "type": "string"
+ },
+ "entered_account": {
+ "anyOf": [
+ {
+ "pattern": "^(([A-Za-z0-9\\s\\*\\.\\-#]{1,20})|(N/A))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "(optional) if the user wishes to change the value extracted for the account by the bill analysis or provided during maual creation, provide the new value here",
+ "title": "Entered Account"
+ },
+ "entered_provider": {
+ "anyOf": [
+ {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "(optional) if the user wishes to change the provider name extracted by bill analysis or use during manual bill creation provide the new value here",
+ "title": "Entered Provider"
+ },
+ "extra_infos": {
+ "default": {},
+ "description": "dictionary of information provided by the user as {<fieldname1>:<value1> , <fieldname2>:<value2> ,...}",
+ "patternProperties": {
+ "^[a-zA-Z0-9_]{2,20}$": {
+ "anyOf": [
+ {
+ "maxLength": 50,
+ "minLength": 2,
+ "pattern": "^(([a-zA-Z0-9 \\-\\_.,'&]+)|(N/A))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^(([A-Za-z0-9\\s\\*\\.\\-#]{1,20})|(N/A))$",
+ "type": "string"
+ },
+ {
+ "pattern": "\\d{1,2}\\s?(/|-)\\s?\\d{1,2}\\s?(/|-)\\s?\\d{4}",
+ "type": "string"
+ }
+ ]
+ }
+ },
+ "title": "Extra Infos",
+ "type": "object"
+ },
+ "fee_approved": {
+ "description": "True if any fees on the payment have been disclosed to the user and they accepted them",
+ "title": "Fee Approved",
+ "type": "boolean"
+ },
+ "phone": {
+ "default": "2223334444",
+ "description": "phone number for the user (use the default if you do not have a real one)",
+ "pattern": "^(\\+?1[\\s.\\-]?)?(\\([2-9]\\d{2}\\)|[2-9]\\d{2})[\\s.\\-\\\\\\/]?\\d{3}[\\s.\\-\\\\\\/]?\\d{4}$",
+ "title": "Phone",
+ "type": "string"
+ },
+ "refresh_token": {
+ "description": "Refresh token obtained when the user was created during a bill analysis or as input to a previous confirm_payment_intent tool call in previous bill payment sessions",
+ "pattern": "^r:[a-z0-9]{32}$",
+ "title": "Refresh Token",
+ "type": "string"
+ },
+ "user_amount_statement": {
+ "description": "Required proof that you asked the user and they confirmed the amount: quote what the user actually said about how much to pay (e.g. 'pay the full 150' or 'just pay 50 this month'). You MUST have confirmed amount_to_pay with the user before calling this - never invent this.",
+ "maxLength": 200,
+ "minLength": 3,
+ "title": "User Amount Statement",
+ "type": "string"
+ },
+ "user_id": {
+ "description": "identifier for the user that was provided as a result of bill extraction",
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "title": "User Id",
+ "type": "string"
+ }
+}Input schema / properties / confirm_input / requiredAdded value: +[
+ "user_id",
+ "bill_id",
+ "auth_token",
+ "refresh_token",
+ "amount_to_pay",
+ "user_amount_statement",
+ "email",
+ "fee_approved"
+]Input schema / properties / confirm_input / titleAdded value: +"ConfirmInput"Input schema / properties / confirm_input / typeAdded value: +"object"fetch_bill_status6 fields changedInput schema / $defsRemoved value: -{
- "BillStatusInput": {
- "properties": {
- "auth_token": {
- "description": "authorization token attached to the user as obtained when submitting the bill, searching for a biller or getting a new auth token",
- "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
- "title": "Auth Token",
- "type": "string"
- },
- "bill_id": {
- "description": "identifier for the specific bill that was provided as a result of a bill extraction",
- "pattern": "^[a-zA-Z0-9]{10}$",
- "title": "Bill Id",
- "type": "string"
- }
- },
- "required": [
- "bill_id",
- "auth_token"
- ],
- "title": "BillStatusInput",
- "type": "object"
- }
-}Input schema / properties / bill_status_input / $refRemoved value: -"#/$defs/BillStatusInput"Input schema / properties / bill_status_input / propertiesAdded value: +{
+ "auth_token": {
+ "description": "authorization token attached to the user as obtained when submitting the bill, searching for a biller or getting a new auth token",
+ "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
+ "title": "Auth Token",
+ "type": "string"
+ },
+ "bill_id": {
+ "description": "identifier for the specific bill that was provided as a result of a bill extraction",
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "title": "Bill Id",
+ "type": "string"
+ }
+}Input schema / properties / bill_status_input / requiredAdded value: +[
+ "bill_id",
+ "auth_token"
+]Input schema / properties / bill_status_input / titleAdded value: +"BillStatusInput"Input schema / properties / bill_status_input / typeAdded value: +"object"get_new_auth_token6 fields changedInput schema / $defsRemoved value: -{
- "NewTokenInput": {
- "properties": {
- "refresh_token": {
- "description": "a token used to refresh expired auth token provided by previous calls to analyze_bill or create_manual_bills",
- "pattern": "^r:[a-z0-9]{32}$",
- "title": "Refresh Token",
- "type": "string"
- }
- },
- "required": [
- "refresh_token"
- ],
- "title": "NewTokenInput",
- "type": "object"
- }
-}Input schema / properties / new_token_input / $refRemoved value: -"#/$defs/NewTokenInput"Input schema / properties / new_token_input / propertiesAdded value: +{
+ "refresh_token": {
+ "description": "a token used to refresh expired auth token provided by previous calls to analyze_bill or create_manual_bills",
+ "pattern": "^r:[a-z0-9]{32}$",
+ "title": "Refresh Token",
+ "type": "string"
+ }
+}Input schema / properties / new_token_input / requiredAdded value: +[
+ "refresh_token"
+]Input schema / properties / new_token_input / titleAdded value: +"NewTokenInput"Input schema / properties / new_token_input / typeAdded value: +"object"request_bill_cancellation6 fields changedInput schema / $defsRemoved value: -{
- "BillStatusInput": {
- "properties": {
- "auth_token": {
- "description": "authorization token attached to the user as obtained when submitting the bill, searching for a biller or getting a new auth token",
- "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
- "title": "Auth Token",
- "type": "string"
- },
- "bill_id": {
- "description": "identifier for the specific bill that was provided as a result of a bill extraction",
- "pattern": "^[a-zA-Z0-9]{10}$",
- "title": "Bill Id",
- "type": "string"
- }
- },
- "required": [
- "bill_id",
- "auth_token"
- ],
- "title": "BillStatusInput",
- "type": "object"
- }
-}Input schema / properties / bill_cancel_input / $refRemoved value: -"#/$defs/BillStatusInput"Input schema / properties / bill_cancel_input / propertiesAdded value: +{
+ "auth_token": {
+ "description": "authorization token attached to the user as obtained when submitting the bill, searching for a biller or getting a new auth token",
+ "pattern": "^[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}$",
+ "title": "Auth Token",
+ "type": "string"
+ },
+ "bill_id": {
+ "description": "identifier for the specific bill that was provided as a result of a bill extraction",
+ "pattern": "^[a-zA-Z0-9]{10}$",
+ "title": "Bill Id",
+ "type": "string"
+ }
+}Input schema / properties / bill_cancel_input / requiredAdded value: +[
+ "bill_id",
+ "auth_token"
+]Input schema / properties / bill_cancel_input / titleAdded value: +"BillStatusInput"Input schema / properties / bill_cancel_input / typeAdded value: +"object"analyze_billcheck_payment_methodconfirm_payment_intentfetch_bill_statusget_new_auth_tokenrequest_bill_cancellationClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Pay any US bill in a snap, right from your chat — utilities, medical, rent, parking tickets & more.
Split bills from your AI: read bills & balances, create equal splits, request settlements.
Create a bill from a chat/photo and share it with anyone
Let your AI send invoices and take payment — card or ACH. Free.
Add one secure layer between your agents and this server.
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.
