Skip to main content
Glama

Make an invoice's payment link

well_mint_payment_link
DestructiveIdempotent

Make the card payment link of one issued invoice, for the owner to forward to the customer, through a payment provider this workspace connected: the bank that holds the account the invoice prints when it makes payment links (Qonto), else Stripe, else Qonto. A provider of another workspace is never used. Call it when the owner asks for an invoice's payment link, or at the step of a skill you are following that says to; never on your own. Well sends nothing to the customer.

Pass invoice_id: the invoice's id, or the number the owner named it by (INV-2026-0148). When the owner names only the customer ("the payment link for Atelier Berg"), pass customer_name instead, as the owner wrote it: Well picks that customer's one issued invoice still to be paid, and refuses with each candidate named when there are several, so you ask which one. A draft, a canceled invoice, a credit note and an invoice with nothing left to pay are refused.

The result's outcome:

  • minted: give the owner portal_url as a plain link, exactly as returned. Never give mint.url: portal_url is the page that shows the invoice and its payment options. A repeated call returns the same link (reused: true). An owner's or an admin's yes to a link turns card payment on for every later invoice of the workspace, unless they saved invoice_card_payment_link "off" before: card_payment_on_every_invoice is true when it is on, and then say in one line that every later invoice gets its card payment link and QR code, and that the owner can turn it off.

  • not_configured: no Stripe or Qonto connection can make payment links; mint.slug names the provider. Give connect_url as a plain link when it is present; the owner connects or reconnects that provider there, then asks again.

  • failed: no link was made, and message says why. Tell the owner the invoice keeps its bank details. When connect_url is present, give it as a plain link: the owner reconnects the provider there. Never retry on your own.

In Well's own chat and on WhatsApp, a call that no connection of the workspace can mint is refused before any confirmation, with success: false and the code payment_link_unavailable: say in one line that the invoice gets no card payment link and keeps its bank details and its customer page, and give link as a plain link when it is present, the way connect_url is given for not_configured. The confirmation of a call that can mint names the provider that makes the link; name that same provider, never another.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
invoice_idNoThe UUID of the invoice to make the payment link of. When the person named it by its reference instead (DRAFT-0007, the draft's own reference, or an issued number), pass that reference: Well resolves it, and refuses a reference that names several invoices.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
customer_nameNoThe customer's name as the owner wrote it, when the owner did not name the invoice. Pass this or invoice_id, not both.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
codeNo
mintNo
errorNo
reusedNo
messageNo
outcomeNo
successYes
invoice_idNo
portal_urlNo
connect_urlNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
card_payment_on_every_invoiceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / card_payment_on_every_invoice
      Added value: +{
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changed
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / invoice_id / description
      Previous value: -"The UUID of the invoice to make the payment link of. When the person named it by its reference instead (DRAFT-061, the number a draft shows, or an issued number), pass that reference: Well resolves it, and refuses a reference that names several invoices."New value: +"The UUID of the invoice to make the payment link of. When the person named it by its reference instead (DRAFT-0007, the draft's own reference, or an issued number), pass that reference: Well resolves it, and refuses a reference that names several invoices."
  4. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  5. Changed3 schema fields changed
    • addedInput schema / properties / customer_name
      Added value: +{
      +  "description": "The customer's name as the owner wrote it, when the owner did not name the invoice. Pass this or invoice_id, not both.",
      +  "maxLength": 200,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "invoice_id"
      -]
    • addedOutput schema / properties / code
      Added value: +{
      +  "type": "string"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  7. Changed1 schema field changed
    • addedOutput schema / properties / newly_connected
      Added value: +{
      +  "description": "Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "type": "string"
      +      },
      +      "service_id": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "service_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  8. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare openWorld, idempotent and destructive, but the description adds the substance behind them: the global side effect (a yes turns card payment on for every later invoice and QR code), reuse behavior ('A repeated call returns the same link (reused: true)'), and the three outcome branches with what to surface in each. It also explains the pre-confirmation refusal path (`payment_link_unavailable`) in Well chat and WhatsApp, which no annotation conveys. The lone loose word is calling this a 'read' in the workspace-authorization sentence, which is imprecise for a write but does not contradict the behavioral claims.

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?

Front-loaded and well organized with a bulleted outcome list, but at roughly 450 words it is heavy, and instructions repeat: 'give `connect_url` as a plain link' appears twice in near-identical form, and the plain-link rendering convention is re-specified per field. The chat/WhatsApp paragraph adds a third layer of link-rendering rules that could be consolidated.

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?

Complete for a six-parameter, open-world, output-schema-bearing mutation. It covers provider fallback, refusal cases, outcome handling, single-vs-multiple workspace auth, conversation_id continuation, and the confirmation-time requirement to name the same provider. An agent has everything needed to call it, interpret the result, and report to the owner.

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?

Schema coverage is 100%, so the baseline is 3; the description earns more by explaining that `invoice_id` accepts the owner's reference (INV-2026-0148) and is resolved, and by adding the customer_name path with its ambiguity-refusal semantics ('refuses with each candidate named'). It also explains the conditional workspace_id rule in plain terms. Not a 5 because these points largely restate the schema descriptions rather than adding new constraints.

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?

States a specific verb and resource ('Make the card payment link of one issued invoice') and pins the exact scope: one issued invoice, forwarded by the owner. The provider resolution order (Qonto, else Stripe, else Qonto) and the 'a provider of another workspace is never used' clause further narrow what this tool does, so an agent can distinguish it from generic link-creation siblings without opening any schema.

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?

Gives an explicit trigger ('when the owner asks for an invoice's payment link, or at the step of a skill') and an explicit prohibition ('never on your own'), plus 'never retry on your own'. It also routes between the two identification paths (invoice_id vs customer_name) and enumerates what gets refused: drafts, canceled invoices, credit notes, and paid-up invoices.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources