Skip to main content
Glama
Sign In

BotSpot: AI Trading, Backtests and Bots

by io.github.grzesir
OverviewDiscussionsAdmin

Search long-term memories about the user

search_memory
Read-onlyIdempotent

Retrieve relevant prior memories about this user.

CALL search_memory at the START of any conversation where the user:

  • References past context ("like we discussed", "remember when", "last time")

  • Asks for advice that should reflect their preferences

  • Describes a trading problem where their history is relevant

  • Mentions anything you might have recorded before

Default to calling this tool more often than you think you should. It is cheap, scoped to this user only, and returning zero results is fine.

Memories are historical reports, not current selection authority. A recalled strategy/account name does not resolve an unbound "this strategy" in a new conversation. Preserve an explicit attachment or selection in this chat; otherwise discover owned candidates without a remembered-name filter and clarify ambiguity. Verify current state through its owning tools.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax memories to return. Defaults to 5.
queryYesNatural language query to find relevant prior memories. Examples: 'What strategies has the user built before?' 'Does the user prefer aggressive or conservative trading?' 'What was the user's last concern about risk?' Returns up to `limit` matching memories ordered by relevance.
filtersNoNarrow results by metadata tags. Example: {"strategy_id": "abc"} returns only memories tagged with that strategy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavioral context: results are user-scoped only, the call is cheap, empty results are acceptable, and recalled memories are historical reports rather than selection authority. The warning that a remembered name must not resolve an unbound reference, and that current state should be verified through owning tools, is exactly the kind of trait annotations cannot convey.

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?

Purpose is front-loaded, followed by a scannable bullet list of triggers and then the interpretive caveats, so the reader can stop early if needed. The 'more often than you think you should' line is colloquial but behaviorally load-bearing, and nothing is redundant enough to cut.

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 read-only search with rich annotations and fully documented parameters, the definition covers purpose, triggering conditions, cost, and result-interpretation risk. Minor gap: no indication of what a returned memory record looks like or how relevance ordering behaves, though the schema hints at the latter and there is no output schema to rely on.

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%, with query, limit, and filters each documented including examples, so the schema carries the parameter burden. The description adds nothing about query phrasing, the relationship between limit and relevance ordering, or how filter tags interact with the natural-language query, leaving it at baseline.

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?

States a specific verb and resource ('Retrieve relevant prior memories') and pins the scope to 'this user', which separates it from generic history tools like search_conversation_history. It does not name any sibling explicitly, so the differentiation comes from scope wording rather than direct routing.

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 trigger list (past-context references, preference-sensitive advice, trading problems with relevant history) plus an explicit bias toward over-calling, which is unusually actionable. It stops short of naming an alternative tool for adjacent needs such as conversation logs or data catalog lookups, leaving that inference to the agent.

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

All BotSpot: AI Trading, Backtests and Bots toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources