robokassa-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., hold_init, hold_confirm, hold_cancel are separate steps). The only potential confusion is between refund_create and partner_refund, but descriptions clarify the difference. Overall, tools are well-differentiated.
Naming Consistency4/5
Tool names predominantly follow a verb_noun pattern (e.g., build_split_invoice, create_invoice). A few deviate (hold_cancel, hold_confirm), but the naming is still predictable and readable.
Tool Count4/5
With 18 tools covering standard payments, holds, recurring, refunds, fiscal receipts, and utilities, the count is slightly high but well-justified for a comprehensive payment MCP server.
Completeness4/5
The tool surface covers core payment lifecycle operations. Missing an explicit cancel payment tool for non-hold payments, but agents can work around via states. Overall, nearly complete for the domain.
Average 3.9/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose side effects (e.g., does it create a record or just generate a link?), auth requirements, or idempotency. The behavioral context is insufficient for an unannotated tool.
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?
Two sentences with no fluff; the purpose and split structure are clearly stated. However, some structure (e.g., bullet points) could improve readability for complex splits.
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 6 parameters (0% schema coverage), no annotations, and an output schema (unused in description), the description is too minimal. It omits optional parameters, expected output format, and usage steps, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description explains out_amount and splits (including expected object structure) but ignores email, inc_curr, inv_id, and description parameters, leaving several parameters undocumented.
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 builds a URL for multi-recipient split payment, uses specific verbs ('Build'), specifies the resource ('URL'), and distinguishes from sibling tools like create_invoice by focusing on split payments.
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?
No guidance on when to use this tool vs alternatives (e.g., create_invoice). No when-not-to-use or scenario examples, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions one key behavior (releasing without capturing), but omits important details like required authentication, whether the hold ID must be valid, what happens to associated funds, or any side effects. The output schema exists but is not described.
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?
The description is a single, concise sentence that directly states the tool's purpose. No extraneous information is included.
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?
Given the tool's complexity (4 parameters, 1 required) and the presence of sibling tools for other hold operations, the description is too brief. It fails to cover prerequisites (e.g., hold must exist), state expectations, or error conditions. The output schema exists but is not referenced, leaving the agent without context on return value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no information about parameters beyond the schema. The parameters (e.g., inv_id, merchant_login) are left unexplained, forcing the agent to infer their purpose from names alone. The description should at least indicate which parameters are important and how they relate to the cancellation.
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's function: 'Release a hold without capturing the reserved funds.' It uses a specific verb ('Release') and resource ('hold'), and the action is distinct from sibling tools like hold_init (create hold) and hold_confirm (capture hold).
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 explicit guidance on when to use this tool versus alternatives like hold_confirm or hold_cancel for other holds. It does not mention prerequisites, such as requiring an active hold, or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'check the current state'. It does not disclose side effects, permissions, error handling, or rate limits. For a read-only tool, minimal disclosure is acceptable but still lacking.
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, immediately clear sentence with no extraneous information. Front-loaded with purpose.
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?
Output schema exists, so return values are covered. But the description does not mention prerequisites (must have called refund_create) or error conditions. For a simple status check, it's moderately complete.
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%, and the parameter description in schema already explains the parameter's source (GUID from refund_create). The tool description adds no additional meaning, so baseline 3.
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 it checks the state of a refund request, with a specific verb 'check' and resource 'state of a refund request'. It distinguishes from sibling tool refund_create.
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?
The description implies usage after refund_create but does not explicitly state when to use or avoid it, nor provides alternatives. It's implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only states that the tool checks status, implying a read operation, but lacks detail on side effects, permissions, error handling, or the response format. The presence of an output schema partially mitigates the lack of return value description, but the description is insufficient.
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?
The description is extremely concise: two sentences with no redundant information. The first sentence captures the purpose, and the second provides a critical usage tip, making it efficient and front-loaded.
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?
Given the tool's complexity (3 parameters, no annotations or schema descriptions), the description is too sparse. It fails to explain the `receipt_id` and `password1` parameters, nor does it cover expected behavior or edge cases. The output schema exists but the description does not reference it or provide enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must clarify parameter meanings. It only explains that `merchant_id` should be set to 'robokassa_state' for status lookups, but does not describe `receipt_id` or `password1`, leaving their roles unclear. This adds marginal value beyond 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?
The description clearly states the verb 'Check' and the resource 'registration status of a 54-ФЗ fiscal receipt', which accurately defines the tool's purpose and distinguishes it from sibling tools like second_receipt_create or refund_status.
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 provides a specific usage hint: 'Use `merchant_id="robokassa_state"` for status lookups', which guides the agent on when to use this tool. However, it does not explicitly mention when not to use it or describe alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 building a checkout URL and the post-payment usage, but does not disclose behavioral traits such as idempotency, side effects (e.g., does it create a record?), authentication requirements, or error conditions. The description is adequate for a basic understanding but lacks depth.
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?
The description is highly concise, consisting of two sentences that front-load the core action and follow up with the workflow context. Every sentence earns its place with no redundancy or filler.
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?
Given the tool's complexity (11 parameters, no annotations, 0% schema coverage), the description is insufficient. It does not explain the purpose of many parameters, usage prerequisites, or what the agent should do with the returned checkout URL. The presence of an output schema is noted but does not compensate for the missing parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 11 parameters, the description only references 'inv_id' as the invoice ID to cite. It does not explain 'out_sum', 'merchant_login', 'password1', or other optional parameters. The description adds minimal value beyond the schema, failing to compensate for the lack of parameter descriptions.
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 verb 'Build a checkout URL' and identifies the resource as a recurring parent. It also distinguishes the tool's role in the recurring payment flow, contrasting with the sibling tool 'recurring_charge' for subsequent charges. The purpose is specific and unambiguous.
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 provides implicit usage guidance by indicating the workflow: after this tool, use 'recurring_charge' for subsequent charges. However, it lacks explicit when-to-use or when-not-to-use instructions relative to other sibling tools like 'create_invoice' or 'build_split_invoice', leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses auth requirements and alternative tool but does not describe behavior beyond being a refund path (e.g., side effects, response format, or success/failure indicators). Inferred as destructive but not explicit.
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 filler, front-loaded with purpose. Every word earns its place.
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?
Output schema exists but description fails to compensate for unexplained parameters. Auth guidance is good but lacks parameter details, making the tool ambiguous for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema coverage and description provides no explanation for 5 parameters (robox_partner_id, op_key, auth_headers, refund_sum, receipt). Only vaguely references 'RoboxPartnerId' and 'auth headers' without mapping to schema names or semantics.
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 it is an 'Alternative refund path via Partner API (for CPA / SaaS integrators)' and distinguishes it from the merchant-only tool 'refund_create'. The verb 'refund' and resource 'path' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: partners only; merchant-only users should prefer 'refund_create'. Also mentions required auth headers, providing clear guidance on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits (cart reduction allowed, OutSum can be smaller) and the fundamental action of capturing, but lacks details on auth needs, rate limits, or failure behavior.
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 plus a line break; every word is necessary and efficiently conveys critical information without verbosity.
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?
Adequate for a tool with an output schema, but missing explanation of required inv_id and other optional parameters; relies on domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Provides context for two parameters (out_sum and receipt_items) but leaves five others (including required inv_id) unexplained, despite 0% schema description coverage.
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 uses specific verb 'Capture' and resource 'previously-reserved funds for a held transaction', clearly distinguishing from siblings like hold_init and hold_cancel.
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?
Clearly states when to use (to capture a held transaction) and includes constraints (cart can be reduced, pass same OutSum), but does not explicitly mention when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds behavioral context such as the paid nature and balance requirement. However, it does not disclose other behaviors like message length limits, delivery confirmation, or authentication needs for optional parameters.
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?
The description is short and front-loaded. Every sentence adds value: first defines the action, then specifies prerequisites. No unnecessary words or repetition.
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?
While output schema exists and may cover return values, the description omits important context such as how authentication works (merchant_login/password1), message encoding, and error scenarios. It somewhat compensates with balance and format info but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the phone parameter's format. Other parameters like message, merchant_login, password1, and algorithm receive no additional meaning beyond 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?
The description begins with 'Send an SMS via Robokassa's SMS service,' which clearly identifies the verb and resource. It distinguishes itself effectively from sibling tools such as check_payment or create_invoice, as none of them involve SMS sending.
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?
Explicitly states it is a paid feature requiring a non-zero SMS balance and that the phone must be in international format. This guides when to use the tool and under what conditions, though it does not explicitly mention alternatives or when not to use it beyond balance constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It explains the verification purpose but does not state what the tool returns (e.g., boolean or string) or behavior on failure. The output schema may cover this, but the description alone is incomplete.
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?
The description is very concise: two sentences that efficiently convey purpose, context, and a critical action (respond with build_ok_response). No wasted words, and the information is front-loaded.
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?
Given the tool has an output schema and three parameters with good schema descriptions, the description covers the essential context: purpose, when to use, and the required follow-up action. It lacks explicit distinction from sibling and return value details, but is largely complete.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by specifying that 'params' must contain OutSum, InvId, SignatureValue, and that Shp_* parameters are automatically incorporated. It also explains the fallback for 'password2'. This enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool verifies the SignatureValue on a Robokassa ResultURL request, using specific verbs and resources. It does not explicitly differentiate from the sibling 'verify_success_signature', but the context of payment notifications is distinct enough.
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 provides clear context: use this tool upon receiving a POST to the ResultURL after checkout. It also explains the necessity of responding with `build_ok_response(inv_id)` to avoid retries, giving actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the tool does NOT make an HTTP request but produces a URL for redirecting, which is transparent about the side-effect. However, it does not mention authentication requirements or rate limits that might be relevant.
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?
The description is extremely concise: two sentences with no wasted words. It front-loads the main action and adds a critical caveat about not making an HTTP request. Every sentence earns its place.
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?
Given the output schema exists, the description is not required to detail return values. It does mention that it produces a URL and form fields, which aligns with the output. However, given the tool has 13 parameters, a bit more context about prerequisites or error states could be helpful.
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 the baseline is 3. The description adds minimal extra meaning beyond 'builds a signed URL and form fields'. It does not elaborate on any parameters, but the schema already provides comprehensive descriptions for each.
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 it builds a signed checkout URL and form fields for a new payment. Distinguishes from sibling tools by noting it does not make an HTTP request, which contrasts with tools like check_payment or hold_init that likely perform actual API calls.
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?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for creating a payment URL, but no guidance on when not to use it or mention of sibling tools like hold_init for card binding. Lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the max receipts constraint and provides typical field structures. However, it omits failure modes, idempotency, and permission requirements.
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 concise and front-loaded with the purpose. It uses bullet points for items/payments/client format, making it easy to scan. No wasted words.
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?
Given 11 parameters (8 required) with nested objects, the description provides useful context for some but not all. Output schema exists, so return values are covered; however, parameter explanations are incomplete for a 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 coverage is 0%, so description adds meaning for 'merchant_id', 'origin_id', 'items', 'payments', and 'client' via examples. But it does not explain 'receipt_id', 'total', 'url', 'password1', 'sno', or 'vats', which are required or optional.
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 verb ('Emit') and resource ('final fiscal receipt'), with the specific context of 54-ФЗ and advance/prepayment sale. It distinguishes from siblings like 'second_receipt_status' which likely checks status.
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 specifies it's for merchants using Robokassa Fiscal and mentions max 2 receipts per operation. It gives typical examples for payments and client, but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains that the calculation uses a configurable algorithm and fallbacks to environment variables, which is helpful. However, it does not mention return format, side effects, or whether it makes external calls.
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?
The description is succinct: two sentences plus a signature line. The most critical information (what it does, when to use, how parameters relate) is front-loaded. No unnecessary words.
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?
Given the output schema exists (return values are covered), the description adequately covers purpose, usage, and signature details. It lacks information about error handling or idempotency, but for a calculation tool this is acceptable.
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?
The schema already covers all 5 parameters. The description adds value by explaining the signature formula and fallback behavior for merchant_login and password1, which is not in the schema. This extra context aids correct parameter usage.
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's purpose: calculating the amount credited to the shop for a customer payment. It also provides context ('useful for showing the commission / final sum in checkout UI'), making it distinct from sibling tools like check_payment or verify_signatures.
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 gives a usage scenario (checkout UI) and includes the signature algorithm format, which guides proper invocation. However, it does not explicitly state when not to use this tool or how it differs from similar tools like check_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: funds reservation, 7-day max hold window, notification to ResultURL2, requirement for prior agreement, and card-only restriction.
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?
Three concise sentences, no redundant information, front-loaded with core action and usage flow.
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?
Covers usage flow, constraints, and prerequisites well. Despite lacking parameter details, the description is fairly complete given the presence of an output schema and the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of any parameter (e.g., out_sum, inv_id). It mentions StepByStep=true but that is not a schema parameter, leaving the 11 parameters undocumented.
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 explicitly states the tool builds a checkout URL with StepByStep=true for two-step pre-auth, and distinguishes itself from siblings hold_confirm and hold_cancel by mentioning their roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear guidance: use hold_confirm to capture or hold_cancel to release. Also notes prerequisite (prior agreement) and payment method restriction (card only), providing explicit when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully carries the burden. It discloses that the charge is 'silent' and that 'OK<InvId>' means accepted but not captured, which is a critical behavioral trait. It also directs verification via check_payment.
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 concise sentences with no wasted words. The first sentence states the purpose, the second adds critical usage details. The response format and verification step are clearly 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?
While the description covers the core usage (prerequisite, response meaning, verification), it omits documentation for most parameters. The output schema may explain return values, but the description does not address authorization, idempotency, or other behavioral aspects. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 9 parameters (3 required), the description only clarifies previous_inv_id. It does not explain new_inv_id, out_sum, description, merchant_login, password1, receipt_items, receipt_sno, or algorithm, leaving their semantics to the agent.
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 action ('Silently charge a recurring subscription payment') and distinguishes it from sibling tools like init_recurring_parent and check_payment, which are referenced for prerequisite and follow-up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (previous_inv_id must be from an already-paid parent) and provides follow-up guidance (verify via check_payment). Also explains the response meaning and what it does NOT imply (capture).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It details the operation (OpStateExt XML interface), returned fields, state codes, and credential requirements. However, it does not explicitly state it is read-only, though 'check' implies it.
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?
Description is well-structured with a clear opening, bulleted state codes, and a valuable note section. No redundant information.
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 the output schema exists (not shown), the description sufficiently covers return values, state codes, and credential handling. Provides necessary context for using this tool effectively.
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?
Description mentions invoice ID and credentials but does not explain the algorithm parameter. With 0% schema coverage, more detailed parameter descriptions would improve clarity.
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 it checks the current state of a Robokassa payment by invoice ID, distinguishing it from sibling tools like refund_status and hold-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes when not to use this tool (for post-payment refunds) and directs to Refund/GetState as an alternative. Also explains state code 60 is not user-initiated refund.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears full responsibility. It discloses that the endpoint is public, requires no auth, and returns data grouped by payment family with specific fields. This is sufficient for a read-only listing tool.
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?
The description is concise and well-structured, with a clear opening sentence followed by supporting details. Every sentence adds value, and it is properly front-loaded.
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 the output schema is present, the description does not need to explain return values. It covers purpose, usage hints, authentication requirements, and input parameter details, making it complete for a simple listing tool.
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?
The schema covers both parameters with 100% coverage. The description adds extra context: `merchant_login` can fall back to an environment variable, and `language` affects the `Name` fields. This enhances understanding beyond 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?
The description clearly states 'List payment methods / currencies available to a Robokassa shop.' It uses a specific verb and resource, and from the sibling list, it is distinct from tools that create or modify invoices or payments.
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 provides context linking the Label values to the `IncCurrLabel` parameter of `create_invoice`, indicating when this tool is useful. It also notes that no password/signature is required, but it does not explicitly mention when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains that verifying the signature guards against CSRF/tampering and clarifies the semantic meaning of a successful verification (user returned to success page, not payment credited). While it doesn't explicitly state it's read-only, the verification nature implies no side effects. The context about SuccessURL vs ResultURL adds important behavioral insight.
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?
The description is a short paragraph with no wasted words. It is front-loaded with the purpose and provides critical context (SuccessURL vs ResultURL) efficiently. Every sentence earns its place.
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 the tool's complexity (signature verification with two URL types) and the presence of an output schema (context signals indicate true), the description provides complete context: it explains the purpose, the semantic difference from ResultURL, and the security benefit. The agent has enough information to use the tool correctly.
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 baseline is 3. The description does not add significant new meaning beyond the schema's parameter descriptions (e.g., 'params' as query-string params, 'password1' fallback to env var). The schema already explains the parameters adequately, and the description's value is primarily in usage context rather than parameter semantics.
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 verb 'Verify' and the specific resource 'SignatureValue on a Robokassa SuccessURL redirect'. It distinguishes this tool from the sibling verify_result_signature by explaining the difference between SuccessURL and ResultURL, ensuring correct selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for the browser-side SuccessURL redirect after payment) and contrasts it with ResultURL, noting that it does not confirm payment crediting. This provides clear guidance on when to use this tool versus alternatives like verify_result_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![robokassa-mcp MCP server](https://glama.ai/mcp/servers/artgas1/robokassa-mcp/badges/card.svg)](https://glama.ai/mcp/servers/artgas1/robokassa-mcp)

Score Badge

Copy to your README.md:

[![robokassa-mcp MCP server](https://glama.ai/mcp/servers/artgas1/robokassa-mcp/badges/score.svg)](https://glama.ai/mcp/servers/artgas1/robokassa-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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