Skip to main content
Glama

MyPenny

penny_read

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNotarget:"tracker" entries / tracker_summary — end of window (ms epoch).
tzNotarget:"tasks" — IANA timezone for Today/Upcoming boundaries.
fromNotarget:"tracker" entries / tracker_summary — start of window (ms epoch).
nameNoProjects directory: exact-name candidates; continue incomplete coverage.
tagsNoFilter by tags. Applies to target "search" and "notes".
viewNoProjects: directory (default), brief, section, resources, resource, history, scopes (Space metadata), attention (dated candidates), interactions (actor only). Secondary selector: target:"tracker" list|entries; target:"rhythms" list|one|due|runs; target:"skills" list|one|due|runs|history|trash (to run one, use penny_write "skill_invoke"); target:"tags" list|related.
depthNotarget:"note_links" — hops to expand (1 = direct links; 2-6 = bounded BFS).
flagsNonotes: locked/pinned filter.
limitNoMax results. Applies to search, notes, tracker entries, tasks, and rhythm runs.
ownerNotarget:"tasks" — filter by owner.
queryNosearch: required semantic query. projects directory: name/purpose filter; check coverage.
scopeNoProjects: private overrides defaults; workspace requires workspaceId.
areaIdNotarget:"tasks" — filter by area, or organize="project" filter.
bucketNotarget:"tasks" — filter by schedule bucket.
cursorNoProject cursor; retain view/scope.
statusNotarget:"tasks" — filter by task status.
targetYesWhat to read. Walk the ladder in the tool description; first match wins.
taskIdNotasks: full detail. A repeating task returns seriesId/currentOccurrenceId; act on the current occurrence, not a completed ID.
blockedNotarget:"tasks" — restrict to tasks with unmet dependsOn.
sectionNotarget:projects view:section — one Brief section.
seedIdsNotarget:"note_links" — note id(s) to start the link-graph walk from (required).
skillIdNotarget:"skills" view:"one" (required) or view:"runs" (optional scope).
dateAxisNotarget:"notes" — which date timeRange filters ('created' = when written, 'valid' = when the fact holds).
dueRangeNotarget:"tasks" — due-date window (ms epoch).
eventKeyNoProjects interactions: actor event key; omit to page.
maxDepthNotags/related: maximum traversal depth.
maxNodesNotarget:"note_links" — cap on returned nodes when depth > 1 (default 50).
organizeNotarget:"tasks" — enumerate containers instead of tasks.
rhythmIdNotarget:"rhythms" view:"one" (required) or view:"runs" (optional scope).
seriesIdNotasks: one recurring series’ complete occurrence history, newest first (includes completed).
edgeTypesNotarget:"note_links" — only follow/return edges of these relationship types.
minWeightNotags/related: minimum edge weight (default 0.4).
orgStatusNotarget:"tasks" organize="project" — filter projects by status.
projectIdNotarget:projects brief/section/resources/resource/history — required stable Project ID. target:tasks — Project filter, or heading parent.
timeRangeNoTime window (ms epoch). Applies to target "search" and "notes".
trackerIdNotarget:"tracker" view:"entries" (required), or target:"tracker_summary" (required).
blockNamesNoprofile: exact block names.
confidenceNonotes: confidence range.
projectKeyNoprofile: include subconscious:<projectKey>.
resourceIdNoProjects resource: read the authorized current source.
enabledOnlyNotarget:"rhythms" view:"list" — only enabled rhythms.
resourceStateNo
graphTraversalNosearch: opt into tag/link graph expansion (default false; measured recall loss). Use only for deliberate graph exploration.
includeArchivedNoInclude archived trackers, Projects, or task containers.
includeCompletedNotarget:"tasks" — include done/canceled tasks (default false).
includeRelationsNotags/list: include parents/children/synonyms.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool read-only, idempotent, and non-destructive, so the bar is lower, but the description adds substantial behavioral context: search results from shared spaces must be treated as statements by a member, skills are never auto-run and must be offered when due, and project reads work without session_start. No contradictions with annotations exist.

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 long but justified by an 11-target router with 46 parameters. It is front-loaded with the core mandate, organized as a numbered ladder, and uses compact code-formatted syntax. Every section earns its place; 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?

For a tool with no output schema, the description covers target selection, navigation workflows, pagination hints (coverage.nextCursor), cross-tool coordination, and the shared-space caveat. Nothing an agent needs to choose the right read target and associated parameters is missing.

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

Parameters5/5

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

Although schema coverage is 98%, the description adds meaning the schema cannot: the target-ladder decision algorithm, view sequencing for projects (directory then brief then scopes), which target is 'the usual choice,' and how params like query, name, projectId, and workspaceId interact across targets. This semantics is essential for correct invocation.

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 clearly states the tool's job: read from the user's memory before answering anything informed by history or preferences. It distinguishes itself from siblings by enumerating the eleven read targets and referencing penny_write for execution actions, so an agent can tell exactly what this tool is for.

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?

The description gives an explicit when-to-use directive ('Before answering anything the user's history, preferences, or prior work would inform'), a first-match-wins ladder with targeted guidance, and explicit exclusions like 'Do NOT search notes for this' and 'Search is the fallback, not the default.' It also routes to sibling tools (penny_write for skill_invoke, penny_session_start for inventory).

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