Skip to main content
Glama
artgas1

robokassa-mcp

by artgas1

refund_create

Initiate a refund for a successful Robokassa payment. Supports full and partial refunds with optional fiscal receipt.

Instructions

Initiate a refund for a successful Robokassa payment.

Requires op_key — obtained from check_payment (OpStateExt) or the Result2 webhook payload for the original operation.

Refund amount: - Omit refund_sum for a FULL refund of the original operation. - Pass a numeric amount for a partial refund.

Fiscal receipt: - Omit items to refund without emitting a fiscal receipt (appropriate when the original sale was not fiscalized through Robokassa). - Pass a list of items to emit a receipt for the refund. Each item: {name, quantity, cost, tax, payment_method, payment_object} where tax ∈ none/vat0/vat5/vat7/vat10/vat20/vat105/vat107/vat110/vat120, payment_method ∈ full_payment/advance/..., payment_object ∈ commodity/service/payment/...

Authentication: Uses JWT signed with Password#3. This is distinct from Password#1 (checkout) and Password#2 (XML status). Access to the Refund API must be enabled in the Robokassa cabinet separately.

Returns: {success: bool, request_id: str | None, message: str | None}. Store request_id to poll refund status via refund_status. Common failure messages: NotEnoughOperationFunds, OperationNotFound, AlreadyRefunded.

Credentials may be passed explicitly or via the ROBOKASSA_PASSWORD3 env var.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
op_keyYes
password3No
refund_sumNo
itemsNo
algorithmNoHS256

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses the mutating behavior, authentication with Password#3, return format with success/request_id/message, common failure messages, and need to store request_id for polling. Lacks info on rate limits or idempotency but covers major behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: starts with purpose, then prerequisites, options, authentication, return format, and failure messages. It is slightly lengthy but every sentence earns its place. Front-loaded with the core action.

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?

Given no output schema provided, the description fully explains return values (success, request_id, message) and error messages. It covers all 5 parameters, prerequisites, and how to poll status via refund_status. Complete for a complex payment refund tool.

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 fully compensates. It explains op_key provenance, refund_sum semantics (omit/amount), items structure with tax and payment_method enums, password3 via explicit or env, and algorithm enum. Adds significant meaning beyond schema property names.

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 states 'Initiate a refund for a successful Robokassa payment' with a specific verb and resource. It distinguishes the tool from siblings like refund_status (polling) and partner_refund, and provides details on full vs partial refund and fiscal receipt options.

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?

The description explicitly explains when to use the tool: requires op_key from check_payment or webhook, when to omit refund_sum for full refund, when to omit items for non-fiscalized receipts. It mentions authentication prerequisites but does not explicitly state when to avoid this tool in favor of alternatives like partner_refund.

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/artgas1/robokassa-mcp'

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