Skip to main content
Glama

Memory Attest

memory.attest

Issue an Ed25519-signed portable attestation for a memory entry. Returns envelope for offline verify; server does not store it. Compliance: GDPR Art. 5, 32. Cost $0.01 per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entry_idYesUUID of the memory entry to attest. Must belong to owner_wallet.
owner_walletYes0x-prefixed owner wallet. Only the owner can attest.
wallet_signatureYesEIP-191 signature over the attest message (entry, owner, content hash).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNoTrue when the tool completed without a validation error.
noteNoCaller keeps the envelope; platform does not store it.
toolNoTool name that produced this payload.
paymentNoSettlement receipt after x402 or sandbox payment.
envelopeNoSigned innovalxx.memory.attestation.v1 envelope.
envelope_hashNoSHA-256 of the canonical full envelope.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations provide no read-only, openness, idempotency, or destructiveness signals, so the description carries the full burden. It discloses the server does not store the attestation and the cost ($0.01 per call), which is useful. However, it does not describe potential side effects on the memory entry, error behaviors, or authorization prerequisites beyond what's in the schema. It adds some transparency but leaves gaps.

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 three sentences, front-loaded with the primary action, and includes only essential extras (cost, compliance). No redundancy; efficient and well-structured.

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?

Given the output schema exists and schema descriptions cover all parameters, the description covers purpose, cost, and storage behavior. However, it does not explain scenarios where this tool is preferred over alternatives, and it omits potential side effects or failure modes. It is adequate but not exhaustive.

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%, so the schema already explains each parameter. The description does not add parameter-specific information beyond what's in the schema. It only mentions the entry generically, which doesn't add semantics. A baseline 3 is appropriate.

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 action ('Issue an Ed25519-signed portable attestation') on a specific resource ('a memory entry'), and differentiates it from siblings like memory.write and issue_agent_attestation by emphasizing portability and offline verification. It is clear and specific.

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?

The description implies usage for offline verification ('Returns envelope for offline verify') and mentions server non-storage, but does not explicitly compare to sibling tools like memory.verify_attestation or issue_agent_attestation, nor state when not to use it. There's only implicit context, no explicit when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources