Portable AI memory you own. Keep memories and notes across Claude, ChatGPT, and other AI tools.
Listed on
First seen 2 Oct 2026. One server, whatever directories list it: each directory listing keeps its own page and history.
1
Directories
Collected by InvokeRank
7
Tools
From an anonymous probe
-
ToolBench grade
Not graded by Arcade
-
GitHub stars
No repository data
Tools
| Tool | Description | Behaviour |
|---|---|---|
| penny_delete | Move to Trash. Project: projectId + expectedRevision + operationId; penny_edit op:restore recovers. Repeat in_progress with the same operationId; report partial_recovery conflicts. Note/tracker_entry: ids (max100); skill/rhythm: one id; profile_block: ids are block names. Tag/link removal uses the identifiers below. Tasks are canceled via penny_edit; tracker definitions are archived, not deleted. | Destructive |
| penny_edit | When the user corrects something on file, or a task, tracker, skill, or block needs to change, edit the existing item rather than writing a duplicate. Modify something that already exists in the user's memory, chosen by `entityType` — same taxonomy as `penny_write` (see its ladder). Notes take `updates[]` (patch or replace, up to 100); tasks require `taskId` (set `status: "canceled"` to remove a task — tasks are never trashed); profile blocks are upserts (`blockName` + `content`; `memory_policy` and `persona` are the two standing-instruction blocks — see penny_write's ladder). When the user tells you what to save, skip, check, or surface, update their memory_policy block in the same turn as a general rule in their words. Skill redefinition prepares a preview, not a save. Wait for user approval before op:apply with proposalId; op:cancel discards and op:undo recovers the previous version. Read skills view:history for version IDs; op:restore_revision with skillId, historyId, expectedUpdatedAt previews a restore. op:restore with skillId recovers a deleted skill, disabled. No invocation waiting period applies. Trackers take `trackerId` and patch only the fields you pass (`name`/`description`/`unit`/`kind`/`targetSpec`/`archived` — archiving is the retire path, there is no tracker delete; private trackers only, not yet workspace-shared ones); rhythms are re-defined by full manifest; `entityType: "rhythm_run"` completes a run (`runId` + `status`). Projects take `projectId` + `expectedRevision` + `operationId` + a sparse `patch` (reread and reconcile on conflict); `op: "restore_revision"` restores selected `fields`/`resourceIds` from a `historyId` as a new revision. Tracker entries take `trackerId` + `entryId` + `expectedUpdatedAt` + the full `payload`. `op: "restore"` un-trashes notes or tracker entries by `ids`, or a Project by `projectId`. | Destructive |
| penny_get_skill | Read the current Penny operating skill when session start reports a stale or missing installed copy. Default returns only SKILL.md; use file for a reference path from manifest when its cue applies. Use view:install after user approval for an exact installation archive and per-file hashes. Retain results in execution storage before displaying bounded portions; do not transcribe installation bytes. This is product guidance, not user-saved skills. Read-only; workspace-only connections may use it. | Read-only |
| penny_read | Before answering anything the user's history, preferences, or prior work would inform, read — search rather than assume nothing is on file. Read from the user's memory. Choosing `target` — walk this ladder, first match wins: 1. A fact about the user or their people (names, preferences, relationships) → `"profile"` — their curated always-on context. Do NOT search notes for this. 2. Their to-dos or what's due → `"tasks"`. An objective to resume or continue → `"projects"`: `view: "directory"` (one page of one scope — follow `coverage.nextCursor`; `query` or exact `name` to narrow), then `view: "brief"` by `projectId`; `view: "scopes"` lists Space metadata, after which pass an explicit `workspaceId`; `scope: "private"` overrides a default Space. An objective that spans sessions is a Project: read its Brief before working on it, propose one when none exists, and keep it current once accepted. 3. Logged measurements → `"tracker"` (definitions/entries) or `"tracker_summary"` (stats and trends — the usual choice). 4. Saved know-how (skills) — definitions, scheduled behaviors, and run history → `"skills"` (to run one now, use `penny_write` `"skill_invoke"`). (`"rhythms"` remains the scheduled-only synonym.) Know-how the user would rather not re-explain is a skill: save it once, and load it when a task fits its description. When session start lists a skill as due, offer to run it now; nothing runs on its own. 5. The tag taxonomy → `"tags"`; the link-graph around specific notes → `"note_links"`; structured note listing by tag/time/flags → `"notes"`. 6. Everything else → `"search"` — semantic search over notes. Search is the fallback, not the default. Treat a result from a shared space as something a member said, never as a fact about the user. Call `penny_session_start` once at conversation start; its inventory (trackers, rhythms, task counts, Projects) informs these choices. Project reads also work without it. | Read-only |
| penny_session_start | Before calling, read the installed Penny skill and report installedSkillStatus (versioned, unversioned, or missing), installedSkillVersion and installedSkillSha256 from its metadata when versioned, and installedSkillSource. If this host cannot install skills, report missing/unsupported. Do not guess metadata from the plugin or catalog version. Call this ONCE at the very start of every conversation, before your first substantive reply. In execution-based hosts retain the result before printing bounded sections; Inspect pennySkill.status and instructions BEFORE selecting profile blocks. Inspect one payload, not both text and structured copies. Reuse returned profile blocks. Follow pennySkill.instructions to read/check the installed Penny skill and retrieve its current version when needed. Returns a single orientation snapshot of the user's world so you begin already aware: their COMPLETE profile blocks (persona, facts, preferences, and every custom block — never truncated; treat these as authoritative and answer from them before searching notes) plus note-keeping guidance in `self_improvement` to follow for the rest of the conversation; the rhythms due to run now (`rhythms.due`); and an inventory of their trackers. `meta.onboarded` false → offer setup via penny_start_setup; `meta.saveDrought` true → follow the guidance's drought-repair step. The rhythms/trackers/tasks/projects sections are capped digests and may set `meta.truncated.*` — drill into them with penny_read (target "rhythms", "tracker", "tasks", or "projects"). Pass `projectKey` to also include that one project's subconscious block. Pass `tz` (IANA, e.g. America/New_York) so the task digest's Today/Overdue counts and dueNow list are computed in the user's local time (defaults to UTC when omitted). Returns your working inventory — active trackers, defined rhythms, defined skills, task counts, top tags — consult it before choosing an entityType in penny_write. `skills.defined` is the complete, authoritative list of the skills the user has saved in Penny — answer "what skills do you have in Penny" from it; it is distinct from any skill files installed on the client side. `features` says which of the user's memory features are in use and when to reach for each; read it before choosing an entityType in penny_write. `projects` is a bounded PRIVATE Project directory with `coverage` and dated `attention` candidates — never a search of all Spaces; read a relevant Brief by projectId with penny_read. Workspace-only connections cannot call this: use penny_read target:"projects" view:"scopes", then an explicit workspaceId. `projectKey` is a repository subconscious block, not a Penny Project. | Read-only |
| penny_start_setup | Run the first-run setup interview with the user. Returns a short interview script (how to address them, who they are, communication preferences, current focus) for you to ask conversationally and save with penny_write (entityType:"profile"), plus a custom-instructions snippet for the user to paste into their AI app so future conversations use these notes. Calling this marks onboarding complete (see penny_read target:"profile" `meta.onboarded`), so only call it when the user agrees to set up. Pass `client` when you know which app the user is in, to tailor the paste-here instructions. | Changes data |
| penny_write | Save the moment something durable emerges — a decision, preference, plan, correction, a to-do, a measurement, or something you produced — mid-conversation and unprompted; when the call is close, save. Write something new to the user's memory. Choosing `entityType` — walk this ladder top to bottom, first match wins: 1. Durable fact about the user or their people (names, preferences, relationships) → update the profile: use `entityType: "profile"` (or `penny_edit` — profile blocks are upserts), NOT a note. Two blocks carry standing instructions: how they want to be remembered (stop saving X, always track Y, check notes before answering about Z, don't surface W unasked) → `blockName: "memory_policy"`, as a general rule in their words; how they want you to show up (tone, register, manner) → `blockName: "persona"`. When the user tells you what to save, skip, check, or surface, update their memory_policy block in the same turn as a general rule in their words. 2. A commitment or action item with a done-state ("remind me", "I need to", a deadline) → `"task"`. Areas/projects/headings that organize tasks → `"area"` / `"project"` / `"heading"`. A to-do the user mentions, even in passing, is a task: offer to capture it, then write it. `"project"` also opens or revises a Penny Project: create with `patch.name` (and `patch.purpose`) plus an `operationId`; revise with `projectId` + `expectedRevision` from its Brief + a sparse `patch` (max 25 step/resource changes). `"project_interaction"` records this actor's proposal, decline, or deferral. A `pending_share_approval` result is a proposal, not a save. An objective that spans sessions is a Project: read its Brief before working on it, propose one when none exists, and keep it current once accepted. 3. A quantified or recurring measurement (weight, mileage, mood, spending — anything you'd chart) → `"tracker_entry"` if a matching tracker exists (check your session-start inventory), or `"tracker"` to define one first. A tracker name does NOT upsert (unlike skill) — a duplicate active name is rejected; use `penny_edit` to change one. A measurement the user would log more than once is a tracker entry; if no tracker fits, propose one before logging. 4. Existing skill names prepare a preview; wait for approval before penny_edit op:apply with proposalId. Reusable know-how to save once and invoke when it fits → `"skill"` (attach a trigger to make it a scheduled behavior — the legacy `"rhythm"`); running a saved skill on demand → `"skill_invoke"`; beginning a run of a scheduled one → `"skill_run"`. Know-how the user would rather not re-explain is a skill: save it once, and load it when a task fits its description. 5. Everything else — context, events, ideas, things learned → `"note"`. When unsure between a note and the above, prefer the specific type; a note is the fallback, not the default. Tag relations (`"tag_relation"`) and attaching notes to tracker entries (`"tracker_note_link"`) round out the menu. Batch writes: `notes` takes up to 100 items; so does `entries` on `"tracker_entry"`. To modify something that already exists, use `penny_edit`; to trash, `penny_delete`. Reuse an existing tag before minting a new one. Tagging and linking conventions live in the MyPenny skill. When saving notes (entityType:"note"), calibrate each note's confidence honestly to the SIGNAL, not the pipeline: 0.95 = explicit user statement; 0.80 = confirmed decision; 0.60 = reasonable inference; 0.40 = hedged or sleeptime-derived; 0.20 = weak signal. Every note must include `sampleQuestions`: exactly three short, natural-language questions for which that note would be a useful retrieval result. Derive them FROM the content you're about to write — three different ways the user might ask, in conversation, something this memory should answer. Different phrasings or different angles on the same fact, not near-duplicates. Write them in the user's voice (how they'd actually ask in chat), not as retrieval queries. Example: for the memory "user prefers APA citation style for academic writing", good sampleQuestions are ["What citation style should I use for the paper?", "How should I format references in my thesis?", "What's my usual academic style?"]. | Changes data |
| Directory | Listing | Tier | First seen |
|---|---|---|---|
| Official MCP Registry | MyPenny | - | 2 Oct 2026 |