Maindex Expert Memory Service

collection_manage

Destructive

Create, update, delete collections, or manage their members. Actions 'list' and 'get' are read-only; all others mutate. 'create' is not idempotent; 'delete' is idempotent. The 'id' param is required for update/delete/add_members/remove_members/get. Team collections use prefixed slugs (team:slug). Returns the collection object with id and shortId.

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": {
      "action": "<action>"
    },
    "name": "collection_manage"
  }
}

Input Schema

Name	Required	Description
`id`	No	Collection ID, short_id, or slug (required for update/delete/add_members/remove_members/get)
`icon`	No	Emoji or icon identifier
`name`	No	Collection name (for create/update)
`slug`	No	URL-friendly slug (auto-generated from name if omitted)
`team`	No	Team slug filter. Omit for mixed personal+team results. Use "personal" for personal-only.
`color`	No	Hex color for UI display
`action`	Yes	Action to perform
`metadata`	No	Arbitrary key-value metadata for the collection. Opaque to search and ranking.
`parent_id`	No	Parent collection ID for nesting
`memory_ids`	No	Memory IDs (for add_members/remove_members)
`description`	No	Collection description
`summary_headline`	No	Short summary for browsing

Output Schema

Name	Required	Description
`id`	No	Collection ID
`name`	No	Collection name
`added`	No	Members added (for add_members action)
`items`	No	Collection list (for list action)
`total`	No	Total count (for list action)
`deleted`	No	Whether deletion succeeded (for delete action)
`removed`	No	Members removed (for remove_members action)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the annotations, it adds per-action behavioral detail: which actions are read-only, that 'create' is non-idempotent while 'delete' is idempotent, and that team collections use prefixed slugs. It refines rather than repeats the tool-level idempotentHint=false. It does not disclose what 'delete' actually destroys (nested child collections, member memories) or any permission requirements, which matters for a destructiveHint=true tool.

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 short sentences, no filler, and the mutating-versus-read-only distinction is front-loaded before the per-action caveats and the return shape. Every sentence carries distinct information.

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?

With 12 parameters, full schema coverage, an output schema, and rich annotations, the description covers the ambiguity that matters most: which action is a write, which are idempotent, and which parameter each action needs. The notable remaining gap is destructive side effects of delete or member removal, which an agent would want before invoking it.

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%, so the baseline is 3; the description earns above that by adding cross-parameter meaning the schema lacks — that 'id' is mandatory specifically for update/delete/add_members/remove_members/get, and that team collections use a 'team:slug' prefix format. It leaves the purpose of the remaining create/update fields to the schema.

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 first sentence names specific verbs and the resource ('Create, update, delete collections, or manage their members'), and the action list makes the functional scope unambiguous. It does not explicitly position itself against the one collection-adjacent sibling (collection_unlock), which keeps it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does tell the agent that 'list' and 'get' are the read-only actions and that all others mutate, which implies when to choose this tool for reads versus writes. However it never names an alternative tool or states when not to use this one, so the guidance is inferential rather than explicit.

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

All Maindex Expert Memory Service 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?