Skip to main content
Glama
Cloto-dev

CPersona

Official
by Cloto-dev

pause_persistence

Idempotent

Suspend all write operations for a configurable TTL to prevent memory contamination during benchmarking or ephemeral exploration. Reads remain active; writes return no-op responses until auto-resume.

Instructions

Pause write operations on this MCP server for an opt-in TTL window. While paused, every write tool — store, archive_episode, update_memory, delete_memory, delete_episode, delete_agent_data, lock_memory, unlock_memory, update_profile, import_memories, merge_memories, calibrate_threshold, set_recall_precision — returns a no-op response carrying persisted: false, dry_run: true and a reason (with the TTL remaining) instead of writing to the database. persisted: false is the authoritative signal: branch on it, not on an id. Where the success shape has an id, it reads "no-persist" (store, archive_episode); action-specific id keys (deleted_id / updated_id / locked_id / unlocked_id / episode_id) are blanked to null so a truthy echo cannot read as success. migrate_channel_axis is gated differently — it is forced to dry_run and reports repairs_skipped rather than returning a skipped-response, so it carries no persisted key. check_health and deep_check are not blocked but downgrade to fix=false (they answer with repairs_skipped: true). Read tools (recall, list_*, get_profile, etc.) still answer normally, except that recall suppresses its recall_count / last_recalled_at bump — a write that would otherwise move ranking state during a paused session. Blast radius follows session_key (response scope). Pass the same session_key here and on your write calls and the pause covers that key alone (scope: "session"): a session that sends a different key is neither silenced by it nor able to clear it. The key is a partition hint, not a credential — it is compared, never verified — so anyone who sends the same string shares the pause. Omit it and you arm the bucket every keyless caller shares (scope: "process") — on a streamable-HTTP deployment a single process serves every connected client, so a keyless pause silences writes for every other keyless session until resume or TTL elapse, and those sessions get no signal. Under stdio (one process per client) that bucket is the session. This affects only this MCP server (cpersona); call cscheduler's pause_persistence too if you want both paused. Use for benchmarking, AB testing, or ephemeral exploration where memory contamination must be avoided. Default TTL: 1800 seconds (30 minutes); upper bound: 86400 seconds (1 day).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_keyNoOpaque session identity you declare: a partition hint, not authentication and not a data filter. Selects which no-persist pause applies to this call. Omit to share one bucket with every caller that omits it. Full text on recall.
ttl_secondsNoTTL until automatic resume. Min 1, max 86400 (clamped). Default 1800.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv2.5.10
    • addedInput schema / properties / session_key
      Added value: +{
      +  "default": "",
      +  "description": "Opaque session identity you declare: a partition hint, not authentication and not a data filter. Selects which no-persist pause applies to this call. Omit to share one bucket with every caller that omits it. Full text on recall.",
      +  "type": "string"
      +}
  2. Addedv2.5.2
  3. Removedv2.5.1
  4. Addedv2.4.34

TDQS

A5/5.0
Behavior5/5

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

With only idempotentHint=true and readOnlyHint=false as annotations, the description carries the full burden of behavioral disclosure and exceeds it: it explains the no-op response shape, the authoritative `persisted: false` signal, blanked id keys, wildcard versus key-scoped pause semantics, the keyless shared bucket fallback, and the migrate_channel_axis exception. No contradiction with the annotations exists.

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?

The description is long, but every sentence earns its place given the nontrivial semantics of scoped pausing. The critical behavior is front-loaded, with response signatures, scope rules, and edge cases presented in logical order. No filler or repeated schema content is present.

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?

There is no output schema, so the description must explain the response shape—and it does, including `persisted: false`, `dry_run: true`, the reason field, the 'no-persist' id, and nulled id keys. It also covers TTL defaults, scoped/global behavior, resume requirements, and server boundaries, making it complete for an agent to correctly invoke and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents both parameters, the description adds meaning beyond the structured fields. For session_key, it clarifies that '*' is global, non-wildcard keys are partition hints rather than credentials, pauses do not stack or clear each other, and omitting the key shares a process-level bucket. For ttl_seconds, it reinforces the default and upper bound while explaining the automatic resume behavior.

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 opens with a specific verb and resource: 'Pause write operations on this MCP server for an opt-in TTL window.' It clearly names the affected write tools and distinguishes the behavior from resume_persistence and persistence_status by explicitly stating that only resume_persistence can end the pause early.

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?

The description provides explicit use cases: 'Use for benchmarking, AB testing, or ephemeral exploration where memory contamination must be avoided.' It also gives cross-tool guidance by telling the agent to call cscheduler's pause_persistence if both servers should be paused, and clarifies which operations are not affected.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cloto-dev/CPersona'

If you have feedback or need assistance with the MCP directory API, please join our Discord server