Skip to main content
Glama

Remember

remember
Idempotent

Save data the agent will need to reuse later — across this conversation or across sessions. Use when you discover something worth carrying forward (a resolved ticker, a target address, a user preference, a research subject) so you don't have to look it up again. Stored as a key-value pair scoped by your identifier. Authenticated users get persistent memory; anonymous sessions retain memory for 24 hours. Pair with recall to retrieve later, forget to delete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesMemory key (e.g., "subject_property", "target_ticker", "user_preference")
valueYesValue to store (any text — findings, addresses, preferences, notes)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations indicate idempotent and non-destructive. Description adds key behavioral details: key-value pair scoped by identifier, persistence duration (24h vs permanent). No contradictions.

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?

Three tight sentences, front-loaded with purpose, no fluff. Efficiently conveys all necessary information.

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?

Covers purpose, usage, behavior, parameters, and sibling tools. No output schema needed; tool is simple and well-documented.

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% with examples. Description reinforces with additional examples and context (key-value pair, persistent memory), adding value beyond schema.

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 clearly states the tool saves data for reuse across conversations/sessions, with specific examples (ticker, address, preference). It distinguishes itself from siblings recall and forget explicitly.

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?

Provides clear when-to-use guidance ('when you discover something worth carrying forward') and pairs with recall/forget. Lacks explicit when-not-to-use but context is clear.

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

A3.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, especially within separate domains. However, the large number of Polymarket-related tools (bet_research, polymarket_arbitrage, polymarket_edges, etc.) may cause confusion as they overlap in functionality, though descriptions help differentiate them.

Naming Consistency3/5

All tool names use snake_case, but the naming patterns are inconsistent: some are bare verbs (forget, recall), some are verb_noun (generate_llms_txt), and others are noun_compound (polymarket_arbitrage). This mixed convention reduces predictability.

Tool Count3/5

With 31 tools, the set is on the higher end. While many tools serve distinct data-querying and prediction-market needs, the count feels heavy for the server's stated purpose (Tinder Bio), and some tools (e.g., pipeworx_trending, pipeworx_feedback) could be considered bloat.

Completeness1/5

The server name implies a focus on dating profile bio generation, yet only one tool (tinder_bio_generate) addresses this. The vast majority of tools are unrelated (e.g., SEC filings, Polymarket bets), creating a severe mismatch between the server's title and its actual functionality.