Skip to main content
Glama

activate

Activates a persona. Activating several personas in one conversation to make them answer each other is a debate: use start_debate.

`persona_slug`: the persona you speak as, `soov` by default. A former name
(`rodin`, `occam`, `leonard`) still works; the answer then gives the
current slug and an `alias_note`.

`purpose` (a string): `session` (default) when the user opens a
conversation with this persona; `debate` or `consult` in a subagent opened
for a debate or a consultation. Only `session` reads and returns
`previous_context`: apply it, then call `clear_previous_context`.

`topic` (debate or consult only): the question; the memory pack then
serves Core and the most relevant entries on it.

Before `archetype_md`, the answer gives `rules_md` (the immutable debate
rule) and `team_md` (the team block, then the team sheet of this
account), then the memory pack. The answer stays under a budget (about
22,000 characters, 49,500 with the Large setting of the Mémoire page,
12,000 for `debate` and `consult`): the rule, the team and the archetype
are served in full, the memory pack fills the rest. `mode`: `lite`
(default: the `Core` entry, the most used procedural rules, an index of
the rest), `medium` (semantic and procedural entries) or `full` (plus the
last `recent_events_n` events). `Core` is the semantic entry titled
exactly `Core` in the global memory, served first in every mode;
maintain it with `update_semantic("Core", ..., project_scope="global")`
(on plans without general memory, the server keeps it in the project).
The general memory is read only on the Pro plan, and outside a project it
is the only memory read.
`memory_note` counts what is not served: `search_memory` fetches it on
demand. `pack_chars` counts the whole answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNolite
topicNo
purposeNosession
persona_slugNosoov
project_scopeNo
recent_events_nNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does so richly: output budget (~22,000 chars, 49,500 Large, 12,000 for debate/consult), what is served and in what order (rules_md, team_md, memory pack, archetype_md), alias handling that returns the current slug plus alias_note, plan-gated general memory, and previous_context lifecycle with clear_previous_context.

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?

Purpose and the sibling distinction are front-loaded, but the body is a dense backtick-heavy run-on that mixes call semantics, memory-pack internals, and maintenance advice for other tools. Much of it earns its place, yet the structure makes it hard to scan and several operational details read as spillover.

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?

For a 6-param, no-annotation tool in a complex memory system, the description supplies the routing, the mode/serving behavior, the budget constraints, and the lifecycle hooks an agent needs. It also narrates return fields even though an output schema exists, which is redundant but not harmful.

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 0% for 6 params, so the description must compensate, and it does for persona_slug (default soov, legacy names), purpose (session/debate/consult meanings), topic (debate/consult only), mode (lite/medium/full contents), and recent_events_n (events added in full mode). project_scope is only implied via plan/project remarks rather than defined directly, so it falls short of full coverage.

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 and resource ('Activates a persona') and immediately differentiates from the sibling by name: multi-persona answering is 'a debate: use start_debate.' An agent can route without opening either 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?

Explicit when-to-use for each purpose value ('session' when the user opens a conversation; 'debate'/'consult' in a subagent), names the alternative for debates (start_debate) and for unserved content (search_memory), and gives the follow-up action after previous_context. Nothing is left to inference.

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.