Skip to main content
Glama

Save to agent memory

memory_save
Idempotent

Remember something, with its sources and its knowledge time.

    Nothing is ever overwritten: saving a `factor_def` or `watchlist` under an existing key
    SUPERSEDES the previous version (both rows survive, so "what did I believe in June?" stays
    answerable), and saving identical content twice is a no-op rather than a duplicate.

    Args:
        kind: 'query' | 'factor_def' | 'watchlist' | 'finding' | 'note'.
        content: the thing to remember, as an object.
        key: the stable name — REQUIRED for 'factor_def' and 'watchlist' (that is what makes a
            definition reusable next session instead of re-invented).
        as_of: the knowledge time this memory is about. Recall can bound on it, which is what
            keeps a memory from leaking the future into a point-in-time question.
        source_query_ids: the `twmd_q_…` ids behind this. REQUIRED for 'finding' — a conclusion
            that cannot point at its data is not evidence, and will be refused.
        agent_id: optional label for which of your agents wrote this.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
kindYes
as_ofNo
contentYes
agent_idNo
source_query_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
hintNo
kindNo
as_ofNo
errorNo
activeNo
reasonNo
blockedNo
memory_idNo
created_atNo
superseded_byNo
source_query_idsNo
not_investment_adviceNo

TDQS

A4.8/5.0
Behavior5/5

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

The description adds meaningful behavioral detail beyond the annotations: nothing is overwritten, both rows survive, duplicate saves are no-ops, and findings without source_query_ids are refused. This aligns with idempotentHint=true and provides operational expectations the annotations alone 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.

Conciseness5/5

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

The description is well-structured and front-loaded with the most important semantic guarantee, followed by a concise argument-by-argument breakdown. Every sentence adds value, and there is no fluff or redundancy.

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?

Despite having six parameters and nested content, the description leaves no significant gap: it covers all parameters, required conditions, behavioral guarantees, and refusal criteria. The output schema exists, so return-value documentation is unnecessary.

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 description coverage is 0%, so the description fully compensates by explaining each parameter: kind, content, key, as_of, source_query_ids, and agent_id. It also explains why key and source_query_ids are conditionally required, which is essential for correct invocation.

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 description opens with 'Remember something, with its sources and its knowledge time,' which clearly states a specific verb and resource. It further clarifies the memory kinds and distinguishes saving from the read/query siblings like memory_search and memory_get_watchlist.

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?

The description provides strong usage guidance on required parameters per kind, such as key being required for factor_def/watchlist and source_query_ids required for finding. It does not explicitly contrast with sibling read tools, but the save-vs-retrieve distinction is obvious from the wording and sibling names.

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.

TDQS

A4/5.0
Disambiguation4/5

The tools are largely distinct: querying, searching, backtesting, risk reads, alerts, memory, and audit functions each have clear homes. A few adjacent pairs (risk_read vs risk_assess, company_health_check vs positioning_read) could be confused, but the descriptions draw explicit boundaries.

Naming Consistency3/5

There are strong consistent clusters like list_*, get_*, run_*, and memory_*, but the *_read suffix alternates with noun-first names like company_health_check, and bare-verb tools like ask, calendar, chart, and screen break the pattern. The naming is readable but not uniform.

Tool Count2/5

Forty tools is well past the 25+ threshold and makes the surface heavy for an agent to navigate, even though the breadth reflects a genuinely wide platform. Several clusters could plausibly be consolidated without losing capability.

Completeness4/5

The tool surface covers the main lifecycle well: discovery, point-in-time querying, filings search and full text, backtesting, research, risk assessment, alerts, memory, approvals, and provenance verification. Minor gaps exist—no strategy management tools, no memory deletion, no bulk export—but agents can work around them.

Resources