Skip to main content
Glama

Papaya Pay Any Bill (US)

by com.papayapay.consumer-production.mcp-agent
OverviewAdmin

Server Details

Pay any US bill in a snap, right from your chat — utilities, medical, rent, parking tickets & more.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A4.3/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct step in the bill payment lifecycle: analyze creates the bill, check_payment_method verifies card setup, confirm_payment_intent submits payment, fetch_bill_status tracks payment status, request_bill_cancellation stops a payment, and get_new_auth_token handles auth refresh. No two tools overlap in purpose, and descriptions clearly differentiate the check status vs. check card method tools.

Naming Consistency5/5

All six tools follow a consistent verb_noun pattern using snake_case: analyze_bill, check_payment_method, confirm_payment_intent, fetch_bill_status, get_new_auth_token, request_bill_cancellation. Verbs are descriptive and distinct, with no mixed conventions or ambiguous short names.

Tool Count5/5

Six tools is well-scoped for a bill payment domain: two core steps (analyze and confirm), one optional verification (card check), one status query, one cancellation, and one auth helper. The count feels neither sparse nor bloated, and each tool contributes to the core workflow.

Completeness5/5

The tool set covers the full lifecycle of paying a bill: create, set payment method, confirm payment, check status, and cancel if needed. Auth token refresh covers authorization failures, and re-running analyze_bill handles corrections. No obvious gaps that would cause agent failures in the intended use case.

Available Tools

6 tools
analyze_billAnalyze BillAInspect

Read a bill from the user's description and create it for payment. This is the first step. Capture every address and identifier on the bill (remit-to address, account/invoice number, any code or pin) - missing details can delay or fail the payment. The remit-to address (where payment is sent) is especially important: it is what identifies the correct biller, and a wrong or missing one can match the bill to the wrong biller and cause a failed or delayed payment. Always include it. If the bill does not show a remit-to address, research the biller's official remit-to / payment address online and use that rather than omitting it. For the same reason, capture the bill's online-payment URL in payUrl and any payment phone number in otherInfo whenever the bill shows them - these strongly identify the correct biller. Always secure a user identifier so the payment can be applied to the right account or charge: capture the account/customer number in the account field, and any invoice, ticket, or reference number in otherInfo - capture all that the bill shows, since some billers need the account number plus another identifier. If the bill shows none, ask the user for one rather than proceeding without it. Before calling, ask the user how much they want to pay (the full balance amountDue, or a partial amount), then pass it as amount_to_pay and quote what they said in user_amount_statement - both are required (never invent the amount). If the payment carries a fee, the result includes a fees list - show any returned fee to the user before continuing. The result also includes a payment_link: give this link to the user as-is so they can enter their card on the secure form (the only way to set a payment method). If the user already exists from a prior bill, pass their user_id and auth_token to reuse the account.

Args:
    bill_description: structured bill details, including amountDue, amount_to_pay
        and user_amount_statement

Returns:
    bill/user identifiers, tokens, provider, amount due, the chosen amount_to_pay,
    a payment_link to the secure card form, and any user-facing fees
ParametersJSON Schema
NameRequiredDescriptionDefault
bill_descriptionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that it creates a bill for payment, that fees may be returned and should be shown, and that a payment_link is returned for card entry. It adds guidance on reusing auth_token for existing users. Annotations already indicate non-read-only, so the description supplements with actionable behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is quite long and somewhat repetitive, especially around the remit-to address being critical. It is dense with useful instructions but lacks clear sectioning or bullet points, making it harder for an agent to quickly parse the key directives.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all necessary context: required fields, handling missing information, pre-call user questions, reuse of auth tokens, and expected return values (fees, payment_link). Since an output schema exists, the description appropriately supplements rather than duplicates, making it complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema includes detailed descriptions for all nested parameters, the tool description adds crucial workflow context: it explains the importance of remitAddress, how to fill amount_to_pay and user_amount_statement, and where to place invoice numbers in otherInfo. This goes beyond the schema's field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: "Read a bill from the user's description and create it for payment." It also positions it as "the first step" in the payment workflow, distinguishing it from sibling tools like confirm_payment_intent or check_payment_method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: it is the first step, and it mandates pre-call actions like asking the user for the payment amount and capturing identifiers. It does not explicitly name when NOT to use it or mention alternative tools, 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.

check_payment_methodCheck Payment MethodA
Read-only
Inspect

Optional: check whether the user has finished the secure form and a card is on the bill yet. Returns the card's last 4 digits and name when one is set, or a PENDING status when the form has not been completed. Use only if you need to confirm the card landed (e.g. the user asks) - it is not a required step; the normal path is analyze_bill -> user fills the form -> confirm_payment_intent.

Args:
    check_input: the user_id and bill_id to look up
ParametersJSON Schema
NameRequiredDescriptionDefault
check_inputYesIdentifiers to look up whether a card has been set on a bill yet.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description is consistent and adds specifics about return values (card details or PENDING). No contradictions; it could mention idempotency but fine given readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear main description and Args section. Slightly lengthy but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers the tool's purpose, usage, and return info. With an output schema available, it's sufficiently complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter is well-documented in schema. The description's Args section adds little beyond restating the purpose; no new semantic details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it checks whether the user has finished the secure form and a card is on the bill, and specifies return values (last 4 digits/name or PENDING). It distinguishes from sibling tools like confirm_payment_intent by noting the normal path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (e.g., user asks) and notes it's not a required step, contrasting with the normal path (analyze_bill → user fills form → confirm_payment_intent).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

confirm_payment_intentConfirm PaymentA
Destructive
Inspect

Final step: submit the bill for payment, after a card has been set. You must have confirmed the amount with the user first (amount_to_pay may be partial) and quote their confirmation in user_amount_statement - do not call this until you have asked. If analyze_bill reported a need for extra information, supply it in extra_infos or submission will fail. Use entered_account / entered_provider only to correct a mis-extracted value. Pass the user's current refresh_token (from analyze_bill or a prior confirm) - do not guess.

Args:
    confirm_input: identifiers, the amount to pay, contact info and any extra info
ParametersJSON Schema
NameRequiredDescriptionDefault
confirm_inputYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true, indicating mutation. The description adds context like 'Final step' and prerequisites, but does not elaborate on irreversible consequences or side effects of wrong usage. It mentions failure conditions (missing extra_infos) but lacks deeper behavioral detail. Still adds value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise, using a short paragraph and a bulleted 'Args' block. It front-loads the core purpose and conditions. However, it could be more structured, e.g., separating preconditions from parameter behavior. The 'Args' section is minimal but effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a nested input object with many required fields, the description covers key aspects: preconditions, dependencies on other tools (analyze_bill), and the need for user confirmation. It does not mention the output schema, but since one exists, the agent can infer return values. Some nuance about destructive nature is missing, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description summarizes confirm_input as containing 'identifiers, the amount to pay, contact info and any extra info', adding context beyond the schema's property types. Although schema descriptions for nested fields are comprehensive (0% coverage at tool level), the description's summary helps the agent understand the high-level structure, earning a score above baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as 'Final step: submit the bill for payment' and distinguishes it from siblings like analyze_bill (analysis) and check_payment_method (checking method). The verb 'submit' and resource 'payment' are specific, and the context of being final step differentiates it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit conditions are given: must have set a card, must confirm amount with user and provide quote, supply extra_infos if needed, only use entered fields for correction, and pass refresh token. The instruction 'do not call this until you have asked' and warning that submission will fail if extra info is missing provide clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_bill_statusFetch Bill StatusA
Read-only
Inspect

Check the payment status of a submitted bill. Read value for the current status. statusEvaluatedDescription is only present when the payment was declined or failed, and then explains why - relay that reason to the user. It is omitted for every other status, so treat its presence as a decline/failure.

Args:
    bill_status_input: the bill identifier and auth token

Returns:
    dictionary with keys value, statusDescription, and - only for declined/failed
    bills - statusEvaluatedDescription explaining why the payment did not go through
ParametersJSON Schema
NameRequiredDescriptionDefault
bill_status_inputYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description adds valuable behavioral context: it explains that 'statusEvaluatedDescription' is only present for declined/failed payments and should be treated as a reason for failure. This goes beyond the annotation's readonly flag by disclosing conditional output behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with an opening statement, a behavioral note, and clear Args/Returns sections. It avoids unnecessary text, though the conditional explanation could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool, the description adequately covers the main behavior and conditional output. However, it lacks explicit mention of default status values or pagination, and the input parameter is not fully unpacked. Given the presence of an output schema (implied by Returns description), this is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for parameter meaning. It only vaguely mentions 'bill_status_input: the bill identifier and auth token' without detailing the nested fields or their formats. The schema itself provides descriptions for 'bill_id' and 'auth_token', but the description adds minimal value beyond aggregation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check the payment status of a submitted bill.' This specifies a concrete action (check) on a specific resource (payment status of a bill). It distinguishes from sibling tools like 'analyze_bill' or 'confirm_payment_intent' by focusing solely on status retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives like 'analyze_bill' or 'check_payment_method'. It implies usage after bill submission but gives no explicit context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_new_auth_tokenRefresh Auth TokenAInspect

Get a fresh auth token when another tool fails with an authorization error. Pass the user's current refresh_token; returns a new auth_token/refresh_token pair to use on the retried call and on later calls. Call this only in response to an auth failure, not preemptively.

Args:
    new_token_input: contains the user's refresh token

Returns:
    a new auth_token and refresh_token pair, or an error if the refresh token is
    missing or invalid
ParametersJSON Schema
NameRequiredDescriptionDefault
new_token_inputYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns a new token pair and errors for missing/invalid refresh tokens, which is sufficient. Annotations indicate non-destructive and non-read-only, and the description does not contradict them. Minor omission: no mention of whether old tokens are invalidated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, uses two short paragraphs with a clear Args/Returns structure, and contains no filler. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool with one parameter and clear purpose, the description provides all necessary context. The presence of an output schema (though not shown) and explicit return value description complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the single parameter 'new_token_input' contains the user's refresh token, and the schema provides additional detail. Together they fully clarify the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool obtains a fresh auth token in response to authorization failures. The name and title align, and it is distinct from sibling tools which handle billing and payment operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to call only on auth failure, not preemptively. This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_bill_cancellationCancel BillA
Destructive
Inspect

Cancel a submitted bill so it will not be paid. Use when the user wants to stop a bill they submitted; cancellation may be rejected if the payment has already progressed too far - relay any error to the user. Not for correcting bill details: re-run analyze_bill for that.

Args:
    bill_cancel_input: the bill identifier and auth token

Returns:
    the cancelled bill id and status, or error details
ParametersJSON Schema
NameRequiredDescriptionDefault
bill_cancel_inputYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so destructive nature is known. Description adds that cancellation may be rejected if payment progressed, and to relay errors. This enriches behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: purpose, usage guidance, args, and returns in a few sentences. No fluff, front-loaded core information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main purpose, usage, return values. Could mention permission requirements or that cancellation may not be reversible, but overall sufficient given tool complexity and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. However, it only vaguely mentions 'the bill identifier and auth token' without detailing the nested structure, required fields, or patterns. The schema provides these details but the description adds little value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it cancels a submitted bill to prevent payment, using specific verb 'cancel' and resource 'bill'. It distinguishes from sibling `analyze_bill` by noting it's not for correcting details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (user wants to stop a bill), what to do if rejection occurs (relay error), and what not to use it for (correcting details, redirecting to `analyze_bill`).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Changedanalyze_bill8 fields changed
      • removedInput schema / properties / bill_description / properties / remitAddress / anyOf
        Removed 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"
-  }
-]
      • removedInput schema / properties / bill_description / properties / remitAddress / default
        Removed value: -null
      • changedInput schema / properties / bill_description / properties / remitAddress / description
        Previous 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."
      • addedInput schema / properties / bill_description / properties / remitAddress / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / bill_description / properties / remitAddress / required
        Added value: +[
+  "name",
+  "address",
+  "city",
+  "stateCode",
+  "zip"
+]
      • addedInput schema / properties / bill_description / properties / remitAddress / title
        Added value: +"BillingAddress"
      • addedInput schema / properties / bill_description / properties / remitAddress / type
        Added value: +"object"
      • changedInput schema / properties / bill_description / required
        Previous value: -[
-  "billerName"
-]New value: +[
+  "remitAddress",
+  "billerName"
+]
  2. 1 tool update
    • Changedanalyze_bill3 fields changed
      • changedInput schema / properties / bill_description / properties / account / description
        Previous 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."
      • changedInput schema / properties / bill_description / properties / otherInfo / description
        Previous 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."
      • changedInput schema / properties / bill_description / properties / userAddress / description
        Previous 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."
  3. 6 tool updates
    • Changedanalyze_bill6 fields changed
      • removedInput schema / $defs
        Removed 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"
