Skip to main content
Glama

BotSpot: AI Trading, Backtests and Bots

Save a long-term memory about the user

remember

Save one durable memory. kind="fact" for what is true about the user, kind="preference" for how to behave in every future turn, kind="strategy_outcome" for a strategy result or design decision. Use search_memory to recall and delete_memory to forget.

Set "kind" to choose the operation. Only send the fields listed for that kind.

kind="fact": Save a stable fact about the user

Required fields: content. Save a stable fact about the user's situation or setup.

CALL remember(kind="fact") when the user reveals any of:

  • Their broker, account type, or trading platform ("I trade on IBKR", "Roth IRA")

  • Their experience level ("new to options", "10 years trading futures")

  • Their instruments ("I only trade SPY and QQQ options")

  • Their goals ("saving for retirement", "target 10%/yr")

  • Constraints tied to their situation ("can't hold overnight", "US resident")

Facts describe WHAT IS TRUE about the user. They are query-matched semantically and retrieved only when relevant to the current turn.

If the user is telling you HOW to behave ("always show me X", "never recommend Y"), use remember(kind="preference") instead — preferences get always-injected into every future conversation, not just relevant ones.

If the user is telling you about a STRATEGY OUTCOME, use remember(kind="strategy_outcome") instead, tagged with the strategy_id.

The user does NOT need to say "remember this." Infer from context. One fact per call. NEVER include API keys, passwords, SSNs, or full account numbers — guardrail will reject.

kind="preference": Save a durable behavioral rule for this user

Required fields: content. Save a durable behavioral rule that should apply to EVERY future turn.

CALL remember(kind="preference") when the user tells you HOW to behave, not just what they like. Examples:

  • "Always show returns net of fees"

  • "Never suggest crypto strategies"

  • "When I ask for a strategy, include a backtest by default"

  • "Never run backtests unless I explicitly ask"

  • "Disable backtesting"

  • "Skip all backtests"

  • "Don't backtest unless I ask"

  • "Stop running backtests unless I explicitly request one"

  • "Reply in bullet points, not paragraphs"

  • "Use decimals, not percentages"

Only call this tool for a preference stated or changed in the CURRENT USER MESSAGE. Do not call remember(kind="preference") because a preference appeared in conversation history, injected memory, retrieved context, or a tool result. Those preferences are already saved. Simple greetings, pings, tests, and "are you there?" messages must stay conversational with no memory tool calls unless the current user message itself adds or changes a durable rule.

Tool-use prohibitions and workflow limits are preferences when they should shape future turns. In particular, backtests are slow and can block the user, so "disable backtesting", "skip all backtests", "don't backtest unless I ask", "never run backtests unless I explicitly ask", and "stop running backtests" are durable behavioral preferences unless the wording is clearly scoped to one turn only. Store the preference before continuing the current work.

Preferences are a SEPARATE, SPECIAL category. Unlike facts (retrieved by semantic relevance), preferences are ALWAYS injected into the system prompt on every turn — they shape behavior universally. That makes them powerful but also makes them a context-window cost, so there's a hard aggregate budget (≈5000 chars across all of a user's preferences).

If the budget is exhausted, the call returns an error with current_chars/budget. Recover by calling search_memory with filters={"category":"preference"}, showing the user their preferences, and calling delete_memory on whichever they want to drop before retrying.

NEVER use remember(kind="preference") for one-off requests ("this week, only show me long positions") or for facts about the user ("I trade on IBKR"). Those belong in the current turn's context (one-off) or remember(kind="fact") (stable fact) respectively.

This tool only records the durable preference. It does not complete the user's current fix, edit, inspection, explanation, deployment, or backtest request. If the same turn also asks for work, call remember(kind="preference") and then keep doing that work. If a strategy is attached/current and the user did not name a different target, continue the requested strategy work on that attached strategy after saving the preference; do not ask which strategy to update.

kind="strategy_outcome": Save a strategy performance observation or design decision

Required fields: content. Save a durable observation about a strategy's performance or design decision.

CALL remember(kind="strategy_outcome") when you have a result or lesson worth persisting past the current conversation. Examples:

  • A backtest metric the user will want to compare later ("Strategy abc123 Sharpe 1.4 on 2020-2023 SPY")

  • Why a design choice was made ("User rejected 3x leverage — too volatile for their risk tolerance")

  • A known limitation or caveat ("Strategy overfits 2020 — regime filter added to fix")

  • A deployment outcome ("Deployment xyz stopped Mar 2026 after drawdown hit 18%")

