Skip to main content
Glama
hectortemich

@deonpay/mcp-server

by hectortemich

Update a product

deonpay_update_product

Update your product's price, name, stock quantity, or active status by specifying its UUID or SKU. Only changed fields are applied.

Instructions

Update an existing product (resolved by UUID or SKU). Only fields you send are changed. Use this for price adjustments, renaming, toggling is_active, updating stock_quantity, or swapping the image_url. Note: under the hood the API uses HTTP PATCH (not PUT).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesProduct UUID or SKU.
nameNo
descriptionNo
unit_amountNoNew unit price in centavos.
currencyNo
image_urlNo
skuNo
is_activeNo
stock_trackingNo
stock_quantityNo
metadataNo

Implementation Reference

  • The handler function for deonpay_update_product. It destructures `id` from args for the URL path and calls `client.patch()` on `/products/{id}` with the remaining fields compacted (stripping empty/undefined values).
    safeHandler(async ({ id, ...rest }) => {
      return client.patch(`/products/${encodeURIComponent(id)}`, compact(rest));
    }),
  • Zod input schema for deonpay_update_product. Requires `id` (UUID or SKU string), with optional fields: name, description, unit_amount (min 100 centavos), currency, image_url, sku, is_active, stock_tracking, stock_quantity, and metadata.
    inputSchema: {
      id: z.string().min(1).describe("Product UUID or SKU."),
      name: z.string().min(1).max(255).optional(),
      description: z.string().max(1000).optional(),
      unit_amount: z.number().int().min(100).optional().describe("New unit price in centavos."),
      currency: z.string().length(3).optional(),
      image_url: z.string().url().optional(),
      sku: z.string().max(100).optional(),
      is_active: z.boolean().optional(),
      stock_tracking: z.boolean().optional(),
      stock_quantity: z.number().int().min(0).optional(),
      metadata: z.record(z.unknown()).optional(),
    },
  • Registration of the tool named 'deonpay_update_product' on the MCP server via `server.registerTool()`, including its title, description, input schema, and handler.
    server.registerTool(
      "deonpay_update_product",
      {
        title: "Update a product",
        description:
          "Update an existing product (resolved by UUID or SKU). Only fields you send are changed. Use this for price adjustments, renaming, toggling is_active, updating stock_quantity, or swapping the image_url. Note: under the hood the API uses HTTP PATCH (not PUT).",
        inputSchema: {
          id: z.string().min(1).describe("Product UUID or SKU."),
          name: z.string().min(1).max(255).optional(),
          description: z.string().max(1000).optional(),
          unit_amount: z.number().int().min(100).optional().describe("New unit price in centavos."),
          currency: z.string().length(3).optional(),
          image_url: z.string().url().optional(),
          sku: z.string().max(100).optional(),
          is_active: z.boolean().optional(),
          stock_tracking: z.boolean().optional(),
          stock_quantity: z.number().int().min(0).optional(),
          metadata: z.record(z.unknown()).optional(),
        },
      },
      safeHandler(async ({ id, ...rest }) => {
        return client.patch(`/products/${encodeURIComponent(id)}`, compact(rest));
      }),
    );
  • The tool is registered as part of the module, called via `registerProductTools(server, client)` in the central `registerAllTools` registry function.
    registerProductTools(server, client);
  • The `compact` helper used by the handler to strip undefined/null/empty-string values before sending the PATCH body.
    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>;
    }
Behavior3/5

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

No annotations provided, so description carries full burden. Discloses partial update behavior ('Only fields you send are changed') and HTTP method (PATCH). However, lacks details on idempotency, rate limits, authorization needs, or error conditions.

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?

Two sentences with no redundant words. Purpose and key behavior are front-loaded. Every sentence adds value.

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

Completeness2/5

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

With 11 parameters, no output schema, and no annotations, the description is too brief. Missing return format, error handling, pagination hints, and nuance about nested metadata field. Incomplete for complex tool.

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 only 18% (2 of 11 parameters described). Description compensates by clarifying the identifier resolution and partial update semantics, but does not explain parameters like metadata, stock_tracking, or currency beyond what schema lacks.

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?

Clearly states the verb and resource: 'Update an existing product (resolved by UUID or SKU).' Differentiates from sibling tools like deonpay_create_product and deonpay_get_product by specifying update behavior and identifier type.

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?

Provides explicit use cases: 'price adjustments, renaming, toggling is_active, updating stock_quantity, or swapping the image_url.' Lacks explicit when-not-to-use or alternatives, but context is sufficient for most agents.

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