Skip to main content
Glama

Manawa Terminal

Edit portfolio order

edit_order

Change an open portfolio order. Use this before cancel_order.

Attach or replace the 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. An empty library_item_id
removes the case. The accept card and the book show it.

qty, price, expires_kind (day, gtc, or delete_after), expires_at,
after_hours, and library_item_id. Send only the fields that change.
Rules still apply. HIL on,
or an order above Skip HIL up to, opens the accept card again. A day
order needs an open session. A good till that lasts past the next open
can stay open while the session is closed.

Args:
    portfolio_id: The portfolio UUID
    order_id: The order UUID
    qty: New share count
    price: New price, or the new limit
    expires_kind: day, gtc (90 days), or delete_after
    expires_at: Required with delete_after. Naive times are New York.
    after_hours: Extended session for a stock or ETF
    library_item_id: The investment case. The document id from search_library
        (item_id) or list_library_items (id). Not the title. An empty string removes the case.

Input Schema

NameRequiredDescriptionDefault
qtyNo
priceNo
order_idYes
expires_atNo
after_hoursNo
expires_kindNo
portfolio_idYes
library_item_idNoInvestment case to attach or replace. Pass the document id, not the title. search_library returns it as item_id. list_library_items returns it as id. An empty string removes the case.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / library_item_id / description
      Added value: +"Investment case to attach or replace. Pass the document id, not the title. search_library returns it as item_id. list_library_items returns it as id. An empty string removes the case."
  2. Changed1 schema field changed
    • addedInput schema / properties / library_item_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Library Item Id"
      +}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, closed-world; the description adds real value beyond that by disclosing that an empty library_item_id removes the case, that HIL may reopen the accept card, and that a day order requires an open session. The HIL sentence is garbled ("HIL on, or an order above Skip HIL up to"), so the most consequential behavioral note is not fully actionable.

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?

Front-loads the core action well, but library_item_id is explained twice (body and Args) and the HIL/session paragraph reads as fragmented prose rather than structured rules. The garbled HIL clause and repeated parameter listing cost space without adding clarity.

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 2-required/8-optional mutation tool with an output schema, the description covers the parameter surface, session prerequisites, and HIL re-confirmation. It leaves ambiguous what happens on partial failures or how the reopened accept card affects the call's return, which matters for a mutation.

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 coverage is only 13%, but the description compensates thoroughly: it explains expires_kind values (day, gtc 90 days, delete_after), that expires_at is required with delete_after and naive times are New York, and that after_hours is for stocks/ETFs. The library_item_id doc-id-vs-title trap and the empty-string removal semantics are spelled out explicitly.

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?

States a specific verb and resource ("Change an open portfolio order") and explicitly positions it relative to cancel_order and search_library/list_library_items. An agent can tell it apart from the cancel sibling without opening either schema.

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?

Gives a concrete sequencing rule ("Use this before cancel_order") and the key operating constraint ("Send only the fields that change"). It implies rather than spells out the full decision rule (e.g., when to edit vs. cancel and re-place), so it falls just short of exhaustive.

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