Skip to main content
Glama

update_my_direct_payment

Set how clients pay the coach directly: UPI ID and/or a payment link, plus instructions. Turning it on routes new checkouts to the coach. (confirm-gated: previews until confirm: true)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input": "<input>"
    },
    "name": "update_my_direct_payment"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes
confirmNoMust be true to actually execute. If false/omitted, returns a preview only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, so the mutation nature is already known; the description adds real value by disclosing the confirm-gated preview behavior and that enabling reroutes new checkouts. It does not cover what happens to existing subscriptions or in-flight checkouts, leaving a small gap.

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, zero filler, with the core action front-loaded and the confirmation semantics parenthetically appended. Every clause carries 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?

For a small nested-object mutation tool with no output schema, the definition covers the essentials: what is configured, what enabling does, and the confirm gate. Minor omissions are edge behavior such as disabling effects and validation when neither URL nor UPI ID is supplied.

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?

With only 50% schema coverage, the description compensates by mapping fields to meaning: 'url' as a payment link, 'upiId' as a payee handle, 'instructions' as client-facing text, and 'enabled' as the routing switch. The nested 'input' wrapper and the confirm flag are left to the schema.

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 ('Set how clients pay the coach directly') and enumerates the configurable pieces (UPI ID, payment link, instructions). It is clearly distinguishable from sibling payment tools like connect_my_stripe, connect_my_razorpay, and get_payment_connections.

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

Usage Guidelines3/5

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

Explains the effect of enabling ('routes new checkouts to the coach'), which implies when to use it, but never states prerequisites or contrasts it with the connect_my_* payment-connection siblings. Usage is implied rather than directed.

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.