Skip to main content
Glama
ignatenkofi

memshelf-mcp

by ignatenkofi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memshelf_doctor

Read-onlyIdempotent

Checks a memory shelf for schema, digest, secret, ledger, and index issues; read-only, and can optionally probe remotes for public exposure.

Instructions

Diagnose shelf integrity: episode schema, digest contract at rest, leaked secrets, ledger consistency, INDEX budget. Read-only; fixes nothing. check_remote adds the network probe for a public remote.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.0
    • addedInput schema / $defs / DoctorInput / additionalProperties
      Added value: +false
    • addedInput schema / $defs / DoctorInput / properties / derived_stale_after_hours
      Added value: +{
+  "default": 24,
+  "description": "Hours the derived layer may go unrewritten with uncounted episodes before `derived-stale` fires (#89). A shelf picks its own threshold — a bot that renders in minutes deserves a far shorter one than the day-long default.",
+  "exclusiveMinimum": 0,
+  "title": "Derived Stale After Hours",
+  "type": "number"
+}
    • addedInput schema / $defs / DoctorInput / properties / shelf_path / default
      Added value: +""
    • changedInput schema / $defs / DoctorInput / properties / shelf_path / description
      Previous value: -"Path to an initialized memory shelf."New value: +"Path to an initialized memory shelf. Optional: when omitted, the shelf named by $MEMSHELF_SHELF_PATH is used. Pass it explicitly to address a different shelf than that default."
    • removedInput schema / $defs / DoctorInput / required
      Removed value: -[
-  "shelf_path"
-]
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered; the description adds genuine extra context by listing the specific invariants checked, stating it performs no repairs, and disclosing that check_remote hits the network and is off by default. It does not describe failure reporting or exit behavior, but that is largely covered by the output schema.

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?

Two tight sentences, heavily front-loaded with the diagnosis scope, followed by the non-fixing guarantee and the one parameter caveat that changes behavior. No filler.

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 a read-only diagnostic tool with an output schema, the description covers scope, non-mutating behavior, and the network caveat — enough to invoke correctly. Minor gap: it never states what a failure result looks like, though the output schema plausibly carries that.

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

Parameters3/5

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

Top-level coverage reads as 0% (the single visible param is the wrapper), but the nested DoctorInput fields are themselves well documented in the schema. The description adds real meaning only for check_remote (network probe for a publicly visible remote) and says nothing about shelf_path defaults or derived_stale_after_hours, so it sits at the schema-does-the-work baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ("Diagnose shelf integrity") and enumerates the exact checks performed: episode schema, digest contract, leaked secrets, ledger consistency, INDEX budget. That scope is more specific than siblings, though it never names memshelf_lint_digest or memshelf_advise to draw the boundary explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

"Read-only; fixes nothing" implicitly tells the agent this is the inspection step rather than the repair step, and the check_remote sentence explains when the optional network probe applies. However, there is no explicit when-to-use / when-not guidance and no routing to overlapping siblings like lint_digest or stats.

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