Skip to main content
Glama
CPersona

CPersona

Official
by Cloto-dev

check_update

Report whether a newer release of this server exists, and — only if you ask — install it. The check itself runs ONCE per process start, in a background task that nothing waits on, and its verdict is cached for 24h…

Instructions

Report whether a newer release of this server exists, and — only if you ask — install it. The check itself runs ONCE per process start, in a background task that nothing waits on, and its verdict is cached for 24h (CPERSONA_UPDATE_CHECK_INTERVAL_SECONDS) in a file beside the database; a bare call here reads that verdict and reaches neither the network nor the disk. state is one of: ok (running the newest release) / newer (a newer final release exists — pre-releases are never proposed) / yanked (every file of the RUNNING version has been withdrawn on PyPI; reason carries the publisher's text) / unlisted (this version is not on the index at all — a development checkout; not a defect) / unknown (no check has completed, e.g. no network) / disabled. install names how this process was installed (uvx / pip / checkout / unknown) and the exact command that would update it. refresh=true performs the fetch now (3s budget) and updates the cache. apply=true runs that command as an argv list (never a shell), returning exit_code and the last 40 lines of output — supported for pip and checkout installs only; under uvx the environment is a cache entry keyed by the launch arguments, so the update belongs in your client's config (uvx cpersona@latest), and an install here would be discarded on the next launch. A checkout parked at a tag (detached HEAD) is likewise refused before anything runs, and answers with the git fetch --tags && git checkout <tag> form to use instead (install.command shows it too). One apply runs at a time; a second is refused until it ends. Updating is NEVER automatic and never a side effect of any other call. A RESTART IS ALWAYS REQUIRED afterwards: this process keeps serving the old code until it is replaced. Unaffected by pause_persistence — an install writes no memory row, so a no-persist session can still repair a withdrawn version. Set CPERSONA_UPDATE_CHECK=false to disable the feature entirely: no fetch, no cache, no notice on recall or check_health, and this tool answers state=disabled.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
applyNoRun the detected update command (pip / checkout installs only). Off by default; a restart is required afterwards.
refreshNoFetch the package index now instead of reading the cached verdict (3s budget). A failed fetch keeps the verdict already known, so `checked_at` does not move; with none known it answers state=unknown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.6.12
    • changedInput schema / properties / refresh / description
      Previous value: -"Fetch the package index now instead of reading the cached verdict (3s budget; a failure answers state=unknown)."New value: +"Fetch the package index now instead of reading the cached verdict (3s budget). A failed fetch keeps the verdict already known, so `checked_at` does not move; with none known it answers state=unknown."
  2. Addedv2.5.10

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses extensive behavior beyond the single readOnlyHint=false annotation: background check timing, 24h caching, state values, install detection, argv execution, output truncation, refusal cases, and the restart requirement. It is consistent with the annotation because the tool can mutate when apply=true.

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 description is dense, but it is front-loaded with the core purpose and every detail is relevant to this unusually conditional tool. It could be structured with clearer sections, but it avoids redundant filler.

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?

Given the tool's complexity and lack of an output schema, the description is complete: it defines every state, explains refresh and apply behavior, documents practical failure modes, and covers configuration and restart requirements.

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 schema coverage is already 100%, the description adds meaningful semantics for both parameters: refresh's 3s fetch budget and failed-fetch behavior, and apply's supported install types, argv execution, exit_code, and output lines. This goes well beyond the schema text.

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 a specific verb and resource: report whether a newer server release exists and optionally install it. It clearly separates checking from applying and is unmistakably distinct from the memory-oriented sibling tools.

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 gives explicit conditions for refresh and apply, states that updating is never automatic, and explains unsupported cases such as uvx installs and detached-HEAD checkouts. It also notes the one-apply-at-a-time constraint and the required restart.

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