Skip to main content
Glama

create_transaction

Create a new transaction (income, expense, or transfer). Requires accountId, amount (decimal), transactionType, and transferNature. paymentType is optional and defaults to the default payment type of the account. For transfers, also provide destinationAccountId and destinationAmount. Use splits to categorize portions of the amount. Use originalAmount + originalCurrencyCode to record what the purchase cost in its invoice currency when that differs from the account currency. Use paymentLegs to pay one purchase from several accounts.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note or description for the transaction
timeNoTransaction date/time as ISO 8601 string. Defaults to now
amountYesTransaction amount as an unsigned decimal (e.g. 12.50). Never negative: transactionType sets the direction
splitsNoSplit the transaction across multiple categories
tagIdsNoTag IDs to assign to this transaction
payeeIdNoPayee ID to assign
accountIdYesID of the account the transaction belongs to
isPlannedNoMark the transaction as planned rather than an already-happened record
categoryIdNoCategory ID to assign to this transaction
paymentLegsNoPay this income/expense from up to 4 more accounts. Each item is either { accountId, amount } to create a part on another account, or { transactionId } to link an existing transaction as a part (its amount stays). amount is in that account's currency; when it differs from this transaction's currency also pass paymentAmount, the part's value in this transaction's currency. Not allowed for transfers, refunds, planned or category-split transactions
paymentTypeNoPayment method used. Defaults to the account's default payment type, or bankTransfer
originalAmountNoAmount in the currency the purchase was originally priced in (decimal), e.g. 66.42 for a PLN invoice paid from a UAH account. Informational only: never affects balances. Requires originalCurrencyCode
transferNatureYesTransfer type. Use not_transfer for regular income/expense
transactionTypeYesWhether this is income or expense
destinationAmountNoFor transfers: amount received in destination account (decimal, greater than 0)
destinationAccountIdNoFor transfers: destination account ID
originalCurrencyCodeNoISO 4217 code of originalAmount (e.g. "PLN"). Requires originalAmount. Cannot be combined with transfer fields
destinationTransactionIdNoFor transfers: link to an existing destination transaction instead of creating one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / paymentLegs
      Added value: +{
      +  "description": "Pay this income/expense from up to 4 more accounts. Each item is either { accountId, amount } to create a part on another account, or { transactionId } to link an existing transaction as a part (its amount stays). amount is in that account's currency; when it differs from this transaction's currency also pass paymentAmount, the part's value in this transaction's currency. Not allowed for transfers, refunds, planned or category-split transactions",
      +  "items": {
      +    "anyOf": [
      +      {
      +        "additionalProperties": false,
      +        "properties": {
      +          "amount": {
      +            "exclusiveMinimum": 0,
      +            "type": "number"
      +          },
      +          "paymentAmount": {
      +            "exclusiveMinimum": 0,
      +            "type": "number"
      +          },
      +          "transactionId": {
      +            "format": "uuid",
      +            "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "transactionId"
      +        ],
      +        "type": "object"
      +      },
      +      {
      +        "additionalProperties": false,
      +        "properties": {
      +          "accountId": {
      +            "format": "uuid",
      +            "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +            "type": "string"
      +          },
      +          "amount": {
      +            "exclusiveMinimum": 0,
      +            "type": "number"
      +          },
      +          "paymentAmount": {
      +            "exclusiveMinimum": 0,
      +            "type": "number"
      +          }
      +        },
      +        "required": [
      +          "accountId",
      +          "amount"
      +        ],
      +        "type": "object"
      +      }
      +    ]
      +  },
      +  "maxItems": 4,
      +  "type": "array"
      +}
    • changedInput schema / properties / paymentType / description
      Previous value: -"Payment method used"New value: +"Payment method used. Defaults to the account's default payment type, or bankTransfer"
    • changedInput schema / required
      Previous value: -[
      -  "accountId",
      -  "amount",
      -  "transactionType",
      -  "paymentType",
      -  "transferNature"
      -]New value: +[
      +  "accountId",
      +  "amount",
      +  "transactionType",
      +  "transferNature"
      +]
  2. Changed2 schema fields changed
    • addedInput schema / properties / note / maxLength
      Added value: +1000
    • changedInput schema / properties / splits / items / properties / note / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maxLength": 100,
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  3. Changed1 schema field changed
    • addedInput schema / properties / payeeId
      Added value: +{
      +  "description": "Payee ID to assign",
      +  "format": "uuid",
      +  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +  "type": "string"
      +}
  4. Changed6 schema fields changed
    • changedInput schema / properties / amount / description
      Previous value: -"Transaction amount as a decimal (e.g. 12.50)"New value: +"Transaction amount as an unsigned decimal (e.g. 12.50). Never negative: transactionType sets the direction"
    • addedInput schema / properties / amount / minimum
      Added value: +0
    • changedInput schema / properties / destinationAmount / description
      Previous value: -"For transfers: amount received in destination account (decimal)"New value: +"For transfers: amount received in destination account (decimal, greater than 0)"
    • addedInput schema / properties / destinationAmount / exclusiveMinimum
      Added value: +0
    • changedInput schema / properties / splits / items / properties / amount / description
      Previous value: -"Amount for this split portion (decimal)"New value: +"Amount for this split portion (decimal, greater than 0)"
    • addedInput schema / properties / splits / items / properties / amount / exclusiveMinimum
      Added value: +0
  5. First observed

TDQS

A3.5/5.0
Behavior3/5

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

The description adds some behavioral context, such as paymentType defaulting to the account's default and originalAmount being informational only. But with no annotations, it does not fully disclose mutation side effects, permissions, idempotency, or what happens on failure, leaving meaningful gaps for a create operation.

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 front-loaded with the core action and required parameters, then moves through optional and advanced scenarios. It is dense but appropriately sized for an 18-parameter creation tool, with little wasted 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?

Given the fully described schema, the description provides an adequate high-level summary of required fields, transfers, splits, original currency, and payment legs. It omits some advanced fields like isPlanned or destinationTransactionId, but the schema covers them, and no output schema needs explanation.

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 parameter documentation is already strong. The description summarizes key fields and conditional groups, but largely repeats or compresses what the schema more precisely explains; it does not add substantial semantic detail beyond the schema.

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 uses a specific verb and resource: 'Create a new transaction (income, expense, or transfer).' It clearly establishes scope and required fields, but does not explicitly differentiate this tool from siblings like update_transaction or split_transaction.

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?

Usage is implied by 'Create a new transaction' and the conditional guidance for transfers, splits, original amounts, and payment legs. However, there is no explicit guidance on when to choose this tool versus alternatives such as update_transaction, split_transaction, or create_investment_transaction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.