Skip to main content
Glama

finance

Agent: Save payment link

save_payment_link
    Save (or update) the external payment URL for one payment context.
    Use when the user gives or corrects a link — e.g. "for child support
    use https://childsupport.state.mn.us". Saving a label that already
    exists (case-insensitive) UPDATES that link's URL.

    Intended for URLs the user explicitly provided or confirmed, not
    found, guessed, or constructed ones. https only; a bare domain like "chase.com" is normalized to
    https://; javascript:/http:/IP-literal/credential-bearing URLs are
    rejected.

    Args:
        label: The payment context name (max 100 chars), e.g. "child support".
        url: The user-provided payment page URL (https).

    Returns:
        {"success": True, "created": bool, "payment_link": {...}} —
        created is False when an existing label's URL was updated.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
labelYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations only give the generic safety profile; the description adds the crucial upsert semantics (an existing case-insensitive label UPDATES its URL, aligning with idempotentHint=false), the validation/normalization rules (https only, bare domain normalized, javascript:/http:/IP-literal/credential URLs rejected), and a field-length limit.

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?

Front-loads the action, then usage, then constraints, then Args/Returns. Each sentence carries distinct information; nothing is repeated from structured fields.

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?

For a 2-param mutation with no output schema, the description supplies the return shape ({success, created, payment_link}) and explains created=False when updating, leaving no gap an agent would need.

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?

Schema description coverage is 0%, so the description carries the full burden: it defines label (payment context name, max 100 chars, example 'child support') and url (user-provided https payment page). No ambiguity remains.

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 (save/update) and resource (external payment URL for one payment context), and implicitly differentiates from delete_payment_link and list_payment_links by scoping to a single context's URL.

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 it (user gives or corrects a link) and when not to (URLs 'found, guessed, or constructed' rather than user-provided). Names the exact triggering scenario with an example.

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