Skip to main content
Glama

memory_archivo

Detect tampering in an append-only audit log: append events, verify SHA-256 hash chain, or tail recent entries.

Instructions

[alias of cuba_archivo] Tamper-evident audit log: append-only, SHA-256 hash chain, UPDATE/DELETE blocked at the PostgreSQL trigger level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoLimit for verify/tail (default 10000 / 20)
actionYesappend: add an event. verify: walk the hash chain and detect tampering. tail: read recent events.
payloadNoArbitrary JSON payload (for append)
event_actionNoEvent type (for append)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.0

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and delivers real behavioral substance: append-only semantics, SHA-256 hash chain tamper detection, and UPDATE/DELETE blocked at the PostgreSQL trigger level. It does not cover permissions, whether verify returns a boolean or a chain report, or cost of walking a large chain.

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?

A single dense sentence with the alias qualifier first and the defining behavioral traits front-loaded. Nothing is wasted or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, no-annotation, no-output-schema tool, the description explains the storage model well but is silent on what verify/tail actually return and on limits of the chain walk. An agent knows what the store is but not fully what a call yields.

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?

Schema description coverage is 100% with the action enum, limit, event_action and payload all documented inline, so the schema already does the heavy lifting. The description adds no parameter-level detail beyond what is in the schema, which is the baseline 3 case.

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?

The description names a specific resource — an append-only, tamper-evident audit log — and the alias note ('alias of cuba_archivo') tells an agent this duplicates a sibling, aiding routing. The verbs (append/verify/tail) live only in the schema, so the description itself does not state the operations, keeping it short of a 5.

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

Usage Guidelines2/5

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

There is no guidance on when to choose this tool, when not to, or which sibling action replaces it other than the bare alias note. The action enum in the schema implies three modes but the description never frames them as usage scenarios.

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