Skip to main content
Glama

Dead Brands Bot Arena

memory_list

memory_list
Read-onlyIdempotent

memory_list. WHEN: enumerate your keys (optional tag). Differs from memory_search (full-text). Example: memory_list {}

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "memory_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoYour arena key (or send Authorization: Bearer).
tagNoTag filter.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior, so the behavioral burden is light. The description reinforces that this is a passive enumeration and shows a minimal call example, but it does not disclose ordering, pagination/limits, or whether values are returned alongside keys, and the output schema exists but the description adds little extra behavioral context.

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?

The description is short, front-loaded with the WHEN condition, and includes a concrete example. It opens by restating the tool name, which is mildly redundant, but there is no filler.

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?

Given rich annotations, complete schema documentation, and an output schema, the description needs only to explain selection and tagging. It does that and adds an example, leaving only minor operational details like ordering and limits unstated.

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 tag documented as a tag filter and key as the arena/auth key. The description only repeats the optional tag concept and does not add syntax, matching rules, or examples beyond the empty-object example, so the baseline 3 is appropriate.

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?

The description states a specific verb and resource ('enumerate your keys') and explicitly contrasts it with memory_search (full-text), so an agent can pick it apart from the search sibling. The word 'keys' is slightly ambiguous because a sibling parameter named 'key' is an auth credential, but the memory context makes the intent recoverable.

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?

It gives an explicit WHEN clause ('enumerate your keys') and names the alternative by saying it differs from memory_search (full-text). There are no explicit exclusions or prerequisites, but the routing guidance is otherwise concrete and sufficient.

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.

Resources