Skip to main content
Glama
Phygital-Brain

phygital-memory

Official

status

Read-only

Lists available memory folders with lock state, note count, and read/edit permissions; call it before using other tools to choose the right folder or detect locked/unknown ones.

Instructions

Start here. Lists the person's memories (folders) you may use: each one's name, whether it is unlocked, how many notes it holds and which subfolders are private. Also says whether this AI app may only read or may edit. Read only, no inputs. Call it first in a chat, and again when another tool says a folder is locked or unknown. Use the names it gives as folder= in the other tools. To see what is inside a folder, use list_notes.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

The readOnlyHint annotation already confirms this is a safe read, so the description's 'Read only' line is redundant. However, it adds useful behavioral context beyond annotations: it discloses the returned permission level (read vs. edit), folder lock status, private subfolder visibility, and a re-invocation trigger when a folder is locked or unknown.

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 well-structured and front-loaded with 'Start here.' Each sentence contributes: the resource listing, the permission note, the no-input cue, the invocation triggers, and the sibling routing. There is no 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 simple zero-parameter status check, the presence of annotations (readOnlyHint, openWorldHint) and an output schema, the description covers everything an agent needs: what is listed, when to call it, how to use the results, and where to go for folder contents. No gaps remain.

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?

The tool takes zero parameters, so the baseline is 4. The description simply says 'no inputs', which aligns with the empty schema and clarifies there is nothing to supply.

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 (lists) and resource (memories/folders), and adds what each entry contains: name, unlocked status, note count, private subfolders, and app permission level. It also distinguishes itself from the sibling list_notes by directing that sibling for viewing folder contents.

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 when-to-use instructions: 'Start here', 'Call it first in a chat', and 'again when another tool says a folder is locked or unknown'. It also names the alternative list_notes for inspecting folder contents and explains how to use the returned names as folder= in other tools.

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