-  }
-}
      • removedInput schema / properties / bill_description / $ref
        Removed value: -"#/$defs/BillDescription"
      • addedInput schema / properties / bill_description / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / bill_description / required
        Added value: +[
+  "billerName"
+]
      • addedInput schema / properties / bill_description / title
        Added value: +"BillDescription"
      • addedInput schema / properties / bill_description / type
        Added value: +"object"
    • Changedcheck_payment_method7 fields changed
      • removedInput schema / $defs
        Removed 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"
-  }
-}
      • removedInput schema / properties / check_input / $ref
        Removed value: -"#/$defs/PaymentMethodCheckInput"
      • addedInput schema / properties / check_input / description
        Added value: +"Identifiers to look up whether a card has been set on a bill yet."
      • addedInput schema / properties / check_input / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / check_input / required
        Added value: +[
+  "user_id",
+  "bill_id"
+]
      • addedInput schema / properties / check_input / title
        Added value: +"PaymentMethodCheckInput"
      • addedInput schema / properties / check_input / type
        Added value: +"object"
    • Changedconfirm_payment_intent6 fields changed
      • removedInput schema / $defs
        Removed 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"
-  }
-}
      • removedInput schema / properties / confirm_input / $ref
        Removed value: -"#/$defs/ConfirmInput"
      • addedInput schema / properties / confirm_input / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / confirm_input / required
        Added value: +[
+  "user_id",
+  "bill_id",
+  "auth_token",
+  "refresh_token",
+  "amount_to_pay",
+  "user_amount_statement",
+  "email",
+  "fee_approved"
+]
      • addedInput schema / properties / confirm_input / title
        Added value: +"ConfirmInput"
      • addedInput schema / properties / confirm_input / type
        Added value: +"object"
    • Changedfetch_bill_status6 fields changed
      • removedInput schema / $defs
        Removed 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"
-  }
-}
      • removedInput schema / properties / bill_status_input / $ref
        Removed value: -"#/$defs/BillStatusInput"
      • addedInput schema / properties / bill_status_input / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / bill_status_input / required
        Added value: +[
+  "bill_id",
+  "auth_token"
+]
      • addedInput schema / properties / bill_status_input / title
        Added value: +"BillStatusInput"
      • addedInput schema / properties / bill_status_input / type
        Added value: +"object"
    • Changedget_new_auth_token6 fields changed
      • removedInput schema / $defs
        Removed 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"
-  }
-}
      • removedInput schema / properties / new_token_input / $ref
        Removed value: -"#/$defs/NewTokenInput"
      • addedInput schema / properties / new_token_input / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / new_token_input / required
        Added value: +[
+  "refresh_token"
+]
      • addedInput schema / properties / new_token_input / title
        Added value: +"NewTokenInput"
      • addedInput schema / properties / new_token_input / type
        Added value: +"object"
    • Changedrequest_bill_cancellation6 fields changed
      • removedInput schema / $defs
        Removed 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"
-  }
-}
      • removedInput schema / properties / bill_cancel_input / $ref
        Removed value: -"#/$defs/BillStatusInput"
      • addedInput schema / properties / bill_cancel_input / properties
        Added 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"
+  }
+}
      • addedInput schema / properties / bill_cancel_input / required
        Added value: +[
+  "bill_id",
+  "auth_token"
+]
      • addedInput schema / properties / bill_cancel_input / title
        Added value: +"BillStatusInput"
      • addedInput schema / properties / bill_cancel_input / type
        Added value: +"object"
  4. 6 tool updates
    • First observedanalyze_bill
    • First observedcheck_payment_method
    • First observedconfirm_payment_intent
    • First observedfetch_bill_status
    • First observedget_new_auth_token
    • First observedrequest_bill_cancellation

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

  • voulti-mcp

    csacanam
    A
    license
    Not graded
    quality
    B
    maintenance
    Accept crypto payments from AI agents: create an invoice in one call and get a hosted checkout link (USDC/USDT on Celo, Base, Arbitrum, Polygon, BSC). No API key, instant self-custody settlement.
    MIT

  • P-Link-MCP

    paracetamol951
    A
    license
    B
    quality
    D
    maintenance
    Payment & Transaction Tools that allow AI agents to send, receive, and request payments
    11
    32
    2
    Apache 2.0

  • hive-mcp-trade

    srotzin
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables cross-border SMB invoice settlement on USDT/USDC rails with $0 wire fee and same-block settlement, including fee schedule comparison, invoice creation, status tracking, and dispute arbitration via HiveLaw.
    MIT
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources