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)

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds beyond that: key-value scoping by identifier, persistence differences (authenticated vs anonymous). No contradiction.

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?

Five sentences, front-loaded with purpose, efficient without wasted words. Every sentence adds value.

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?

Given only 2 parameters, no output schema, and good annotations, the description is complete: covers usage, behavioral context, persistence, and pairing with sibling tools.

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 has 100% coverage with descriptions for both key and value. The description adds meaningful context with key examples (e.g., 'subject_property', 'target_ticker') and value content hints, adding value beyond what the schema provides.

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 uses 'Save data the agent will need to reuse later' which is a specific verb-resource pair with clear scope. It distinguishes from sibling tools recall and forget, and provides concrete examples like 'resolved ticker, a target address, a user preference'.

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?

The description explicitly states when to use: 'when you discover something worth carrying forward' and contrasts with sibling tools: 'Pair with recall to retrieve later, forget to delete.' This provides clear guidance on alternatives.

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

B3.3/5.0
Disambiguation3/5

The tool set contains multiple groups with overlapping purposes (e.g., ask_pipeworx/ask_pipeworx_grounded/deep_research for data queries, multiple Polymarket tools, and memory tools). However, detailed descriptions help differentiate them, so ambiguity is moderate but not severe.

Naming Consistency2/5

Naming conventions are inconsistent: some tools follow verb_noun (ask_pipeworx, compare_entities), others use domain-prefixed noun_verb (ghg_emissions_by_sector, polymarket_arbitrage). This mix, combined with a server name that doesn't match the tool domain, makes the naming pattern unclear.

Tool Count1/5

With 35 tools, the server is overloaded, especially given its name 'Epa Emissions' which suggests a narrow focus. Only 5 tools (ghg_*, tri_*) are related to emissions; the rest are unrelated, making the count inappropriate for the server's assumed purpose.

Completeness2/5

For an EPA/emissions server, the tool set is incomplete: it lacks other emissions data (e.g., air quality, water quality, enforcement). The inclusion of many unrelated tools (e.g., Polymarket, memory) does not compensate for missing core emissions coverage.