Skip to main content
Glama
iaptic

Iaptic MCP Server

Official
by iaptic

transaction_get

Retrieve detailed transaction information including status, amount, payment method, associated purchase, and customer data with a transaction ID.

Instructions

Get detailed information about a specific transaction.

  • Returns complete transaction details including:

    • Transaction status

    • Amount and currency

    • Payment method details

    • Associated purchase information

    • Customer information

    • Timestamps and audit data

  • Required: transactionId parameter

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transactionIdYesUnique identifier of the transaction

Implementation Reference

  • The handler function that executes transaction_get logic. It calls this.api.getTransaction() with the transactionId and optional appName, returning the transaction details as a formatted JSON string.
    case 'transaction_get':
      const transaction = await this.api.getTransaction(args.transactionId, { appName: args.appName });
      return {
        content: [{
          type: "text",
          text: JSON.stringify(transaction, null, 2)
        }]
      };
  • The input/output schema definition for transaction_get. Defines transactionId (required) and optional appName (required when using master key).
          {
            name: "transaction_get",
            description: `Get detailed information about a specific transaction.
    - Returns complete transaction details including:
      - Transaction status
      - Amount and currency
      - Payment method details
      - Associated purchase information
      - Customer information
      - Timestamps and audit data
    - Required: transactionId parameter${appNameRequired ? '\n- Requires appName parameter when using master key' : ''}`,
            inputSchema: {
              type: "object",
              properties: {
                transactionId: { 
                  type: "string", 
                  description: "Unique identifier of the transaction" 
                },
                ...(appNameRequired ? {
                  appName: {
                    type: "string",
                    description: "Name of the app to fetch data from. Required when using master key."
                  }
                } : {})
              },
              required: appNameRequired ? ["transactionId", "appName"] : ["transactionId"]
            }
  • src/server.ts:71-82 (registration)
    Registration of all tools including transaction_get via ListToolsRequestSchema handler which calls TransactionTools.getTools() to expose the tool definition.
      return {
        tools: [
          ...this.tools.customers.getTools(),
          ...this.tools.purchases.getTools(),
          ...this.tools.transactions.getTools(),
          ...this.tools.statistics.getTools(),
          ...this.tools.stripe.getTools(),
          ...this.tools.events.getTools(),
          ...this.tools.app.getTools()
        ]
      };
    });
  • src/server.ts:96-97 (registration)
    Routing registration: when a tool name starts with 'transaction_', the call is routed to TransactionTools.handleTool() which dispatches to the correct case including 'transaction_get'.
    if (name.startsWith('transaction_')) {
      return await this.tools.transactions.handleTool(name, args);
  • The API helper method that makes the actual HTTP GET request to /transactions/{transactionId} on the Iaptic API (validator.iaptic.com/v3).
    async getTransaction(transactionId: string, params?: { appName?: string }) {
      const response = await this.client.get(`/transactions/${transactionId}`, { params });
      return response.data;
    }
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 lists the types of information returned (status, amount, payment method, etc.) and notes it is a read operation. It does not mention error behavior or missing transaction cases.

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 bullet points. It conveys essential information without extraneous text.

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?

For a simple tool with one parameter, the description adequately covers the returned data fields. It lacks details on error conditions or response structure, but these are not critical given the simplicity.

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 is already clear. The description adds no additional meaning beyond restating the parameter requirement, which is already in 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 'Get detailed information about a specific transaction' with a specific verb and resource. It distinguishes from sibling tools like transaction_list (which lists transactions) and purchase_get (which gets purchases).

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 requires the transactionId parameter, indicating when to use the tool. It implies context for a single transaction retrieval but does not explicitly state when not to use it or mention alternatives.

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/iaptic/mcp-server-iaptic'

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