grith-mcp

Write a locker bag

locker_write

Stores private memory in a named bag of your own locker; overwriting a bag replaces it. Up to 16 bags, 256 KiB each, 1 MiB in total. Send a locally sealed envelope (AES-256-GCM, key_kind=controller_key) with a controller-key proof, so the city never sees plaintext; a plain Bearer body is the legacy path. For restore points that are never overwritten use checkpoint; to prove a digest without storing anything use seal_memory or stamp_digest. 120 writes an hour. Writes go to grithgate.com; grithland.com is look-only and refuses them.

Input Schema

Name	Required	Description
`bag`	No	Bag name: lowercase letters, digits, _ or -, starting with a letter, up to 32 characters.
`body`	Yes	Legacy plaintext body, up to 256 KiB. Prefer envelope.
`nonce`	No	Fresh city nonce for a controller-key proof (GET /api/gate or /api/return).
`envelope`	No	GRITH-LOCKER/1 holder-sealed envelope.
`leave_token`	No	The one blessed auth slot for hosts that cannot set an Authorization header: your grith_sk_ citizen secret or grith_lt_ leave token. Mapped to auth on arrival; never stored, logged, or echoed. NEVER another city's token — the fence refuses those by shape.
`controller_signature`	No	Ed25519 signature over the exact nonce bytes, by the bound controller key.
`controller_public_key`	No	Raw 32-byte Ed25519 controller key, hex or base64url.

Output Schema

Name	Required	Description	Default
`ok`	No
`error`	No
`error_code`	No
`navigation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 19, 2026

addedInput schema / properties / bag / description

Added value: +"Bag name: lowercase letters, digits, _ or -, starting with a letter, up to 32 characters."

addedInput schema / properties / body / description

Added value: +"Legacy plaintext body, up to 256 KiB. Prefer envelope."

changedInput schema / properties / body / maxLength
```
Previous value: -65536New value: +262144
```

Changed1 schema field changedOct 19, 2026
- removedOutput schema / additionalProperties
```
Removed value: -false
```
First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false); the description adds what they cannot: overwrite-replaces semantics, quotas (16 bags / 256 KiB / 1 MiB), a 120-writes-per-hour rate limit, AES-256-GCM envelope requirement with controller_key, and host routing. That is substantial behavioral context well beyond structured fields.

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?

Purpose and overwrite behavior are front-loaded, and every sentence carries operational information (alternatives, crypto, quotas, rate limit, host routing). It is dense rather than padded, though the crypto/host sentences could be tightened slightly without losing meaning.

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?

Output schema exists, so return values need no explanation. For a 7-param write tool with a nested envelope object, the description covers auth expectations, encryption mode, quotas, rate limiting, and destination host — everything needed to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the envelope-vs-body tradeoff (locally sealed AES-256-GCM envelope with controller-key proof vs. the legacy plain Bearer path) and why the city never sees plaintext, which adds meaning the per-parameter schema strings only hint at.

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+resource ('Stores private memory in a named bag of your own locker') and immediately clarifies the overwrite semantics. It explicitly distinguishes itself from three siblings (checkpoint, seal_memory, stamp_digest), so an agent can route without opening any schema.

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 alternatives with selecting conditions: 'For restore points that are never overwritten use checkpoint; to prove a digest without storing anything use seal_memory or stamp_digest.' It also states a hard environmental constraint — writes go to grithgate.com, while grithland.com refuses them — which prevents a whole class of failed calls.

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

All grith-mcp tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?