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

With no annotations available, the description carries the full burden. The verb 'Read' makes clear it is non-mutating, and it transparently states the content is identical to the server instructions. It does not explicitly mention idempotence or the absence of side effects, but for a read-only informational tool this is sufficient and adds useful context.

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 two sentences with no filler. The first sentence front-loads the purpose and enumerates the key content areas; the second provides the usage context. Every clause earns its place, and it remains compact despite listing multiple topics.

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 zero-parameter, no-output-schema tool, the description is complete: it says what the tool returns (the briefing), what that briefing contains, and exactly when to call it. No prerequisites or additional context are needed for an agent to invoke it correctly.

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 has zero parameters and schema coverage is 100% (trivially). The baseline for no parameters is 4; the description adds no parameter-specific detail because none is needed. It correctly focuses on the output and usage instead.

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 ('Read') and resource ('who Mnemosyne OS is and the rules you must honor'), then enumerates concrete content items (governance tenet, vault protection model, spine model, do/don't behavior). This clearly differentiates it from the sibling tools, which are all operational (memory, agenda, vault, etc.).

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 explicitly gives when to use the tool: 'Call this to re-read it, or if your client did not surface those instructions.' It also notes the same briefing is delivered on connect, making the tool's redundancy clear and giving the agent a reason to invoke it.

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

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

With no annotations, the description carries the behavioral burden and does it well: it discloses that this is a write routed through the widget's store, that what is filed is exactly what the human sees, and that installation mode affects whether the app must be running. It does not cover duplicate handling, failure behavior, or the exact return payload, but the core behavioral traits are clearly stated.

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 front-loaded with purpose, then gives trigger examples, behavior, environment caveats, and sibling routing in a compact sequence. Every sentence earns its place, and no information is repeated from the schema.

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 create tool with a rich schema and no output schema, the description covers what it does, when to use it, the write path, environment requirements, and where to look for the result. It does not explicitly state the function's return value or error behavior, but the visible outcome statement ('what you file is exactly what the human sees') and the detailed schema largely compensate.

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 nested parameter descriptions already explain start, end, all_day, recurrence, location, description, and alarm_minutes_before in detail. The tool-level description adds no parameter-level meaning beyond 'appointments or deadlines', so the baseline score 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 description opens with a specific verb and resource: 'Put appointments or deadlines into the human's calendar (the Agenda widget on their canvas)'. It also names the sibling tools for list, update, and remove, making it unmistakable which operation this tool performs.

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 condition ('Use it when a conversation names a specific date/time to remember') and specific example phrasings. It also routes the agent to the correct alternatives for reading, changing, or removing calendar entries, and adds environment-specific prerequisites about the daemon and app state.

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

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

With no annotations provided, the description carries full responsibility and does so thoroughly. It discloses that there is no archive, removal cannot be undone, repeating events are collapsed to one occurrence with cadence and next date, times are machine-local, and headless operation depends on dev install vs npm install. This goes far beyond basic read-vs-write labeling.

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 dense but every sentence earns its place: purpose, ID requirement, mutation caveats, repeating-event behavior, timezone, environment constraint, and scope. The most important operational guidance is 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?

There is no output schema, so the description must convey what the caller gets back. It does: appointments with IDs, one entry for repeating events with cadence and next occurrence, and local times. Combined with full parameter coverage the tool is effectively self-contained for an agent to use correctly.

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 input schema covers all 4 parameters with full descriptions, so the baseline is 3. The tool description does not add parameter-level detail, though it does clarify the semantics of repeating events, which helps interpret from/to and include_past results.

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: 'Read the human's calendar back' with a time-window scope. It also names the essential output (appointment IDs) and differentiates itself from the mutation siblings by explaining that update/remove require these IDs.

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?

Explicitly instructs to call this BEFORE mnemosyne_agenda_update or mnemosyne_agenda_remove, explains that those tools identify appointments by ID only, and warns about irreversible removal. It also gives environment-specific guidance for dev installs vs npm installs, leaving no ambiguity about when the tool works.

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

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

With no annotations, the description carries the full burden of behavioral disclosure and does so thoroughly: removal is permanent with no archive, repeating appointments are removed as a whole series, and the tool names each removed appointment by title and start time in its response. The headless-daemon requirement is also disclosed, making side effects visible before invocation.

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 dense but every sentence contributes a distinct operational fact. The core instruction to read first and pass ids is front-loaded, and the remaining caveats are ordered by practical importance with no filler or redundancy.

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 destructive action with no output schema, the description covers the input source, matching rules, deletion permanence, recurrence behavior, runtime prerequisites, and what the response will report. Nothing critical is missing for an agent to invoke it safely.

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 schema already documents the ids parameter well, but the description adds important semantic constraints: ids must come from mnemosyne_agenda_list, matching is strictly by id rather than by title or date, and there is a concrete warning against natural-language date matching. This adds real meaning beyond the schema's type and count.

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 clear, specific verb and resource: REMOVE appointments from the human's calendar. It also distinguishes this tool from alternatives by explicitly saying it never matches by title or date, which makes the purpose unmistakable even among agenda siblings.

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 tells the agent to read appointments with mnemosyne_agenda_list first and pass the returned ids, and warns against title- or date-based matching with a concrete failure example. It also addresses repeating appointments and the dev-install versus npm environment differences, which leaves no ambiguity about how and when to use it.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses partial-update behavior (omitted fields untouched, null clears), strict refusal of unreadable start/end times, refusal of unsupported cadences, environment-dependent execution (headless daemon vs app running), and the required scope: agenda:write.

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 front-loads the primary purpose and then packs prerequisites, error behavior, and environment notes into a compact paragraph. Every sentence adds operational value, with no filler or repetition.

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 complex tool with a nested changes array, no output schema, and no annotations, the description covers the essential decision points: how to identify the appointment, how omitted/null fields behave, what inputs are refused, and whether the daemon is required. The only minor gap is atomicity across the array, but that is not essential for correctly invoking the tool.

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 schema already documents every field (100% coverage), so the baseline is 3. The description adds a global update rule 'a field you leave out is left alone; passing null CLEARS it' and instructs the agent to source event_id from mnemosyne_agenda_list, which goes beyond the schema by clarifying omission vs null 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 description opens with the verb 'CHANGE' and names the exact resource: an appointment already in the human's calendar. It enumerates the supported mutations (move, rename, add/drop reminders, start/stop repeating) and explicitly says appointments are identified by the id from mnemosyne_agenda_list, making it clearly distinct from add/remove/list siblings.

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 gives an explicit prerequisite: call mnemosyne_agenda_list first to obtain the appointment id. It also provides operational context such as null-clears-field semantics and the daemon/running-app requirement on dev installs vs npm installs, but it never explicitly names when-not alternatives like agenda_add or agenda_remove.

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

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

With no annotations provided, the description carries the full burden, and it does so exceptionally: it reveals the data source (transcript files on disk), independence from Mnemosyne OS and tokens, working-tree resolution behavior, and the critical limitation that a clean answer only means nothing was found in readable transcripts. It also discloses how unreadable and unplaceable sessions are handled rather than guessed.

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 longer than typical but front-loads the core question and call-time guidance before the caveats. Each sentence contributes a distinct fact, though the readability and transcript-location limitations could have been compressed into fewer sentences.

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 tool with no annotations and no output schema, this description is unusually complete: it explains prerequisites, source of truth, limitations, and the shape of results, including clean answers, missing transcripts, and unplaceable sessions. An agent has enough contextual detail to invoke it correctly and to interpret its results appropriately.

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 input schema already documents the only parameter, `project`, including exact matching, normalization, and omission semantics, giving 100% schema description coverage. The prose description adds useful context about working-tree resolution, but it does not substantially add parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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 opens with the precise question the tool answers: whether two agent sessions are live in the same git working tree and branch, from any installed harness. It also names the concrete operational niche, before git add, commit, and rebase, which clearly separates it from sibling tools such as mnemosyne_git_log. The resource and purpose are unmistakable.

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 explicitly prescribes when to call the tool: before `git add -A`, before a commit, and before a rebase, with a rationale about the shared git index. It does not explicitly name when-not-to-use it or point to an alternative sibling, but the timing guidance is strong enough for an agent to select it correctly.

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

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

With no annotations, the description carries the full burden and does so thoroughly: newest-first ordering, paths/timestamps only, reliability caveat for 'from a command' entries that may never have completed, and provenance labeling ('recorded' vs command). This goes well beyond a basic 'list files' statement.

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?

Waste-free and front-loaded: the key result appears in the first sentence, followed by caveats and a usage directive. All five sentences earn their place, and code spans keep technical terms readable.

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?

Everything needed to call and interpret the result is present: output fields, ordering, provenance, scope, and a concrete use case. The absence of an output schema is compensated because the description names exactly what each line contains.

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%, so the schema already documents limit, project, and contains; baseline of 3 applies. The description adds no extra meaning for these parameters, but none is needed given the schema's clarity.

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 exactly what the tool returns: file paths that other agent sessions wrote or edited, newest-first, with the originating session. It also fences scope ('other agent sessions', 'spans every installed harness') and explicitly excludes file contents, which sets it apart from memory/agenda siblings.

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?

Ends with a direct usage cue: use it before editing an area another session has already touched. It gives clear context but does not enumerate exclusions or contrast with a named sibling such as mnemosyne_git_log.

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

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

With no annotations, the description carries the full burden, and it delivers exceptionally: it discloses the read-only nature (reads transcripts, returns metadata only), the cross-harness scope, the critical caveat that crashed and idle agents are indistinguishable so it reports 'last SEEN' and the agent must conclude, and the OS-closed compatibility. The crash-vs-idle warning is exactly the behavioral nuance that prevents an agent from drawing false conclusions.

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 long but every sentence carries unique value: purpose, scope, return content, usage timing, and a critical semantic caveat. It is front-loaded with the core purpose and the behavioral warning earns its place; only minor tightening would be possible without losing information.

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?

Despite no output schema and no annotations, the description fully compensates: it enumerates the returned metadata fields, explains the scope, provides the interpretation caveat, and gives usage context. For a moderate-complexity read-only list tool, nothing an agent needs to invoke it correctly is missing.

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%, so the baseline of 3 applies; the schema already documents all three parameters thoroughly. The description adds no parameter-level detail beyond the schema, which is acceptable since the schema descriptions themselves are excellent (e.g., explaining why limit is per-harness rather than merged).

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 precise action (list coding-agent sessions), a specific source (transcripts on disk), and a scope (ALL harnesses, not just its own). It enumerates the exact metadata returned, making it unmistakable what this tool does and how it differs from related agent tools like mnemosyne_agent_collisions and mnemosyne_agent_files.

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 when-to-use guidance ('Use it before you touch shared state') and explains how to interpret results. It doesn't name sibling alternatives or state when NOT to use it, but for a list/read tool with 23 siblings of clearly different purposes, the contextual instruction is strong enough.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals that the state is user-declared, the host prints time since last call, the card goes quiet if not updated, the answer contains any human message, the app window must be open, and nothing is stored in memory. This is thorough and goes beyond the 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 description is four sentences, front-loaded with the purpose and followed by concise usage and behavioral notes. Every sentence adds value, and there is no redundancy or fluff. It is efficient and well-structured.

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?

There is no output schema, so the description must explain return values; it does ('The answer carries any message the human left on your card'). It also covers requirements (app window open), memory behavior, and the meaning of states. It does not mention the 'closed' state, but that is in the schema, so the description is complete enough for a simple tool.

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% with detailed parameter descriptions, so the baseline is 3. The description adds usage context (e.g., 'working' + a short title and status) but does not introduce new semantics for any parameter beyond what the schema already provides. It reinforces but does not enhance 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?

The description clearly states the tool's purpose: updating your own status card on the human's canvas (the cockpit). It explicitly lists the trigger events (start, need, stuck, done) and distinguishes itself from sibling tools like mnemosyne_position_update by focusing on the cockpit card status. The verb-resource pairing is implicit but unambiguous.

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 gives explicit when-to-use instructions: call it when starting a task, when needing the human, when blocked, and when done. It also advises calling at real milestones to avoid the card going quiet. It does not mention alternatives or exclusions, but the context is clear and specific.

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

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

With no annotations provided, the description carries the full burden. It discloses that bridges are produced during idle-time scans, that an empty list is normal, and that the engine runs only if enabled in Settings. It also explains the scoring components (dbs and raw cosine). It does not mention auth or rate limits, but the read-only 'List' intent is clear.

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, with the core purpose front-loaded and supporting use cases and edge-case behavior following in order. It is slightly dense but each sentence earns its place; nothing is redundant or 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?

Given no output schema, no annotations, and four optional parameters, the description supplies the needed behavioral and interpretive context: what a bridge is, how scores work, what empty results mean, and why one would call this tool. It could go deeper on session/chronicle filtering semantics, but the schema already covers those.

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 adds general context (dbs is composite/prime-aware, ordering by strength) but does not add meaning beyond the schema's own parameter descriptions. This is acceptable given full schema coverage.

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 ('List'), a clear resource ('connections... between memories'), and a distinctive source ('Dream State engine's offline scans'). It is easily distinguished from siblings like mnemosyne_resonance_list or mnemosyne_memory_query by its focus on dreamed/idle-time associations.

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 gives explicit use cases: surfacing non-obvious associations, auditing whether dreams are insightful or noise, and seeding creative exploration. It also explains the empty-list case. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden, and it delivers: it declares read-only behavior, discloses the fixed repository path and its consequence, states the required scope, and explains failure behavior (naming what is missing rather than returning an empty list that could mislead). This is rich behavioral context well beyond a simple verb.

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?

Every sentence earns its place: purpose, safety, return format, constraints, error behavior, and routing to the sibling tool. The most important scoping and behavioral facts are front-loaded, and there is no filler or repetition.

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 moderate-complexity read tool with no annotations and no output schema, the description is complete: it explains what is returned, the ordering, the fixed repository limitation, required permissions, error semantics, and the closest alternative. An agent has everything needed to invoke and interpret this tool correctly.

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?

Both parameters are already fully described by the schema (100% coverage), so the baseline of 3 applies. The description adds contextual value by noting the newest-first ordering, but it does not need to restate parameter details since the schema already documents limit and since.

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 opens with a specific verb and resource: 'Read recent commits from the Mnemosyne OS monorepo.' It further specifies return content (hash, subject, author, date) and order (newest first), and distinguishes itself from mnemosyne_memory_query, making its purpose unambiguous even among many siblings.

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 explicitly states when to use the tool: 'Use it for what changed and when,' and names the alternative for related but different needs: 'mnemosyne_memory_query for the reasoning behind a change.' This gives an agent clear selection criteria without ambiguity.

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

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses the RAG pipeline behavior, latency up to ~30s, the fact that output is a model reworded synthesis rather than verbatim memory, the presence of a Sources list, and a strong hallucination-safety warning. This is far beyond a simple 'ask a question' summary.

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 longer than average but information-dense and front-loaded with the core function, followed by usage guidance, latency, and safety warnings. Nearly every sentence earns its place; the dated benchmark 'measured on 2026-08-31' and the detailed pipeline parenthetical add credibility but are slightly expendable.

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 tool with no annotations and no output schema, the description is surprisingly complete: it covers what the tool returns (synthesized prose plus sources), how long it takes, which sibling to compare against, how to phrase questions, and critical trust caveats. An agent has everything needed to invoke it correctly and interpret its output safely.

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 meaningful invocation guidance beyond the schema: concrete example questions ('why was SQLite chosen over Postgres?', 'who is <name> and what do they own?') and the type of questions it is best for. It does not add detail about the vault parameter, but the schema already documents the default and scope-denial behavior.

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 opens with a specific verb+resource: 'Ask Mnemosyne a question and get a SYNTHESIZED prose answer grounded in the vault, PLUS the chronicles it drew on.' It clearly differentiates from the sibling mnemosyne_memory_query by explicitly positioning this tool as both the reasoning tool and the better retriever, and by naming the slower latency tradeoff.

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 guidance is explicit and actionable: 'reach for it whenever you need to find something', 'Best on "why / who / how" questions spanning many memories', and 'Slower than mnemosyne_memory_query (up to ~30s)'. It also tells the agent when to switch to the alternative ('fetch them with mnemosyne_memory_query'), covering both when-to-use and when-not-to-quote-prose.

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

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

No annotations are provided, so the description and schema must carry the behavioral burden. The description states persistence is permanent, that content is indexed for semantic retrieval, and that any agent may later retrieve it. The vault parameter additionally warns that ingest is permanent and to confirm the vault exists before writing somewhere new. This meaningfully discloses consequences beyond what structured fields alone would 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?

The description is two focused sentences: the first states the action and scope, the second gives direct usage guidance. Every sentence earns its place, and important behavioral qualifiers like 'permanently' and 'indexed' are front-loaded rather than buried.

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?

Given the rich schema descriptions, no annotations, and no output schema, the description is largely complete. It covers what the tool does, why to use it, and key consequences (permanence, indexing). It does not describe the return value or explicit success confirmation, which is a minor gap since no output schema is 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 description coverage is 100%, so the baseline is 3. The main description does not add parameter-level details beyond what the schema already provides; however, the schema's own parameter descriptions are rich, covering vault tokens, permanence, content self-containment, and spine_type semantics. The description's examples align with the enum values but add no new parameter 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 description opens with a clear verb and resource: 'Persist a memory into the Mnemosyne OS vault,' and enumerates concrete content types (decision, architecture note, debug finding, session summary). This differentiates it from query/read siblings like mnemosyne_memory_query and mnemosyne_memory_ask, which retrieve rather than store.

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?

Explicit trigger conditions are given: use at the end of a meaningful work session or whenever a decision reaches a point where future recall matters. It does not explicitly name alternatives or exclusion cases, but the clear write-vs-read contrast with the sibling tools makes the intended usage evident.

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

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

With no annotations present, the description carries the full behavioral burden, and it delivers: it states that nothing is rewritten, explains the ranking mechanism (vector similarity fused with BM25, weighted by spineType), and discloses the non-intuitive behavior that hits and misses have indistinguishable scores. This goes well beyond a generic search description.

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 front-loaded with the core purpose, then returns behavior, then use cases, then alternatives and caveats. Every sentence adds distinct value; the warnings and sibling comparison are dense but not padded.

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?

Even without an output schema, the description tells the agent what comes back (matching chronicles, truncated snippets, decorations hinting at total size) and how to interpret it. Combined with complete parameter documentation in the schema, the agent has enough context to select and call the tool correctly.

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%, so the parameters themselves are already well documented in the input schema. The tool description adds ranking context and a score caveat but no additional parameter-level semantics, so the baseline of 3 is appropriate.

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: 'Raw chronicle search in a Mnemosyne OS vault' that returns 'the matching chronicles themselves' for reading, ranking, and citing. It also separates this tool from mnemosyne_memory_ask by framing query as verbatim-source retrieval and ask as find-and-surface retrieval.

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 guidance is explicit: use this tool when you need source text verbatim for quoting or documentation, and prefer mnemosyne_memory_ask when the goal is to find something rather than to quote it. It even warns against treating scores as confidence, which directly shapes correct invocation and interpretation.

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

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

With no annotations, the description carries the full burden and meets it: it discloses the freshness constraint ('never fresher'), the meaning of 'No radar' (no scan projected, not nothing found), the app-running requirement, and how tier is assigned. These are real behavioral details beyond a generic 'read' label.

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?

Four sentences, each carries distinct information: what is read, freshness caveat, use case, no-radar semantics, and app dependency. Slightly dense with parentheticals, but no filler or repetition.

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 read tool with no output schema, it describes the returned contents (threads, topic score, tier), a key temporal caveat, and special 'No radar' response. The only structured details left to the schema are limit/tier filters, which are documented. Nothing an agent needs to call it correctly is missing.

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 covers both parameters 100%, so baseline is 3. The description adds semantic value by defining high/mid/low as 'how much substance THEY can bring to that thread', which the schema doesn't explain. It doesn't add anything about limit, but the schema's description already covers default/max.

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 ('Read') and resource (the human's Pheme radar last scan), and enumerates returned content: fresh threads, topic score, and tier. It is clear what the tool does, but it doesn't explicitly differentiate from siblings like mnemosyne_pheme_watch, so it falls short of a 5.

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 an explicit use case: 'Use it to find threads to draft a reply for; the human posts the reply.' It also states operational prerequisites and what to do when 'No radar' is returned. However, it names no alternative tools or when-not-to-use conditions, so guidance is context-rich but not exclusionary.

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

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

With no annotations at all, the description carries the full burden, and it delivers: refused empty-list removals, per-op outcome reporting, user-visible receipts, no posting/scanning, human posts, and an app-running prerequisite. This is exactly the behavioral context an agent needs before invoking a mutation-like 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 description is front-loaded with the action, then invariants, use case, and constraints in order. It is slightly dense and uses in-house jargon ('settings mirror lives in it'), but every sentence carries substantive guidance.

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?

Despite having no output schema and no annotations, the description tells the agent what results to expect (done/already there/not there/refused), what can't happen, and what environment is required. For a watchlist-mutation tool with one parameter, nothing essential is missing.

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%: op, kind, and value are already documented, including r/-optional subreddits, the 120-character cap, and the three kinds. The description adds no parameter-level detail beyond that baseline; it does add behavioral context but that belongs to transparency.

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 managed resource (the human's Pheme radar), the operations (add/remove watch items), and the item kinds. It is clear and distinctive, but it never contrasts with the likely read-side sibling mnemosyne_pheme_radar, so the distinction is left to inference.

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 ('Use it when a conversation has found a community worth watching') with a concrete example, and sets boundaries ('does not scan', 'does not post'). It does not explicitly state when to prefer a sibling or when not to call it, so it stops short of full routing guidance.

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

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

Annotations are absent, so the description carries the full burden and meets it: it declares read-only behavior ('it queries memory and writes nothing') and discloses the critical edge-case trait that a missing record returns plain words instead of an error, so 'never recorded' and 'call failed' are distinguishable. This is richer than the typical skeletal description.

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?

Front-loaded with purpose, then progresses through behavior, return values, edge case, and usage guidance in a logical order. Each sentence earns its place; the only minor waste is 'Read-only' followed by 'writes nothing', which is trivial given the density of useful information.

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 present, the description correctly supplies the return contract by enumerating the returned fields. It also covers the no-record behavior, read-only safety, and prerequisite tool routing, leaving nothing an agent needs in order to call it correctly.

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%: the single resonance_id parameter is already documented with concrete examples ('agent-cockpit', 'mnemosync-p2p'). The description adds domain context about what a saved position contains but no new syntax or format guidance, 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?

Opens with a specific verb and resource ('Read the last saved position of one Resonance'), enumerates exactly what is returned (resonance id, saved time, chronicle spineType, whole note), and is clearly distinguishable from the sibling write counterpart mnemosyne_position_update. An agent can tell what this tool does 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?

Explicitly states when to use it ('Use it to resume work'), names the prerequisite call ('call mnemosyne_resonance_list first when you do not know the id'), and tells the agent the tool routes to mnemosyne_position_update on a never-recorded id. No inference is required.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does disclose that the operation persists data ('persisted as a DECISION chronicle') and describes what is recorded, but it does not mention permissions, idempotency, failure behavior, or whether the update overwrites or appends. For a mutation tool, this leaves significant gaps for an agent.

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 sentences with no redundancy. The main action is front-loaded, followed by usage timing and persistence detail. Every sentence earns its place, making it highly efficient.

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?

The tool is relatively simple with no output schema. The description covers the purpose, when to use, and what gets persisted. However, it does not mention what the tool returns (if anything) or any error scenarios, which would be useful for an agent. It is adequate but not comprehensive.

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%, so the schema already documents all three parameters. The description adds some context by indicating what to record (phase, current state, next steps), but this largely reinforces the schema descriptions rather than adding substantial new meaning. Baseline of 3 is appropriate.

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 clearly states the primary action: 'Update the current position of a Resonance' which is a specific verb and resource. It also explains the purpose of calling it at the end of a session. However, it does not explicitly name the sibling it is not (e.g., position_get), though the action is unambiguous.

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 provides explicit guidance on when to use: 'Call this at the end of a session to record where you left off'. It gives a clear usage context. It does not mention when not to use or alternative tools, but the context is sufficient for selection.

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

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

With no annotations provided, the description carries full behavioral burden and handles it thoroughly: it states the tool is read-only, writes nothing, has no active/paused filter, returns at most 30 candidates, and clarifies that an empty result means no resonances recorded rather than a failure. This is exemplary disclosure.

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?

Every sentence carries unique information: purpose, read-only guarantee, return fields, filtering limitations, empty-result meaning, and sibling routing. The description is front-loaded with the core purpose and avoids redundancy, making it dense but efficient.

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 and no annotations, the description fully compensates by specifying the exact fields in each entry (id, last phase, minutes ago, chronicle id), the absence of filters, candidate limits, and empty-result semantics. An agent has everything needed to invoke and interpret the call correctly.

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 has zero parameters, so the input schema is an empty object. Per the rubric, the baseline is 4 for 0 params; the description does not need to explain parameters. It instead adds context about what each returned entry contains, which is helpful even though no parameter semantics are needed.

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 opens with a specific verb and resource ('List the Resonances recorded in the default vault') and clarifies the read-only nature. It also distinguishes itself from sibling tools by naming mnemosyne_position_get and mnemosyne_position_update as the follow-up actions, making the tool's scope unambiguous.

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 explicitly explains what this tool returns (all resonances, no filter, max 30 candidates) and when to use alternates: calling mnemosyne_position_get for full detail and mnemosyne_position_update to write. This gives clear routing versus siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It conveys a read/inspect nature through words like 'Inspect' and 'audit', states ordering ('newest first'), and mentions that counts remain whole-vault. However, it does not disclose auth requirements, rate limits, or the exact response shape, which would strengthen transparency.

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 sentences carry the full value: the first states what the tool does and returns, the second states when to use it. There is no filler, and the most identifying information is 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?

This is a moderately simple inspection tool with zero required parameters and fully documented parameters. The description covers outputs, ordering, optional taxonomy, and practical use cases. It lacks an explicit return-format description, but given the rich schema and the tool's inspect-only nature, the context is largely complete.

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%, so the schema already documents all five parameters. The description adds context by linking spine_type to mnemosyne_memory_query's filter and clarifying the tool's audit purpose, but it does not add significant meaning beyond the parameter descriptions.

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 opens with a specific verb ('Inspect') and a precise resource: how Mnemosyne maps chronicle entries to spine assignments for a vault. It lists the distinct outputs (assignments newest first, whole-vault per-spine counts, optional taxonomy tree), which clearly distinguishes it from siblings like mnemosyne_memory_query and mnemosyne_vault_list.

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 gives concrete use cases: auditing auto-classification quality, viewing vault composition, and discovering taxon ids for spine_type_filter. It also names the sibling tool mnemosyne_memory_query as the place to pass those ids. It does not explicitly state when not to use this tool, but the intended contexts are clear enough.

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

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

With no annotations provided, the description carries the behavioral burden and does it well: it discloses that writes go through the widget's own store, that the user sees exactly what is filed, and that dev installs work with the app closed while npm installs require it running. It also surfaces LIST_NOT_FOUND behavior and warns against assuming default lists. It could add reversibility or permission details, but this is strong disclosure for an add operation.

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 long but each clause earns its place: primary action, trigger condition, list workflow, storage guarantee, environment caveat, and sibling routing. It is front-loaded with the core purpose and usage before diving into environment details. Slightly dense, but not bloated.

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 tool with four parameters, no output schema, and no annotations, the description covers the required input meaning, optional list creation behavior, failure/error flow, runtime environment differences, and related siblings. The only notable omission is an explicit success-return format, which is not strictly necessary 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?

The schema already covers all parameters at 100%, so the baseline is 3. The description adds meaningful calling strategy beyond the schema: invoke once without 'list' to discover existing lists, pass create_list:true to create one, and never assume a default list. This complements rather than repeats the schema descriptions.

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: put tasks into the human's To-do backlog in order and optionally under named steps. It also distinguishes this adder from related operations by naming mnemosyne_todo_list, mnemosyne_todo_update, and mnemosyne_todo_categories as the read/change alternatives.

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 explicitly says when to use the tool: after a conversation has settled WHAT to do, e.g., 'make tasks out of everything we said we would do'. It also gives concrete operational guidance for list handling and points to siblings for reading or changing the backlog, so the agent can route between related tools.

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

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

There are no annotations, so the description carries the full burden. It discloses destructive constraints, refusal behavior, the fact that the host will not pick a destination, why original lists are protected, and whether the app must be running. This is unusually thorough for a mutation 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 description is information-dense without padding: the core purpose is front-loaded, followed by the sibling distinction, refusal rules, and environmental caveat. Every sentence earns its place, even though the middle sentences have some parenthetical complexity.

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 tool with one nested-array parameter, no annotations, and no output schema, the description is complete enough: it covers what operations exist, when to choose this tool, what will be refused, protections for original lists, and runtime requirements. Nothing critical is left for the agent to guess.

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%, so the baseline is 3. The description adds meaningful semantic context beyond the schema by explaining the refusal conditions, the purpose of the operation types, and the distinction between workspace shape and work content, which helps an agent pick the right op values.

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: manage the To-do backlog's lists via create, rename/recolour, or remove. It also explicitly distinguishes itself from the sibling mnemosyne_todo_update by the workspace-shape vs work-in-it principle, so an agent can tell them apart without opening schemas.

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 names the alternative tool (mnemosyne_todo_update) and gives a clear decision rule: use this tool when changing the shape of the workspace, not the work in it. It also pre-warns about refusals for non-empty lists and original lists, plus environment differences between dev installs and npm installs.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it is a read-only scope ('todo:read'), reads from a file via a daemon in dev installs, returns IDs needed for later mutation, and explains that results always state how many matched and were cut. This goes well beyond the input 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 description is front-loaded with the core purpose, then adds targeted warnings, use cases, and environment context. Every sentence earns its place; the length is justified by the valuable guidance it conveys.

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 read tool with three optional parameters, no output schema, and no annotations, the description covers what is returned (lists, tasks, IDs, counts), when to use it, and operational prerequisites. Nothing essential is missing for an agent to select and invoke it correctly.

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%, so the baseline is 3 and the schema already documents list, limit, and include_done behavior. The tool description adds no additional parameter-specific meaning beyond what the parameter descriptions provide, so no upgrade is warranted.

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 opens with a specific verb and resource: 'Read the human's To-do backlog back: the lists that exist and the tasks in them.' It also names the distinguishing purpose of exposing task IDs for later mutation, and explicitly contrasts itself with mnemosyne_todo_update. This makes the tool's role unambiguous even among similarly named siblings.

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 explicitly states when to invoke this tool: before mnemosyne_todo_update, when answering 'what is on my plate', and before adding a duplicate via mnemosyne_todo_add. It also provides environmental guidance about dev installs versus npm installs. The usage conditions are concrete and actionable.

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

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

With no annotations provided, the description takes on the full behavioral burden. It discloses that removal archives by default and is restorable, that the batch applies as one save, that operations report their own outcomes, and that a stale id won't sink others. It also covers environmental constraints. Slight gaps like non-recoverable streak side-effects are left to the schema, but overall transparency is strong.

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 dense but every sentence earns its place, covering scope, prerequisite, destructive behavior, atomicity, error isolation, environment prerequisites, and required scope. It is front-loaded with the core purpose and operation list, with no filler or repetition.

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?

Given the tool's complexity (nested ops array with multiple operation types) and lack of output schema, the description provides everything needed to call it correctly: task id sourcing, operation semantics, permanent deletion nuance, batch behavior, per-operation outcomes, environment constraints, and auth scope. The note that each operation reports its own outcome compensates for the missing output schema.

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%, so the schema already thoroughly documents each field, including the op enum, permanent default, and field-specific behaviors. The description reinforces some key semantics (e.g., 'pass permanent: true only when...') but doesn't add substantial information beyond what the schema provides, keeping this at the baseline.

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 uses a specific verb ('CHANGE') with a clear resource ('the human's To-do backlog') and enumerates the exact operations: edit, tick off, move, remove. It also implicitly distinguishes itself from siblings like mnemosyne_todo_add by framing this as modifying existing tasks and requiring ids from mnemosyne_todo_list.

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 explicitly instructs to call mnemosyne_todo_list first to obtain task ids, which is a critical prerequisite. It also clarifies when to use permanent: true (only when outright deletion is requested) and notes environment-specific daemon requirements. It doesn't explicitly name mnemosyne_todo_add as the alternative for creating new tasks, but the 'CHANGE' framing makes the boundary reasonably clear.

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

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

With no annotations, the description carries the full behavioral burden and succeeds: it discloses that unconfigured vaults are flagged and refused, that the `id` line is the host's internal path and must never be re-passed, and it conveys the read-only nature of the call. This prevents real invocation errors against the sibling tools.

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 dense, purposeful sentences, front-loaded with purpose before usage and output mechanics. The minor template artifact '(bold, e.g. MNEMOSYNE_OS)' and the inconsistent TOKEN/token casing keep it from a perfect structural score.

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 zero-parameter listing tool with no output schema and no annotations, the description covers everything an agent needs: the returned fields, when to call it, how to consume the result in sibling calls, and the access-control failure mode for unconfigured vaults. No critical gap remains.

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 input schema is empty, so the baseline is 4, and the description still adds value above it: the token-vs-`id` guidance teaches the agent exactly what to feed into the sibling tools' `vault` parameter, avoiding a common misuse. Since there are zero parameters, the description cannot do more than this, and it does it well.

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 the memory vaults this Mnemosyne OS exposes') and names the output contract (TOKEN, display name, chronicle count). None of the 24 siblings deals with vault enumeration, so it is clearly distinguishable 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 two explicit trigger conditions ('when you are unsure which vault to query/ask/ingest against' and 'when the user refers to a memory store by a name you have not seen') and positions it as the entry point ('Call this first'). It also routes the agent to the downstream tool families by explaining how the returned token becomes their `vault` argument.

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