India Payments (Razorpay Payment Links — UPI / cards / netbanking)
Server Details
India payments for AI agents — UPI, cards, wallets via Razorpay Payment Links. Never holds funds.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 2 of 2 tools scored.
The two tools have clearly distinct purposes: one creates a payment link, the other checks its status. There is no overlap or ambiguity.
Both tool names follow a consistent verb_noun pattern: create_payment_link and query_payment_status. The naming is predictable and clear.
With only 2 tools, the server feels minimally functional. While it covers the core create and status check, it is on the low end of what is expected for a payment link service.
The server covers the essential create and query operations, but lacks other expected actions like canceling a payment link or listing all links. This is a notable gap for a full payment link lifecycle.
Available Tools
2 toolscreate_payment_linkAInspect
Create an India payment link in INR via Razorpay Payment Links, a major Indian payment gateway. Buyer pays with UPI (Google Pay / PhonePe / Paytm / any UPI app), credit/debit card, netbanking, or wallet — whatever is enabled on the merchant account. Returns a hosted payment page URL (rzp.io short link) the buyer opens to pay — payment completes automatically, no confirm step. Amounts are in INR rupees (decimals allowed, e.g. 499.50). Bring your own Razorpay key pair via headers x-razorpay-key-id AND x-razorpay-key-secret (free test keys from dashboard.razorpay.com; rzp_test_ keys never move real money). Money always flows buyer→Razorpay→merchant; this service never touches funds.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Which gateway. Omit to auto-select: Cashfree when x-cashfree-* headers are present, otherwise Razorpay. Cashfree requires customer_contact (buyer phone). | |
| amount_inr | Yes | Amount in INR rupees (e.g. 499 or 499.50; converted to paise internally). Minimum ₹1. | |
| description | Yes | What this payment is for (shown to the buyer, ≤2048 chars) | |
| callback_url | No | Optional https URL Razorpay redirects the buyer to after payment. | |
| reference_id | No | Your unique order reference (≤40 chars). Auto-generated if omitted. | |
| customer_name | No | Optional buyer name. | |
| customer_email | No | Optional buyer email — Razorpay emails the payment link to them. | |
| customer_contact | No | Optional buyer phone (e.g. +919000090000) — Razorpay SMSes the payment link to them. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: payment completes automatically, no confirm step, money flow (buyer→Razorpay→merchant), and that the service never touches funds. This adds significant context beyond the openWorldHint=true annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph covering purpose, mechanics, prerequisites, and notes. Every sentence adds value; no redundancy. It is dense yet concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main aspects: creation, return URL, payment flow, authentication. It lacks details on error handling or response format, but given the tool's complexity and no output schema, it is fairly complete. A slight gap for error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds meaning: amounts in INR with decimals, provider auto-selection based on headers, Cashfree requiring customer_contact, auto-generation of reference_id. This enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating an India payment link in INR via Razorpay Payment Links. It specifies payment methods, currency, and the return value (hosted payment URL). It distinguishes from the sibling tool 'query_payment_status' by being about creation, not status querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, including when to use (creating payment links), prerequisite headers (Razorpay key pair), and automatic payment completion. It mentions auto-selection of gateway based on headers. However, it does not explicitly state when not to use or give alternatives beyond the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_payment_statusARead-onlyInspect
Check whether an India payment link (created by create_payment_link) has been paid. Fetches the link from Razorpay directly — a reliable pull-based alternative to webhooks. paid=true when status is PAID.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Omit to auto-select by credential headers. | |
| payment_link_id | Yes | The payment_link_id returned by create_payment_link (Razorpay plink_... or Cashfree link_id) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds that it fetches from Razorpay/Cashfree, is pull-based, and explains the return condition (paid=true when PAID). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, it covers purpose, input, behavior, and output condition. Could mention what happens if link not found, but openWorldHint covers that gap. Still quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The tool description does not add new meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an India payment link has been paid, names the payment provider, and distinguishes it from webhooks. The verb 'query_payment_status' matches the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for reliable pull-based status check as alternative to webhooks, and ties input to create_payment_link output. Does not explicitly exclude other uses but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!