Skip to main content
Glama
LuxAlgo

LuxAlgo Library MCP

Official
by LuxAlgo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Annotate a journal trade

journal_update_trade
Idempotent

Update a trade's journal annotations, including notes, tags, mistakes, playbook, rating, stop loss, profit target, and review status, without altering fills, prices, or P&L.

Instructions

Annotate a trade — the user-owned fields only: notes (free text about this trade), tags, mistakes, playbookId, rating 1–5, stopLoss and profitTarget (price levels; the stop is what realized R is measured against) and reviewed. tags/mistakes replace the whole list; use addTags/removeTags/addMistakes/removeMistakes to change a few entries without clobbering the rest (check journal_list_tags for the user's existing words). Pass null to clear a field. Does not touch fills, prices or P&L — those derive from the fills. Returns the updated trade in full. Requires signing in with a LuxAlgo account (OAuth).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesThe trade's `key` exactly as returned by journal_list_trades, journal_get_day, journal_search_notes or journal_add_trade. Never construct one.
tagsNo
notesNoReplaces the trade's note text; null clears it.
ratingNoExecution quality 1–5; null clears it.
addTagsNoTags to add (existing ones are kept; case-insensitive duplicates are ignored).
mistakesNo
reviewedNoMark the trade reviewed (true) or not (false).
stopLossNoPlanned stop price; null clears it.
playbookIdNoPlaybook / setup name this trade followed; null clears it.
removeTagsNoTags to remove (case-insensitive).
addMistakesNoMistakes to add.
profitTargetNoPlanned target price; null clears it.
removeMistakesNoMistakes to remove (case-insensitive).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds that fields are user-owned only, that fills/prices/P&L are immutable, and that OAuth with a LuxAlgo account is required. It doesn't disclose failure modes or what happens on partial updates beyond the null-clear rule.

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-loaded with the verb, but the enumerations of field names and the parenthetical asides make it dense and run-on. Every sentence carries information, but the wall-of-prose format hurts scannability.

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 13-parameter mutation tool with no output schema, it covers the key semantic distinctions (replace vs. add/remove, null clears, auth required, derived fields untouched). It could note the return shape or idempotency behavior more explicitly, but it's nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 85%, so the baseline is 3. The description adds the semantic distinction that tags/mistakes are wholesale replacements vs. the add/remove variants, and clarifies that stopLoss is the reference for realized R — meaning beyond the schema's terse field descriptions.

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 ('Annotate a trade') and enumerates exactly which fields are user-owned vs. derived. It explicitly distinguishes itself from sibling tools like journal_update_note by scoping to trade-level fields.

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?

Explicitly tells the agent when to use addTags/removeTags/addMistakes/removeMistakes instead of tags/mistakes, warns against combining them, and points to journal_list_tags for existing vocabulary. This is actionable routing guidance.

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

Deploy Server

Other Tools