Skip to main content
Glama
theYahia

@theyahia/robokassa-mcp

by theYahia
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

🗄 Репозиторий заархивирован

Разработка переехала в theYahia/WWmcp — монорепозиторий MCP-серверов для незападных API: СНГ, MENA, Африка, LATAM, Юго-Восточная Азия. Общее ядро @theyahia/mcp-core, единый CI, единый релизный конвейер.

Актуальная версия того, что лежало здесь: servers/robokassa/

Пакет в npm прежний — @theyahia/robokassa-mcp, ставится и работает как раньше. Здесь больше ничего не обновляется. Задачи и pull request'ы — в WWmcp.

Archived — development moved to theYahia/WWmcp, a monorepo of MCP servers for non-Western APIs. The current version of this package now lives at servers/robokassa/. The npm package @theyahia/robokassa-mcp is unchanged. Please open issues and pull requests there.

@theyahia/robokassa-mcp

MCP server for Robokassa payment API. 2 tools for invoice creation (with MD5 signature) and status checking.

npm license

Related MCP server: @theyahia/yookassa-mcp

Quick Start

Claude Desktop

{
  "mcpServers": {
    "robokassa": {
      "command": "npx",
      "args": ["-y", "@theyahia/robokassa-mcp"],
      "env": {
        "ROBOKASSA_LOGIN": "your-login",
        "ROBOKASSA_PASSWORD1": "your-password1",
        "ROBOKASSA_PASSWORD2": "your-password2"
      }
    }
  }
}

Claude Code

claude mcp add robokassa -e ROBOKASSA_LOGIN=login -e ROBOKASSA_PASSWORD1=pass1 -e ROBOKASSA_PASSWORD2=pass2 -- npx -y @theyahia/robokassa-mcp

Cursor / Windsurf

{
  "robokassa": {
    "command": "npx",
    "args": ["-y", "@theyahia/robokassa-mcp"],
    "env": {
      "ROBOKASSA_LOGIN": "your-login",
      "ROBOKASSA_PASSWORD1": "your-password1",
      "ROBOKASSA_PASSWORD2": "your-password2"
    }
  }
}

Tools

Tool

Description

create_invoice

Create payment URL with MD5 signature, optional 54-FZ receipt

check_invoice

Check invoice status via OpStateExt XML interface

Auth

Variable

Required

Description

ROBOKASSA_LOGIN

Yes

Merchant login

ROBOKASSA_PASSWORD1

Yes

Password 1 (for payment signature)

ROBOKASSA_PASSWORD2

Yes

Password 2 (for status check signature)

ROBOKASSA_TEST

No

Set to "true" for test mode

HTTP Transport

HTTP_PORT=3000 npx @theyahia/robokassa-mcp
# or
npx @theyahia/robokassa-mcp --http 3000

Endpoints: POST /mcp (JSON-RPC), GET /health (status).

Skills

  • skill-create-invoice -- create a Robokassa payment URL with MD5 signature

  • skill-check-payment -- check invoice status via OpStateExt

License

MIT

Available Tools

2 tools
check_invoiceA

Проверить статус счёта Robokassa по номеру (OpStateExt).

ParametersJSON Schema
NameRequiredDescriptionDefault
invIdYesНомер счёта для проверки статуса

TDQS

A3.7/5.0
Behavior2/5

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

No annotations provided. Description only states 'check status' with no details on behavior, authentication, error handling, or side effects. Insufficient for a read operation.

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?

Single sentence, no fluff. Includes API method name (OpStateExt) for specificity. Efficiently front-loaded.

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?

Simple tool with one param and clear purpose, but lacks any description of output/returned status. 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 100%, description adds no new meaning beyond the schema's own 'description' for invId. Baseline of 3 is appropriate.

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?

Description clearly states the verb 'check', the resource 'invoice status', and the method 'by number (OpStateExt)'. It distinguishes from sibling 'create_invoice' which is for creation.

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?

Context implies use for checking existing invoices, contrasting with 'create_invoice'. No explicit when-not or alternative usage, but clear enough.

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

create_invoiceB

Создать счёт Robokassa. Возвращает ссылку на оплату с MD5-подписью.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailNoEmail покупателя для чека
invIdYesНомер счёта (уникальный ID заказа). 0 = автоматически
itemsNoПозиции чека 54-ФЗ (если нужна фискализация)
outSumYesСумма платежа в рублях
cultureNoЯзык интерфейса оплаты
descriptionYesОписание заказа (до 100 символов)
expirationDateNoСрок жизни счёта в формате ISO 8601 (например 2025-12-31T23:59:59)

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions returning a payment link with MD5 signature but fails to disclose mutation behavior, required permissions, or side effects. For a creation tool, more transparency is needed.

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 short and front-loaded, conveying the core purpose in two sentences. It effectively communicates the essential information without waste, though more detail could be beneficial.

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 7 parameters (3 required) and no output schema, the description does not explain the return structure beyond 'link with MD5 signature' or cover error handling, idempotency, or configuration needs. It feels incomplete for the complexity.

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 100%, so all parameters have individual descriptions. The tool description adds no additional meaning beyond the schema, baseline 3 is appropriate.

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 the tool creates a Robokassa invoice and returns a payment link with an MD5 signature. The verb 'create' and resource 'invoice' are unambiguous, and it distinguishes from the sibling 'check_invoice' which checks invoices.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as the sibling 'check_invoice'. It lacks context on prerequisites, typical use cases, or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.1.0
    • First observedcheck_invoice
    • First observedcreate_invoice
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one creates an invoice, the other checks its status. No overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern in snake_case: create_invoice, check_invoice.

Tool Count3/5

With only 2 tools, the surface feels thin for a payment invoice service. While it covers basic operations, it is at the lower end of the acceptable range.

Completeness3/5

The set provides create and check (read) operations but misses other lifecycle actions like cancel or refund, resulting in notable gaps for a typical payment workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • @theyahia/tkassa-mcp

    theYahia
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for T-Kassa (T-Bank/Tinkoff) payment API. Provides 16 tools for payments, refunds, recurring charges, customer management, saved cards, SBP, receipts, and T-Invest portfolio.
    60
    MIT

  • robokassa-mcp

    artgas1
    A
    license
    A
    quality
    D
    maintenance
    MCP server for the Robokassa payment gateway, enabling AI agents to create invoices, check payments, process refunds, manage recurring subscriptions, and handle fiscal receipts via natural language.
    18
    1
    MIT

  • factura-uz-mcp

    theYahia
    A
    license
    A
    quality
    D
    maintenance
    MCP server for Factura.uz electronic invoicing system (Uzbekistan). Supports creating, signing, accepting, and rejecting e-invoices, plus company and product lookups.
    8
    7
    MIT

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

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