Skip to main content
Glama

agent_manage

Destructive

Manage agents (NAMESPACES under your account, sharing your token).

An agent is a namespace, never a holder of key material: all crypto is the ACCOUNT's, and an agent id is never an input to a wrap, a seal or a KEK. Agents organise and scope what is visible; they do not own encryption.

list. create. update (e.g. owner_access). merge: move an agent's MEMORIES into another, then remove source. PK collision -> 409; confirm="destroy_collisions" to force. merge with to_collection: temporarily disabled and refused with 503 (task 8cfe199b) -- the copy would lose each memory's timestamp and authorship. Merge into an agent instead. delete: refuses (409) if the agent owns data -- merge instead, or confirm="destroy_data".

owner_access to your personal memories: none (default) | reader (search/read) | member (read+write). create starts the agent with NO access -- owner_access none and no collection lines -- and whitelists what you pass: owner_access, and collections=[{slug, role}] (role admin|member|reader, never above the account's own; a bare slug grants reader). update: add_collections=[...] grants or re-roles only those; remove_collections=[slug,...] revokes only those. collections=[...] replaces the whole list (lines left out are revoked); never combine it with the other two. A PIN-holding account on a plan that writes to collections also gets a private collection named after the agent, where its memories live: memory_add(collection="") from any connection of the account writes there, and delete keeps the collection (manage it with collection_manage). Otherwise the create response says compactly why none was provisioned. Target a specific agent via ?agent_id= on the MCP URL (durable route) or the legacy AGENT_ID env / X-Agent-ID header. From your base connection, memory_add(collection="") also writes into an owned agent directly (task 78efb3dc); a connection bound to may name its own the same way and lands in its own namespace (task af02be9f).

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": "agent_manage"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoAgent name. For merge = SOURCE (consumed).
actionYesWhat to do
confirmNodelete: "destroy_data" PERMANENTLY deletes an agent that owns data (else 409 -> merge instead). merge: "destroy_collisions" drops source-side PK collisions (else 409 with the exact call).
to_agentNomerge destination (absorbs source). Default = your primary.
from_agentNomerge source (alias for name).
collectionsNoThe collection whitelist: [{slug, role}] or bare slugs (reader). create grants these; update REPLACES the whole list (absent lines are revoked) -- to change one line use add_collections / remove_collections. A collection the account is not in, or a role above the account's own, is refused.
owner_accessNoAgent access to your personal memories: none/reader/member. With update.
to_collectionNomerge: temporarily disabled, refused with 503 (task 8cfe199b). Use to_agent.
add_collectionsNoupdate: grant or re-role only these lines; others are kept. [{slug, role}] or bare slugs (reader).
remove_collectionsNoupdate: revoke only these slugs; others are kept.
can_read_my_memoriesNoDeprecated -- use owner_access.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark the tool as destructive and non-idempotent, but the description goes much further: it explains the 409 refusal on delete unless confirm=destroy_data, the merge PK-collision 409 unless confirm=destroy_collisions, the temporary 503 for to_collection, create starting with no access, and how owner_access scopes personal memories. This is substantive behavioral context beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loads a crypto aside before the action semantics, so the most actionable parts are not immediately visible. Implementation task IDs such as 8cfe199b, 78efb3dc, and af02be9f add noise for an agent selecting a tool. The information is useful but the length and ordering reduce clarity.

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?

For an 11-parameter, destructive, multi-action tool with no output schema, the description covers most operational edge cases: access defaults, collection replacement rules, merge/delete failure modes, and routing via ?agent_id or legacy headers. It does not explain the list action's return or overall response shape, which is a noticeable gap given the action enum includes list.

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, but the description adds decision semantics that the schema alone does not convey: collections replaces the entire list on update while add_collections/remove_collections only touch named lines, owner_access defaults to none on create, and merge uses name as the source. It does repeat some schema wording, which keeps it from a 5.

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 states the resource precisely as agents (namespaces under the account, sharing the token) and enumerates all five actions: list, create, update, merge, delete. It also clarifies that agents organise and scope visibility rather than owning encryption, which distinguishes this tool from crypto-related tools. An agent can identify this as the multi-action namespace-management tool 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 Guidelines5/5

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

It explicitly says when to choose merge over delete (delete refuses with 409 if the agent owns data), when to use add_collections/remove_collections instead of collections (replace whole list versus adjust lines), and that merge with to_collection is disabled with 503 so to_agent should be used instead. These are concrete routing rules with named alternatives, not just implied usage.

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