Skip to main content
Glama
hectortemich

@deonpay/mcp-server

by hectortemich

Update a payment link

deonpay_update_link

Update a payment link by UUID or short_code. Change amount, status, expiration, or name without resetting other fields. Customization merges, not replaces.

Instructions

Update an existing payment link by UUID or short_code. Only send the fields you want to change — others are preserved. Common uses: pause a link (status='paused'), change its amount, extend the expiration, or rename it. The customization object is MERGED with the existing one (it does not replace it), so you can update a single visual key without losing the rest. Type cannot typically be changed once payments exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesLink UUID or short_code.
nameNo
descriptionNo
amountNoNew amount in centavos.
statusNo
max_usesNo
expires_atNoISO 8601 date or datetime string, e.g. 2026-05-15 or 2026-05-15T10:00:00Z.
allow_msiNo
msi_optionsNo
min_amountNo
max_amountNo
merchant_referenceNo
metadataNo
customizationNoVisual overrides for the hosted page. Only the keys you set are merged into the merchant defaults.

Implementation Reference

  • Registration of the 'deonpay_update_link' tool on the MCP server with inputSchema and handler.
    server.registerTool(
      "deonpay_update_link",
      {
        title: "Update a payment link",
        description:
          "Update an existing payment link by UUID or short_code. Only send the fields you want to change — others are preserved. Common uses: pause a link (status='paused'), change its amount, extend the expiration, or rename it. The customization object is MERGED with the existing one (it does not replace it), so you can update a single visual key without losing the rest. Type cannot typically be changed once payments exist.",
        inputSchema: {
          id: z.string().min(1).describe("Link UUID or short_code."),
          name: z.string().min(1).max(255).optional(),
          description: z.string().optional(),
          amount: z.number().int().min(100).optional().describe("New amount in centavos."),
          status: z.enum(["active", "paused", "expired"]).optional(),
          max_uses: z.number().int().min(1).optional(),
          expires_at: IsoDateStringSchema.optional(),
          allow_msi: z.boolean().optional(),
          msi_options: z.array(z.number().int()).optional(),
          min_amount: z.number().int().min(100).optional(),
          max_amount: z.number().int().min(100).optional(),
          merchant_reference: z.string().optional(),
          metadata: z.record(z.unknown()).optional(),
          customization: CustomizationSchema.optional(),
        },
      },
      safeHandler(async ({ id, ...rest }) => {
        return client.patch(`/links/${encodeURIComponent(id)}`, compact(rest));
      }),
    );
  • Handler function that sends a PATCH request to /links/{id} with the filtered update payload.
    safeHandler(async ({ id, ...rest }) => {
      return client.patch(`/links/${encodeURIComponent(id)}`, compact(rest));
    }),
  • Input schema for deonpay_update_link: id (required), and optional fields like name, description, amount, status, max_uses, expires_at, customization, etc.
    inputSchema: {
      id: z.string().min(1).describe("Link UUID or short_code."),
      name: z.string().min(1).max(255).optional(),
      description: z.string().optional(),
      amount: z.number().int().min(100).optional().describe("New amount in centavos."),
      status: z.enum(["active", "paused", "expired"]).optional(),
      max_uses: z.number().int().min(1).optional(),
      expires_at: IsoDateStringSchema.optional(),
      allow_msi: z.boolean().optional(),
      msi_options: z.array(z.number().int()).optional(),
      min_amount: z.number().int().min(100).optional(),
      max_amount: z.number().int().min(100).optional(),
      merchant_reference: z.string().optional(),
      metadata: z.record(z.unknown()).optional(),
      customization: CustomizationSchema.optional(),
    },
  • safeHandler wraps the handler with try/catch to return MCP-shaped error results. compact strips undefined/null/empty values from the request body.
    export function safeHandler<TArgs>(
      fn: (args: TArgs) => Promise<unknown>,
    ): (args: TArgs) => Promise<CallToolResult> {
      return async (args: TArgs) => {
        try {
          const value = await fn(args);
          return jsonResult(value);
        } catch (err) {
          return errorResult(err);
        }
      };
    }
    
    /**
     * Encodes the local part / full email for use in path segments. RFC 3986 says
     * `@` is reserved as a sub-delim, so encodeURIComponent is the safe choice.
     */
    export function encodePathSegment(value: string): string {
      return encodeURIComponent(value);
    }
    
    /**
     * Strips undefined / null / empty-string entries from a body before sending.
     * The DeonPay API accepts missing fields cleanly but treating "" as a valid
     * value would override server-side defaults — usually not what the LLM means.
     */
    export function compact<T extends Record<string, unknown>>(obj: T): Partial<T> {
      const out: Record<string, unknown> = {};
      for (const [key, value] of Object.entries(obj)) {
        if (value === undefined || value === null) continue;
        if (typeof value === "string" && value.trim() === "") continue;
        out[key] = value;
      }
      return out as Partial<T>;
    }
Behavior4/5

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

With no annotations, the description discloses key behaviors: partial update, merge behavior for customization, and type change limitation. It does not cover idempotency, side effects, or auth, but provides useful context beyond a generic 'update'.

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 a few concise sentences that each add value: identification, partial update, common uses, customization merge, and type limitation. No redundancy or fluff.

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

Completeness3/5

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

Given 14 parameters, low schema coverage, no output schema, and no annotations, the description should cover more. It explains update semantics and merge behavior but omits response format, error handling, and parameter formatting details. Adequate but incomplete.

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 coverage is low (29%), and description adds meaning by explaining partial update and customization merge. It gives an example for 'status' and describes 'customization' merging. However, many parameters remain undocumented, partially compensating but not fully.

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 specifies 'Update an existing payment link' with the verb and resource, and lists common uses like pausing, changing amount, extending expiration, or renaming. It distinguishes from sibling tools such as create_link and get_link.

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?

Guidance includes 'Only send the fields you want to change — others are preserved' and explains customization merging. It notes that type cannot typically be changed after payments exist. However, it lacks explicit 'when not to use' or comparison to alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hectortemich/deonpay-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server