Skip to main content
Glama
Cloto-dev

CPersona

Official
by Cloto-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pause_persistence

Idempotent

Pause write operations on the CPersona MCP server for a set TTL to avoid memory contamination during benchmarking, A/B testing, or ephemeral exploration.

Instructions

Pause write operations on this MCP server for an opt-in TTL window. While paused, every write tool — store, declare_associations, 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.

  1. Changed1 schema field changedv2.6.1
    • addedInput schema / properties / session_key / maxLength
      Added value: +256
  2. 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"
+}
  3. Addedv2.5.2
  4. Removedv2.5.1
  5. Addedv2.4.34

TDQS

A4.7/5.0
Behavior4/5

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

Discloses far more than the annotations: no-op response shapes, persisted:false as the authoritative signal, id key blanking, the migrate_channel_axis special case, check_health/deep_check downgrades, and recall's suppressed ranking bump. It never states whether the pause is itself reversible/clearable beyond resume/TTL, but the safety profile is thoroughly covered.

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?

The core action, the blast-radius warning, and the TTL bounds are ordered well and the critical session_key caveat is bolded. It is long, but nearly every clause carries operational information; only minor tightening of the response-shape enumeration is possible.

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?

With no output schema and a non-trivial side-effecting tool, the description fully compensates: it describes the return payloads (persisted, dry_run, reason, no-persist id), the read-tool carve-outs, and the scope semantics an agent needs to call it safely.

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?

Schema coverage is 100%, but the description still adds real meaning: session_key is a comparison-only partition hint (not a credential), blast radius follows it, omitting it arms a shared process bucket, and TTL bounds/defaults are restated operationally.

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 with scope: 'Pause write operations on this MCP server for an opt-in TTL window.' It enumerates the affected write tools by name and is unmistakably distinct from siblings like resume_persistence and persistence_status.

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?

Gives explicit use cases (benchmarking, AB testing, ephemeral exploration to avoid memory contamination), names the counter-action (resume or TTL elapse), warns that cscheduler's pause_persistence must be called separately, and spells out the when-not consequence of omitting session_key.

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

Deploy Server

Other Tools