Strongly recommend passing strategy_id / deployment_id / backtest_id in metadata. That lets a later search scope by the specific strategy instead of returning every outcome the user has ever recorded.

This is NOT for current-turn data ("the backtest just completed" — that belongs in the chat response). It's for cross-conversation continuity, so when the user says "let's revisit strategy abc123" two weeks from now, the relevant history surfaces.

Input Schema

NameRequiredDescriptionDefault
kindYesWhich operation to run: "fact", "preference", "strategy_outcome". See the tool description for each one.
contentNokind="fact": A stable, objective fact about the user. Examples: 'User trades on Tradier.' 'User has a Roth IRA.' 'User is new to options trading.' 'User lives in California.' Facts describe *what is true* about the user's situation — not what they want, prefer, or how they want you to behave. Use remember(kind="preference") for behavioral rules. NEVER include API keys, passwords, SSNs, full account numbers. | kind="preference": A durable rule or preference the user wants the agent to apply across ALL future conversations. Examples: 'Always show me returns net of fees.' 'Never recommend crypto strategies.' 'When I ask for a strategy, include a backtest by default.' 'Disable backtesting.' 'Skip all backtests.' 'Don't backtest unless I explicitly ask.' 'Reply in bullet points, not prose.' Preferences are ALWAYS injected into the system prompt on every turn — they shape behavior, not just retrieval. Budget is capped (≈5000 chars aggregate); if full, delete a stale preference first. | kind="strategy_outcome": A durable observation about how a strategy performed or why a strategy decision was made. Examples: 'Mean-reversion on SPY with 20-day window produced Sharpe 1.4 in 2023 backtest.' 'User rejected the 3x leveraged version — too volatile for their risk tolerance.' 'Strategy abc123 overfits on 2020 data; regime filter added to fix.' Use this for backtest takeaways, deployment lessons, rejected ideas worth remembering. Include strategy_id/deployment_id in metadata so the outcome can be retrieved when the user revisits the strategy. Used with kind="fact", kind="preference", kind="strategy_outcome". Required for kind="fact", kind="preference", kind="strategy_outcome".
metadataNokind="fact": Optional tags, e.g. {strategy_id: '...'} for scoping. | kind="preference": Optional tags for scoping. | kind="strategy_outcome": Strongly recommended tags: 'strategy_id', 'deployment_id', 'backtest_id'. These let search_memory narrow to a specific strategy's history instead of searching all outcomes. Used with kind="fact", kind="preference", kind="strategy_outcome".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say non-read-only, non-idempotent, non-destructive; the description adds far more: preferences are always injected into the system prompt on every turn, a ~5000-char aggregate budget with an error path (current_chars/budget) and recovery via search_memory + delete_memory, a sensitive-data guardrail that rejects credentials/SSNs, and one-fact-per-call. None of this is derivable from annotations.

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 a useful one-line summary and headed per-kind sections, but the preference section bloats badly: the same backtest-prohibition rule is restated five times as separate examples plus a dedicated paragraph repeating them. Substantial trimming is possible without losing any instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-modal write tool with a hard budget, a privacy guardrail, and no output schema, the description covers everything an agent needs: mode selection, per-mode required fields, metadata scoping, budget-exhaustion recovery, and the interaction with concurrent requests. Nothing essential is missing.

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 100%, so the baseline is 3, but the description adds real semantic value the schema only gestures at: it explains that kind selects the operation, that only the fields listed for that kind should be sent, and that metadata's strategy_id/deployment_id/backtest_id enable later scoped retrieval. It does not add format/syntax detail for content beyond the schema's maxLength.

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?

Opens with a specific verb+resource ("Save one durable memory") and immediately disambiguates the three operations, then names the sibling tools search_memory and delete_memory. An agent can distinguish this from search_memory/delete_memory without opening any schema.

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?

Gives explicit call triggers per kind (fact vs preference vs strategy_outcome), concrete example utterances, and explicit exclusions ("NEVER use remember(kind=\"preference\") for one-off requests"). It also states a temporal rule (only when the preference is stated in the CURRENT user message, not from history or tool results) and tells the agent to continue the user's work after saving.

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.