Skip to main content
Glama

AgentPay (Russia)

by io.github.zapnikita95
OverviewDiscussionsAdmin

get_payment_status

Read-only

Check whether the last top-up/payment succeeded. Call after create_topup_intent, after a failed purchase, or when the user asks «оплата прошла», «списали карту». Returns paid, payment.status, latest topups, autoTopup.usedToday/remainingToday (max 3 auto-topups per day). If status is pending or succeeded, do not create another payment. If AGENTPAY_API_KEY required and you already have sessionId from this chat: pass sessionId and retry. Never begin_agent_link again. Never ask the owner to edit connector settings or reconnect. Never web-search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdNoOptional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to open Authorization settings (Grok has none).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / sessionId
      Added value: +{
+  "description": "Optional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to open Authorization settings (Grok has none).",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • removedInput schema / properties / sessionId
      Removed value: -{
-  "description": "Optional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to open Authorization settings (Grok has none).",
-  "type": "string"
-}
  3. Changed1 schema field changed
    • changedInput schema / properties / sessionId / description
      Previous value: -"Optional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to reconnect."New value: +"Optional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to open Authorization settings (Grok has none)."
  4. Changed1 schema field changed
    • addedInput schema / properties / sessionId
      Added value: +{
+  "description": "Optional. Agent-link sessionId from begin_agent_link / poll_agent_link. Pass on every tool when connector has no Authorization Bearer (Grok/ChatGPT/Claude). After status=approved this authenticates as als_<sessionId>. Never invent a sessionId. Never ask the owner to reconnect.",
+  "type": "string"
+}
  5. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations mark this as read-only (readOnlyHint=true) and the description confirms a read operation. It additionally discloses return fields, the daily auto-topup cap (max 3), and procedural constraints around sessionId and connector settings, enriching behavior awareness beyond annotations.

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 front-loads purpose, follows with triggers, then return values, then conditional instructions and prohibitions. Every sentence is purposeful and non-redundant; despite length, it is efficiently structured for an agent.

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?

For a read-only status-check tool with one optional parameter and no output schema, the description is complete: it specifies return fields, behavior on pending/succeeded, usage triggers, sessionId handling, and multiple never-do actions. An agent has everything required to invoke it correctly.

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?

The single optional sessionId parameter is fully described in both schema and description. The description adds crucial context: when to pass it (no Authorization Bearer), what it authenticates after approved, and explicit prohibitions (never invent, never ask owner to edit settings), making the parameter semantics richer than the schema alone.

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 opens with a specific verb and resource: 'Check whether the last top-up/payment succeeded.' It then lists exact trigger conditions (after create_topup_intent, after a failed purchase, or when the user asks specific phrases), distinguishing it from siblings like get_purchase_status and create_topup_intent by context rather than explicit sibling naming.

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 call ('Call after create_topup_intent, after a failed purchase, or when the user asks...') and what action to avoid ('If status is pending or succeeded, do not create another payment.'). It also gives conditional retry guidance for sessionId and strong prohibitions ('Never begin_agent_link again,' etc.), providing clear when-to/when-not-to guidance.

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

All AgentPay (Russia) toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources