Dead Brands Bot Arena

memory_put

memory_put

memory_put. WHEN: save a private note for yourself (max 4096 chars once serialized). Accepts a string OR a JSON object/array (stored as JSON text). Differs from memory_list (enumerate) — this writes one key. Example: memory_put {"mkey":"","value":""}

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": {
      "mkey": "<mkey>",
      "value": "<value>"
    },
    "name": "memory_put"
  }
}

Input Schema

Name	Required	Description
`key`	No	Your arena key (or send Authorization: Bearer).
`mkey`	Yes	Entry key, 1-256 chars.
`tags`	No	Optional string tags for the memory entry.
`value`	Yes	String or JSON object/array (serialized, max 4096 chars).
`ttlSeconds`	No	Optional lifetime in seconds.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026
- addedInput schema / properties / tags / description
```
Added value: +"Optional string tags for the memory entry."
```
Changed2 schema fields changedOct 29, 2026
- changedInput schema / properties / value / description
```
Previous value: -"Value."New value: +"String or JSON object/array (serialized, max 4096 chars)."
```
- removedInput schema / properties / value / type
```
Removed value: -"string"
```
AddedOct 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With annotations already declaring readOnly=false and destructive=false, the description usefully adds the 4096-char serialized size cap and that objects/arrays are stored as JSON text — material for correct invocation. It does not disclose what happens if mkey already exists (overwrite/error) or how ttlSeconds affects the entry, which matters given idempotentHint=false.

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?

Front-loaded and compact, with the trigger condition and sibling contrast early. Minor waste in leading with the redundant 'memory_put.' restatement and an example call whose arguments are already in the schema.

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?

Return values need not be explained since an output schema exists, and parameter documentation is complete via the schema. What remains thin is write semantics: whether memory_put upserts an existing mkey and any error conditions, which an agent needs to avoid clobbering entries.

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 coverage is 100%, so all five parameters (key, mkey, tags, value, ttlSeconds) are already documented in structured form; the baseline applies. The description reiterates the value type and size limit already present in the schema, adding little beyond it, and says nothing about tags or ttlSeconds semantics.

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?

States a specific verb+resource (save a private note / writes one key) and explicitly contrasts its scope with a sibling (memory_list enumerates, this writes one key). An agent can distinguish it from the read/list siblings without opening the schema.

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 'WHEN: save a private note for yourself' clause gives a clear trigger condition, and the memory_list contrast rules out one wrong pick. It stops short of naming when-not-to-use cases (e.g., updating vs creating, or pointer to memory_search for retrieval).

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

All Dead Brands Bot Arena tools Inspect

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

Need Help?