Skip to main content
Glama

Manawa Terminal

Add portfolio transaction

add_transaction

Add a buy, sell, deposit, withdrawal, dividend, short, or cover to a portfolio.

Attach an investment case with library_item_id. That is the document id.
search_library returns it as item_id. list_library_items returns it as id.
Pass the id, not the title. The accept card and the transaction row show
the case. Leave library_item_id empty when there is no case.

A buy, sell, short, or cover is a portfolio order. Call get_portfolio_rules
first and size it to those rules. filled means the book took it. pending
means the card is open: do not ask again and do not send a second order.
A refused error is a portfolio rule. Do not shrink the order. Dividend,
deposit, and withdrawal still record a transaction immediately.

order_type market ignores price and uses the live price. With HIL on, or
the order above Skip HIL up to, the card opens at that live price. HIL
off, or under the skip, fills. A past date records that day's average.
A future date is refused. order_type limit requires price. The card opens
before the limit rests when HIL requires it. Accept arms it. The card
does not open again when the price hits. A past date records the price
after that day's range check.
expires_kind is gtc (90 days), day, or delete_after. delete_after needs
expires_at. after_hours lets a stock or ETF print in the extended session.
on_touch review wakes you when the limit hits so you can look and then
submit. on_touch direct applies the book rules then, with no second look.
A hard limit still refuses. HIL still opens the card for a resting limit.

A short names the stock. qty is the shares sold short. price is the sale
price per share. A cover names the stock. qty is the shares bought back.
price is the price per share. Neither uses $CASH. A short while long, a
cover larger than the short, a sell larger than the long, and a buy while
short come back as the terminal's 400. Do not rewrite that error into a success.

A dividend names the stock, not $CASH. qty is the shares, price is the
amount per share and must be greater than 0, and date is the pay date.
Cash increases on a long and decreases on a short. The share count does
not change. The open cost of a long drops by the part still held. A
short's open credit shrinks. The closed slice is realized P&L.

Args:
    portfolio_id: The portfolio UUID
    symbol: Stock symbol (e.g. "AAPL"). For deposit/withdrawal use "$CASH"
        (aliases "CASH" / blank are normalized to "$CASH").
    side: "buy", "sell", "deposit", "withdrawal", "dividend", "short", or "cover"
    qty: Number of shares (or cash amount for deposit/withdrawal)
    price: Price per share. Required for a limit, a dividend, and cash. Omit it for a market.
    date: Trade date, or the dividend pay date (YYYY-MM-DD). Today or a past date.
    order_type: market or limit. Market uses the live price today and the day's average in the past.
    limit_price: Resting price. Omit it when order_type is set; price is used.
    expires_kind: gtc, day, or delete_after. Used with a limit.
    expires_at: End time when expires_kind is delete_after.
    after_hours: Allow the extended stock and ETF session.
    on_touch: review or direct. Used with a limit. Default is review.
    library_item_id: The investment case. The document id from search_library
        (item_id) or list_library_items (id). Not the title. Omit when there is no case.
    strategy_id: Strategy UUID from list_strategies. Tags this order on that
        strategy's activity. Omit when the order is not part of a strategy.

Input Schema

NameRequiredDescriptionDefault
qtyYes
dateYes
sideYes
priceNo
symbolYes
on_touchNo
expires_atNo
order_typeNo
after_hoursNo
limit_priceNo
strategy_idNoStrategy this order belongs to. UUID from list_strategies. Omit when the order is not part of a strategy.
expires_kindNo
portfolio_idYes
library_item_idNoInvestment case to attach. Pass the document id, not the title. search_library returns it as item_id. list_library_items returns it as id. Omit when there is no case.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / strategy_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Strategy this order belongs to. UUID from list_strategies. Omit when the order is not part of a strategy.",
      +  "title": "Strategy Id"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / library_item_id / description
      Added value: +"Investment case to attach. Pass the document id, not the title. search_library returns it as item_id. list_library_items returns it as id. Omit when there is no case."
  3. Changed1 schema field changed
    • addedInput schema / properties / library_item_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Library Item Id"
      +}
  4. Changed5 schema fields changed
    • addedInput schema / properties / order_type
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Order Type"
      +}
    • addedInput schema / properties / price / anyOf
      Added value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / price / default
      Added value: +null
    • removedInput schema / properties / price / type
      Removed value: -"number"
    • changedInput schema / required
      Previous value: -[
      -  "portfolio_id",
      -  "symbol",
      -  "side",
      -  "qty",
      -  "price",
      -  "date"
      -]New value: +[
      +  "portfolio_id",
      +  "symbol",
      +  "side",
      +  "qty",
      +  "date"
      +]
  5. Changed5 schema fields changed
    • addedInput schema / properties / after_hours
      Added value: +{
      +  "default": false,
      +  "title": "After Hours",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / expires_at
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Expires At"
      +}
    • addedInput schema / properties / expires_kind
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Expires Kind"
      +}
    • addedInput schema / properties / limit_price
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Limit Price"
      +}
    • addedInput schema / properties / on_touch
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "On Touch"
      +}
  6. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnly=false and destructive=false, so the description carries real weight and does: filled vs pending semantics, idempotency guidance, "A refused error is a portfolio rule. Do not shrink the order... Do not rewrite that error into a success," future dates refused, HIL/limit card behavior, and concrete side effects (cash rises on a long dividend, share count unchanged, open cost reduced). That is well beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose and ends with an Args block, but the middle is ~500 words of dense prose that repeats short/cover and dividend rules already restated in the Args list. Several sentences are garbled or hard to parse ("the order above Skip HIL up to," "records the price after that day's range check"), so size and phrasing cost it.

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 14-parameter, high-stakes mutation with thin schema docs and an output schema that covers returns, the description supplies nearly everything needed: date format, ordering preconditions, asset-class rules, and error semantics. Residual ambiguity remains around price being described as required while the schema marks it optional, and how to recover from a rejected order other than not retrying.

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?

With schema coverage at 14% and zero enums declared, the description is the only source of allowed values, and it supplies them all: side (buy/sell/deposit/withdrawal/dividend/short/cover), order_type (market/limit), expires_kind (gtc/day/delete_after), on_touch (review/direct), plus per-param meanings such as $CASH for deposits and expires_at only under delete_after. It also clarifies the awkward price-vs-limit_price relationship.

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 opening sentence names the specific verb and resource (add a transaction to a portfolio) and enumerates the exact side values it supports, so an agent can distinguish it from edit_order or cancel_order without inspecting the schema. The document-attachment and order-type paragraphs stay on the same subject.

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?

It gives explicit preconditions and sibling pointers: "Call get_portfolio_rules first and size it to those rules," use search_library/list_library_items to obtain the case id, list_strategies for strategy_id, and "do not send a second order" when pending. It never says when to use edit_order or cancel_order instead, which is the only routing gap.

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.

Resources