Pick up where you left off: your project's progress, decisions and notes, kept in your own storage.
Scored across 16 tools
Most tools target distinct resources or operations, but capture_correction overlaps meaningfully with supersede: capture_correction appends a correction and says the old entry is marked superseded, while supersede separately marks any record entry as superseded. The four capture_* tools are otherwise differentiated by their target list, and read_file/read_home/raw_source remain readable as distinct despite some conceptual closeness.
Most names follow a readable verb_noun pattern: capture_*, connect_storage, list_homes, read_file, read_home, save_note, setup_home, update_home_file. Minor deviations exist in raw_source (noun phrase), supersede (bare verb), and organize_prepare/organize_save (category-style prefix), so the convention is mostly but not fully consistent.
Sixteen tools is slightly above the typical 3-15 well-scoped range but remains reasonable for a rich home/project memory system with storage connection, setup, capture variants, organizing, and file updating. Each tool appears to earn its place, though the set is close to feeling heavy.
The surface covers setup, storage connection, home reading, note saving, raw-source preservation, append-only record capture, superseding, organizing, and home-file updates, so core workflows have endpoints. Minor gaps remain, such as no explicit detach-storage tool or standalone listing of record entries, though read_home returns inventory and append-only constraints are intentional.
Living Projects — Append one entry to this home's CORRECTIONS list: one saved fact replaced by another. The old entry stays and is marked superseded. Doubt wording and telling words outside quoted words — "remains to be confirmed", "unconfirmed", "should", "never" and the like — are saved as written, and the answer marks the lines. All four fields are required; the write is verified before VERIFIED is returned. Append-only — there is no edit and no delete. An entry is the short form of what was settled: one or two sentences per field, about 80 words in all. The detail of a sitting lives in its dated note; a field with detail there ends with a pointer to it.
| Name | Required | Description | Default |
|---|---|---|---|
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| why_it_was_wrong | Yes | Why it was wrong. | |
| what_was_saved_and_where | Yes | What was saved, and where. | |
| what_else_was_updated_to_match | Yes | What else was updated to match — or: nothing else. | |
| whats_right_now_in_the_owners_words | Yes | What's right now, in the owner's words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations with details they cannot express: the old entry is retained and marked superseded, wording is saved verbatim and flagged in the response, the write is verified before VERIFIED is returned, and there is no edit or delete path. This confirms the non-destructive hint and explains the response signal, which matters since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the append-only constraint are front-loaded, and most sentences carry distinct information (retention, verification, length budget, pointer convention). Some phrasing is dense and repetitive, e.g. the 'Doubt wording and telling words' sentence, which could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the response signal (VERIFIED, marked lines) and the mutation semantics an agent needs for a write tool. Minor gaps remain, such as what happens on verification failure or what a partial/duplicate correction looks like, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns above that by stating that all four content fields are required and each should be one or two sentences, ~80 words total, with detail pushed to a dated note and referenced by pointer. It also explains that quoted doubt wording must be preserved verbatim, which the schema does not say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Append one entry to this home's CORRECTIONS list') and defines what an entry is ('one saved fact replaced by another'), which separates it from save_note, capture_decision, and supersede. An agent can tell what artifact this creates without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Append-only — there is no edit and no delete' implies that corrections elsewhere belong to a different tool, and the note-versus-field guidance implies when to use a dated note instead. However, no sibling tool is named (notably supersede, which sounds adjacent), so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Append one entry to this home's DECISIONS list: something was chosen, and why. Doubt wording and telling words outside quoted words — "remains to be confirmed", "unconfirmed", "should", "never" and the like — are saved as written, and the answer marks the lines. All four fields are required; the write is verified before VERIFIED is returned. Append-only — there is no edit and no delete. An entry is the short form of what was settled: one or two sentences per field, about 80 words in all. The detail of a sitting lives in its dated note; a field with detail there ends with a pointer to it.
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | Why. | |
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| what_it_replaced | Yes | What it replaced — or: nothing, first choice. | |
| what_was_decided | Yes | What was decided. | |
| what_it_touched_and_connects_to | Yes | What it touched, and what it connects to: where the decision landed, and the entries it sits beside. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: append-only immutability, all content fields required, and that the write is verified before VERIFIED is returned, plus that hedge/telling words are preserved as written and flagged in the answer. That flagging/verification behavior is unobvious and valuable, though the phrasing 'the answer marks the lines' is cryptic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded and the sentences are dense but purposeful. The middle passage about 'doubt wording and telling words outside quoted words' is hard to parse and reads as more obscure than necessary, costing clarity for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does explain that VERIFIED is returned after a verified write, and it specifies the expected shape of each content field. It omits failure modes and how to locate home_path, but the schema covers the latter, leaving only minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 schema already defines all five parameters, albeit tersely ('Why.'). The description adds useful sizing guidance ('one or two sentences per field, about 80 words in all') and the pointer convention for fields detailed elsewhere, which is a modest lift above the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (append one entry) and resource (this home's DECISIONS list) with a semantic gloss ('something was chosen, and why') that implicitly separates it from capture_rejection/capture_correction. It never names those siblings, so an agent must infer the boundary from the wording alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real scoping rules: append-only with no edit or delete, and 'the detail of a sitting lives in its dated note' with a pointer rule for overly detailed fields. However, no sibling tool is named as an alternative, so the choice between capture_decision, capture_rejection, and capture_correction remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Append one entry to this home's DEFINITIONS list: a word the owner uses in a fixed way. Doubt wording and telling words outside quoted words — "remains to be confirmed", "unconfirmed", "should", "never" and the like — are saved as written, and the answer marks the lines. All four fields are required; the write is verified before VERIFIED is returned. Append-only — there is no edit and no delete. An entry is the short form of what was settled: one or two sentences per field, about 80 words in all. The detail of a sitting lives in its dated note; a field with detail there ends with a pointer to it.
| Name | Required | Description | Default |
|---|---|---|---|
| the_word | Yes | The word — the word itself, not a sentence about it. | |
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| what_it_usually_means | Yes | What it usually means. | |
| where_it_was_first_said_and_where_its_used | Yes | Where the owner first said it, and where it's used — or: only here so far. | |
| what_it_means_here_in_the_owners_exact_words | Yes | What it means here, in the owner's exact words. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real behavior beyond the annotations: append-only with no edit and no delete, a write that is verified before VERIFIED is returned, and that the answer marks the lines. One flaw: it says 'All four fields are required' while the schema actually requires five, a small inconsistency that could cause a failed call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first clause, then the behavioral rules and sizing constraints follow in order of consequence. Dense but every sentence carries a distinct constraint; nothing is repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter write with no output schema, it covers the essentials: append-only semantics, verification before return, and the shape of the returned answer. The 'four fields' miscount against five required parameters is the one gap that could affect a call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 nonetheless adds per-field sizing guidance (~80 words total, one or two sentences per field) and the pointer convention when detail lives in a dated note. That is meaning beyond the schema, though it does not disambiguate individual fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (append one entry) and a specific resource (this home's DEFINITIONS list) with the narrowing qualifier 'a word the owner uses in a fixed way', which cleanly separates it from capture_decision, capture_correction and capture_rejection. An agent can route to this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It defines the qualifying subject matter ('a word the owner uses in a fixed way') and gives content-shaping rules (one or two sentences per field, ~80 words, detail belongs in the dated note with a pointer). It never names a sibling or an explicit when-not condition, so the agent must infer that decisions/corrections belong elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Append one entry to this home's REJECTIONS list: a path considered or tried and dropped, and why. Doubt wording and telling words outside quoted words — "remains to be confirmed", "unconfirmed", "should", "never" and the like — are saved as written, and the answer marks the lines. All four fields are required; the write is verified before VERIFIED is returned. Append-only — there is no edit and no delete. An entry is the short form of what was settled: one or two sentences per field, about 80 words in all. The detail of a sitting lives in its dated note; a field with detail there ends with a pointer to it.
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | Why it was dropped. | |
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| what_was_dropped | Yes | What was dropped. | |
| what_was_kept_instead | Yes | What was kept instead — the path taken in its place, not the path dropped. | |
| what_was_already_built_and_removed | Yes | What was already built, and what was removed — or: nothing built yet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic readOnly=false / destructive=false profile, and the description adds the important specifics: append-only with 'no edit and no delete,' and 'the write is verified before VERIFIED is returned.' It also discloses that doubt/telling wording is preserved as written and marked in the response, which an agent could not infer from the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded in the first clause, and most sentences carry distinct information (scope, wording handling, verification, append-only, length discipline). The middle sentence about doubt wording is dense and takes a second pass to parse, costing some crispness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the return behavior — the response marks doubt/telling lines and VERIFIED is returned after write verification. Combined with the length guidance and the append-only constraint, an agent has enough to call this correctly without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: each field should be 'one or two sentences,' about 80 words total, and a field carrying detail elsewhere should end with a pointer to the dated note. The only blemish is 'All four fields are required' when the schema's required list has five names (the four content fields plus home_path), which is slightly imprecise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource — 'Append one entry to this home's REJECTIONS list' — and defines an entry as 'a path considered or tried and dropped, and why.' That distinguishes it in substance from the capture_correction/decision/definition siblings, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It sets a clear condition for use (something considered or tried and then dropped) and routes long-form content elsewhere: 'The detail of a sitting lives in its dated note; a field with detail there ends with a pointer to it,' which implies save_note rather than an expanded entry here. It stops short of naming capture_decision or capture_correction as the alternative when the item wasn't dropped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Attach another storage (Dropbox, Google Drive, or Microsoft OneDrive) to this connection: returns a one-time link the owner opens to approve on that storage's own page. Afterwards the list of homes spans every attached storage; a home still lives whole in ONE storage. If two storages hold a same-named home, name the storage in the path, e.g. 'dropbox:/condo'.
| Name | Required | Description | Default |
|---|---|---|---|
| storage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-destructive mutation, and the description adds genuinely useful context beyond them: the return is a one-time link, approval happens out-of-band on the provider's own page, and the home list afterwards spans all attached storages. It does not say what happens if the storage is already attached or whether the connection can be undone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and effect; the product prefix and the path-disambiguation sentence are mildly extra but both earn their place by clarifying behavior after the call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers what happens (link returned, approval flow, resulting state) well enough to call it correctly. Missing only edge-case behavior and the exact argument format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameter burden. It names the accepted providers and the 'dropbox:/condo' path example hints at a lowercase provider identifier, but it never states the exact value format expected for the `storage` argument, leaving room for a wrong value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — attach another storage (Dropbox, Google Drive, OneDrive) to this connection — and explains the mechanism (a one-time approval link). It is functionally distinguishable from read-oriented siblings like list_homes/read_home, but no sibling is named explicitly to route the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this when you want an additional storage attached. The description explains post-conditions and even how to disambiguate same-named homes in paths, but gives no explicit when-not conditions, prerequisites, or named alternatives (e.g., setup_home).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — List every Living Projects home in the connected storage, by path. Reads names only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/non-destructive/closed-world, so the bar is lower, and 'Reads names only' adds genuinely new information about result content (no file bodies returned) that isn't in any structured field. Pagination and empty-storage behavior remain unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler, though 'Living Projects' is repeated immediately, which is mild redundancy and slightly muddies the scoping statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does just enough by noting results are paths and names only. It omits what a 'home' contains and what happens when no storage is connected, which an agent would need to handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every Living Projects home') plus scope ('in the connected storage, by path'), which clearly distinguishes a discovery/enumeration operation from siblings like read_home and update_home_file. It stops short of naming those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'List every ... home in the connected storage' implies this is the enumeration step before read_home, and that storage must be connected, but neither the prerequisite nor the alternative is stated. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Name the notes folder this platform stages to, where the plugin has no name for the tool that connected. Claude, GPT and Gemini platforms are named by the plugin from the name they give at the door, or from their registration where that name gives none. The answer is kept on this connection, carried across a reconnect, and is the name in every home; once a note is saved under a name, or where the plugin gave the name, pressing this again changes nothing. Notes only — captures do not depend on it. Pressed once after a NOT FOUND answer from save_note; the same save then goes through.
| Name | Required | Description | Default |
|---|---|---|---|
| shelf | Yes | The folder this platform's notes go to, as the owner would name it. The word Notes is added by the plugin. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), the description discloses real behavior: the answer is stored on the connection, survives a reconnect, applies to every home, and re-invocation is a no-op once named. That idempotency and persistence detail is exactly the kind of context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Length is reasonable and little is wasted, but the structure is poor: the single actionable instruction (call after a NOT FOUND from save_note) appears at the very end, behind four sentences of metaphor-heavy prose. Front-loading the trigger would substantially improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with full schema coverage, annotations, and no output schema, the description covers trigger, idempotency, persistence, and scope. The main gap is that the phrasing is indirect enough that an agent must reread to extract the operating condition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'shelf' parameter is already documented in the schema, including the note that the plugin appends the word 'Notes'. The description adds only the implicit precondition that this applies where the plugin has no name, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb+resource is present ('Name the notes folder this platform stages to'), so the core action is identifiable, but it is buried in opaque framing about 'Living Projects', names 'given at the door', and 'registration'. It never states plainly how this differs from siblings like setup_home or connect_storage, which also configure per-platform storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('Pressed once after a NOT FOUND answer from save_note; the same save then goes through') and an explicit no-op condition ('once a note is saved under a name... pressing this again changes nothing'). It also scopes usage ('Notes only — captures do not depend on it'), though it does not name an alternative tool to use instead when the platform is already named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Reads the record's full inventory and complete contents, places the staged notes since the last standing whole after them, and names the earlier notes and the parking lot. Read-only: it writes nothing. Runs before organize_save.
| Name | Required | Description | Default |
|---|---|---|---|
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Read-only: it writes nothing' largely restates them. The added value is the disclosure that it computes an ordering/placement as a preparation step for organize_save, but the opaque phrasing ('last standing whole', 'the parking lot') leaves the actual behavior unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence plus a fragment; it is short, but jargon like 'since the last standing whole' and 'the parking lot' spends words without conveying meaning to an uninitiated agent. The read-only and ordering facts are correctly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple required param, no output schema, and annotations covering the safety profile, the description supplies the key remaining facts: no writes occur and it precedes organize_save. Only the return's shape ('names the earlier notes and the parking lot') is left vague, which is a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single home_path parameter is documented in detail with storage-prefix syntax. The description adds nothing about the parameter, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb+resource is buried in project-specific jargon: 'Reads the record's full inventory and complete contents, places the staged notes since the last standing whole after them.' An agent can infer it is a read/preparation step, and the closing line 'Runs before organize_save' names a sibling, but a stranger to this domain cannot state plainly what the tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Runs before organize_save' gives clear sequencing context, which is real usage guidance. However, there is no statement of when to skip it, whether it is mandatory before organize_save, or how it relates to the many other read siblings (read_home, list_homes, read_file).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Rewrites the home's current standing with the text it is given. Refuses unless organize_prepare ran recently on this connection, and one prepare opens one save. A hand this home is missing is supplied here. Takes the owner's own answer and keeps it in the standing's header. With the answer blank it is the preview: it writes nothing and shows the lines the finder marks, before the owner's yes. It cannot tell whether the owner was actually asked — it checks that an answer is carried, not that it is true. Doubt wording and telling words outside quoted words — "remains to be confirmed", "unconfirmed", "should", "never" and the like — are saved as written, and the answer marks the lines.
| Name | Required | Description | Default |
|---|---|---|---|
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| owner_answer | Yes | ||
| standing_text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag a destructive, non-read-only write; the description adds real context beyond that: prepare pairing, refusal behavior, preview mode, the fact that it cannot verify the owner was actually asked, and that doubt wording is saved verbatim. It stops short of saying what happens to prior standing content or whether the overwrite is recoverable, which matters for a destructiveHint tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the length is moderate, with most sentences carrying operational information. However, the dense run-on phrasing and unexplained metaphors ('hand', 'finder marks', 'the owner's yes') make it harder to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, preparation-gated mutation with no output schema and low schema coverage, the description covers prerequisites, preview mode, and validation limits. It omits what the save returns, how standing_text is merged into existing standing content, and what happens to the prior version — gaps an agent would need before invoking confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must carry the other two parameters. It does add meaning for owner_answer (stored in the standing's header; blank triggers preview) and standing_text (saved as written, with answer marks), but the explanations are embedded in opaque prose rather than clear field-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource — rewrites the home's current standing with the supplied text — and the prepare dependency distinguishes it from siblings. But key terms ('standing', 'a hand this home is missing', 'the finder marks') are metaphorical and undefined here, so an agent cannot fully picture what artifacts are produced or changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a hard precondition (organize_prepare must have run recently on this connection, one prepare opens one save) and a clear alternate mode (blank owner_answer = preview that writes nothing). It does not name other siblings like save_note or supersede, but the when-to-use and when-refused guidance is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Keep a long first-person account whole and verbatim as a permanent raw-source artifact.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, non-destructive, closed-world write. The description adds useful behavioral context by saying the account is kept whole, verbatim, and permanent, but it does not explain overwrite behavior, naming conflicts, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no obvious filler. It is efficient, though its brevity leaves gaps that other dimensions capture.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with three required parameters, low schema coverage, and no output schema, the description is too thin. It gives the artifact concept but leaves the semantics of title and content unclear, which is a significant gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only home_path documented in the schema. The description does not clarify the roles of title or content, so it does not compensate for the undocumented required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: keeping a long first-person account whole and verbatim as a permanent raw-source artifact. It is clearer than the bare tool name, but it does not explicitly distinguish this from sibling save/capture tools such as save_note or capture_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case for long first-person accounts, but it gives no explicit when-to-use guidance, no exclusions, and no named alternatives. An agent must infer whether this should be used instead of save_note or the capture_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Read one file inside a home (path relative to the home). Read-only; paths outside the home are refused. An address that begins with the home's own name is read from inside the home.
| Name | Required | Description | Default |
|---|---|---|---|
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| relative_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a genuine behavioral constraint not present in annotations: attempts to read outside the home are refused, which tells the agent the sandbox is enforced server-side rather than validated by the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short clauses with the main operation and scope front-loaded, and no wasted preamble. The final sentence about a path beginning with the home's own name is dense and slightly redundant with the parenthetical, but it is not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read tool with annotations covering safety, the definition covers scope and boundary enforcement. With no output schema, it leaves unstated what reading returns (file contents? encoding? size limits?), which matters for a tool whose name is read_file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: home_path is well documented in the schema, while relative_path has no schema description. The description partially compensates by defining relative_path as relative to the home and by noting that an address beginning with the home's own name resolves inside the home, though that last clause is ambiguous rather than clarifying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (read) and resource (one file) plus the scoping constraint that the path is relative to a home, which separates it from read_home and update_home_file. It does not name a sibling outright, so differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only framing and the refusal of out-of-home paths imply when this tool applies, but there is no explicit when-to-use guidance versus read_home (whole-home view) or raw_source. The agent must infer the boundary from the requirement to supply both home_path and relative_path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — A home's home file, current standing, record inventory and staged notes, returned together — where the work in this home stands. Where the home file is out of date it answers with the update offer ALONE and waits for the owner's yes or no; read the home again after either and it shows whole. The question comes at every read until it is answered; the answer is given through update_home_file. Read-only: it writes nothing. A hand this home is missing is named, and the next organize_save supplies it.
| Name | Required | Description | Default |
|---|---|---|---|
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/destructive=false, so the 'it writes nothing' line adds little. The real value is the disclosed partial-return behavior: when the home file is stale the tool answers with the update offer ALONE and repeats that question on every read until answered — a non-obvious contract that changes how an agent must interpret an empty-looking result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Roughly four sentences of high information density, but the front-loading is weak — the opening is a stacked noun phrase rather than a plain statement of what is returned. Jargon such as 'a hand this home is missing' is opaque and costs the reader effort without adding precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by enumerating the four returned components and the special update-offer response mode. It stops short of describing ordering or size of the inventory, but an agent has enough to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single home_path parameter is thoroughly documented in the schema, including storage-prefix syntax. The description adds no additional semantics about the path, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause names the resource and enumerates what comes back (home file, current standing, record inventory, staged notes), so the agent knows this is a consolidated home-state read. It is distinguishable from read_file, though the phrasing is dense and the reader must parse the appositive stack to extract the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to re-read ('read the home again after either') and routes the answering action to update_home_file, plus notes that organize_save supplies a missing hand. It never explicitly excludes read_file for plain file reads, so the sibling boundary is implied rather than declared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Save a dated, create-only note into this platform's own notes folder inside the home. The notes folder is named by the plugin from the name this tool gave at the door, and it is the same name in every home; a notes folder renamed by hand inside the home is still found. There is no argument for naming it: the caller does not name the notes folder. A note holds what settled, in the owner's words. It is saved once the file verifiably exists. An idea with no home yet goes to the home's own Parking Lot folder instead of a notes folder. A note whose name begins fact holds one thing that became true without being chosen — "fact — next keep-alive click before 27 September". The name is the fact, and the newest name on a subject is the current one. A settled fact inside a longer note — a submission, a status change — is also saved as its own fact note, so the facts list shows it by title. A NOT FOUND answer means no folder name is saved on this connection yet: the owner names the folder once, name_platform keeps the answer, and the same save then goes through. Doubt wording and telling words outside quoted words — "remains to be confirmed", "unconfirmed", "should", "never" and the like — are saved as written, and the answer marks the lines. Language: The record is written as a description of what is true, what was settled, and how the work runs. A sentence that describes what happened stays true after the moment passes. Code blocks and quoted words are kept as they are. Example: The cat likes the tree because there are birds in it. It climbs up in the mornings, when the birds are loudest.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| parking_lot | No | Yes sends this note to the home's own Parking Lot folder instead of a notes folder. Leave it out otherwise; the caller does not name the notes folder. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare create-only, non-destructive, non-open-world, and the description is consistent while adding real behavior: success is gated on the file 'verifiably exists', a NOT FOUND answer has a defined recovery path through name_platform, the folder name is plugin-owned and not caller-settable, and the returned answer marks doubt-wording lines. The one gap is that it never says what the normal return value contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead is front-loaded, but the body sprawls into cryptic, self-referential sentences such as 'The notes folder is named by the plugin from the name this tool gave at the door, and it is the same name in every home', which is restated again later. Several sentences do not earn their place and the run-on structure makes the actual rules hard to extract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter create tool with annotations but no output schema, the description covers error handling, naming, and content style. It is only partially complete: the shape of a successful response (path? confirmation?) is left implicit beyond a hint that doubt lines get marked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, so the description must carry title and content: it does, specifying the 'fact — ...' title convention with newest-name-is-current ordering, and a whole 'Language:' paragraph governing how content is written (descriptive-of-truth, code blocks and quotes preserved). It also forecloses a nonexistent folder-name argument. It adds real value beyond the bare string types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus its scope: 'Save a dated, create-only note into this platform's own notes folder inside the home.' The create-only nature and Parking Lot routing are concrete. It does not, however, distinguish itself from the many capture_* siblings that presumably also write notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives conditional routing: an idea with no home goes to the Parking Lot, and a NOT FOUND answer means calling name_platform first. But there is no explicit statement of when to use save_note versus capture_decision, capture_correction, capture_definition, or organize_save, which is the main ambiguity an agent faces here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Install a Living Projects home into a folder in the connected storage (Dropbox, Google Drive, or OneDrive). The folder is made when it is missing, so nothing needs checking or confirming before the press. The home is a Living Projects folder holding an empty record folder, a plugin folder, and the home file (HOME.md) copied from the standard text with the project's name filled in. Notes folders are not pre-built — each platform's is born there when it first saves. The project's folder itself becomes the home: it installs into the folder it is given, beside whatever is already there. An existing home file stops the install; the three script hands are written over where the plugin folder holds them; nothing else in the folder is touched.
| Name | Required | Description | Default |
|---|---|---|---|
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| project_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description goes further by scoping the destruction precisely: an existing home file aborts the install, three named script files in the plugin folder are overwritten, and nothing else in the folder is touched. That is exactly the extra context an agent needs before approving a write to a user's storage folder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, but the prose is bloated and occasionally opaque — 'before the press', 'the three script hands', and 'each platform's is born there when it first saves' require re-reading. Several sentences do earn their place (the overwrite and abort rules), yet they are wrapped in unnecessary phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, two-parameter install with no output schema, it covers what is created, the abort condition, and the overwrite boundary. Gaps remain: it never says what the tool returns on success or failure, and it assumes rather than states that a storage connection already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (project_name has no description at all), and the description compensates by explaining that HOME.md is 'copied from the standard text with the project's name filled in', which defines what project_name actually does. It also clarifies home_path semantics ('installs into the folder it is given, beside whatever is already there'), though it adds nothing on path syntax beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: installs a Living Projects home (a folder containing a record folder, plugin folder, and HOME.md) into a given folder in connected storage. The word 'Install' plus the enumeration of what the home contains clearly separates it from read_home, list_homes, update_home_file, and connect_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: 'nothing needs checking or confirming before the press' and 'An existing home file stops the install' tell the agent it can be called directly and will fail if a home already exists, hinting at list_homes/read_home as the check. But it never explicitly says when to prefer this over siblings, nor that connect_storage must have succeeded first, so the prerequisites are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Mark a record entry as superseded, with the reason and the kind it is in (decision, rejection, definition, or correction). History stays; there is no button for deleting or editing it.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| reason | Yes | ||
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. | |
| entry_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a non-read-only, non-destructive, closed-world mutation. The description usefully adds that history is retained and that there is no delete or edit action, which confirms the non-destructive behavior in operational terms. It does not explain what happens if the entry is already superseded or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in a compact two-sentence description, and the history/no-delete caveat follows logically. The 'Living Projects —' prefix is product context rather than wasteful, though the description could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-required-parameter mutation with no output schema and only partial schema documentation, the description covers the core action, the kind values, and the retention behavior. It leaves out important operational details such as how to identify the entry number, what a successful supersede returns, and whether an already-superseded entry can be superseded again.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25%; only home_path is described in the schema. The description compensates meaningfully for kind by enumerating the four accepted categories, and reason and entry_number are semantically self-explanatory from their names. Still, it does not clarify the expected format of entry_number or reason beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Mark a record entry as superseded.' It also names the four kinds (decision, rejection, definition, correction), which clarifies the scope better than the title alone. It does not explicitly distinguish itself from the capture_* siblings, which likely create new records rather than supersede existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Mark a record entry as superseded' and by the statement that history stays with no button for deleting or editing it, suggesting this is the replacement mechanism rather than deletion. However, it never explicitly says when to use supersede versus capture_correction or capture_decision, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Living Projects — Rewrite this home's home file (HOME.md, in its Living Projects folder) from the standard text, keeping the old one beside it as a dated copy. Pressed only on the owner's yes — a home file is the owner's own writing, and anything in it that is not in the standard is lost from the live file (recoverable from the copy kept beside). WITH PREVIEW TRUE IT ANSWERS WHAT IS IN THE UPDATE — what the new version contains, where this home's file stands, what a yes does, what a no does, what would be lost, and the whole new text — AND WRITES NOTHING. WITH DECLINE TRUE IT RECORDS THE OWNER'S NO — writes the marker only, so the question waits for the next standard, and changes nothing else. On a yes it touches the home file and writes the marker.
| Name | Required | Description | Default |
|---|---|---|---|
| decline | No | True records the owner's no and changes nothing else. Leave out otherwise. | |
| preview | Yes | True shows the text and writes nothing. False writes it. | |
| home_path | Yes | The home folder's path in the connected storage (Dropbox, Google Drive, or Microsoft OneDrive), e.g. /LIVING PROJECTS or /condo. A path that begins with the storage's name, e.g. 'dropbox:/condo', 'google drive:/condo' or 'onedrive:/condo', reaches that storage on the first press; with more than one storage connected the name is needed, so it is given whenever the storage is known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses exactly what is destroyed (anything in the owner's file that is not in the standard, from the live file), what recovery exists (the dated copy kept beside), and what each no-write mode does to state. This matches destructiveHint=true and adds the precise scope of the loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence front-loads purpose well, but the all-caps mode blocks are shouty and partly restate the schema's own parameter descriptions. Content earns its place, but the formatting and repetition cost readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description steps in to say what preview returns — contents of the new version, where the file stands, what yes/no do, what would be lost, and the whole new text — so an agent knows what to expect. The write-mode response is only summarized, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema cannot: the interaction between preview and decline, and the fact that decline takes effect without a rewrite. It does not add path formatting detail beyond the schema, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — rewrite this home's HOME.md in its Living Projects folder from the standard text — plus the side effect of keeping a dated copy. It is clearly distinguishable from read_home (reads) and setup_home (initial creation) 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit mode conditions: preview=true answers and writes nothing, decline=true records the no and changes nothing else, and the write fires only on the owner's yes. It does not name sibling alternatives, so it falls just short of a 5, but the when/when-not guidance is unusually precise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
capture_correctioncapture_decisioncapture_definitioncapture_rejectionconnect_storagelist_homesname_platformorganize_prepareorganize_saveraw_sourceread_fileread_homesave_notesetup_homesupersedeupdate_home_filePrivate projects, preflight, decisions, and handoffs that keep work continuous across AI tools.
Shared project memory that keeps teammates and AI agents aligned across sessions.
One memory for every AI you work with: your rules, notes and decisions in your own Git repo.
Bring your saved preferences, project decisions, and useful context into your next AI conversation.
Add one secure layer between your agents and this server.
