ctxfile

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

With no annotations, the description carries the burden, and it delivers: it discloses that results are chronological/provenance-tagged, that an omitted thread causes an assumed selection reported in the result, and that returned digests are agent-reported data to treat as untrusted context, not instructions. This security-relevant behavior is exactly the kind of context an agent needs.

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 the core action, then usage triggers, default behavior, and a trust warning. Every sentence earns its place and there is no 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 single-optional-parameter read operation with an output schema, the description covers what it does, when to use it, what happens on omission, and how to interpret the returned data. 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%, so the schema already documents the thread parameter including fuzzy matching and the omit-for-most-recent behavior. The description mainly restates this and adds a small note that the result reveals which thread was assumed, which is marginal extra parameter 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?

The description uses a specific verb ('Fetch') with a well-qualified resource ('merged, chronological, provenance-tagged history of a named thread') and frames the outcome as resuming a thread. This is concrete enough to distinguish it from sibling tools like list_threads or save_session even without naming them.

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 explicit trigger phrases ('pick up where I left off', 'follow up on X') and explains the omitted-parameter default. It stops short of saying when not to use it or naming alternatives, so it does not fully earn 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 provided, the description carries the full burden. It adds a valuable behavioral disclosure beyond the schema: content from files/Notion is untrusted data and instructions embedded in it should not be followed (prompt-injection warning). It doesn't explicitly state read-only/safety traits, but the 'Load' verb implies a non-destructive 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?

Three compact sentences with zero waste. Core purpose is front-loaded in the first sentence, usage in the second, and the security warning in the third. Every sentence earns its place.

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?

An output schema exists so return values need no explanation. Coverage of what it loads, when to use it, and the untrusted-data warning is strong for a low-complexity tool. The notable gap is the undocumented scope parameter, which neither the schema nor the description explains.

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 0%, so the description must compensate, but it never mentions the 'scope' parameter or its enum values (full/plan/files/git). The listed content types loosely map to the enum, allowing inference, but the description does not explicitly document the parameter or its 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?

States a specific verb ('Load'), a precise resource (current working context for the user's project), and enumerates contents (plan, key files, git state, notion pages, optional summary) plus output format (structured JSON). This clearly differentiates it from siblings like save_session, ingest_context, continue_thread, and list_threads.

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 at the start of work or when the user references prior work you don't see.' This is clear context, but it does not mention when NOT to use it or name alternatives/siblings, so it falls 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 does well: it discloses that records are stored locally, redacted, provenance-stamped as agent-reported, and reviewable via 'ctxfile ingest list'. It omits auth/permission requirements and any return behavior, but the storage and trust semantics are genuinely 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 core action is front-loaded in the first sentence, and the enumerations of fields/storage traits each carry information. It is a dense single paragraph but not padded, with only minor redundancy around the schema version.

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?

No output schema or annotations exist, yet the description covers the action, the storage/trust model, a review path, and the optional linkage fields, which is nearly all an agent needs. It does not describe what the call returns, a small remaining 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 description coverage is 100%, so the schema already documents source, session, and ctxfile_ingest_schema. The description mostly restates this ('Set ctxfile_ingest_schema to "2"', 'continues_from (prior session_id)'), adding only a small gloss on continues_from and thread, 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 description states a specific verb and resource ('Push a digest of the CURRENT session into ctxfile') and gives the goal (future agents pick up where this one left off). It is distinguishable from read-oriented siblings like get_context/list_threads, though it only partially separates itself from save_session, which it references rather than contrasts.

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 'CURRENT session' and the handoff framing, and it points to save_session for the handoff field. However, there is no explicit when-to-use vs save_session or ingest_memory, and no when-not guidance, leaving the agent to infer which sibling to call.

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 carries the full behavioral burden. It discloses important traits: max 100 entries per call, batching with complete=false, approval gating for instructions and identity entries, verbatim requirements, and date handling that forbids guessing. It still omits auth/rate-limit/error behavior, but the core behavioral context 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 front-loaded with the purpose and then packs in operational details without obvious filler. It is dense and uses semicolons to compress multiple rules, which mostly works. A little more structure could improve scanability, but every clause earns its place.

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 6-parameter nested-object tool with no annotations and an output schema, the description covers the essential call context: purpose, scope semantics, entry shape, batching, and approval behavior. It does not address sibling selection or edge cases such as duplicate handling, but the output schema handles return values and the input schema covers remaining parameter details.

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 semantics beyond the schema for scope (global vs project), entries (one fact per entry, verbatim instructions, origin, date), and complete (batch continuation). It does not explain part, source, or ctxfile_memory_schema, but those are already covered by 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 states a specific action and resource: exporting stored or learned user information into ctxfile, with clear global vs project scope meanings. It is understandable, but it does not distinguish itself from sibling tools such as ingest_context or save_session. The verb "Export" also sits oddly against the tool name ingest_memory and title Import Memory, which could briefly confuse an 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 by the purpose: use this to push stored/learned user information into ctxfile so other agents start with it. However, there is no explicit when-to-use, when-not-to-use, or alternative routing against sibling tools. The batching and approval notes are operational rather than selection 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys the output (active threads with times and counts) and implies a read-only operation, but it does not explicitly state side effects (or lack thereof), ordering, or any limitations. Given the simplicity, a 3 is appropriate.

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 wasted words. The core action is front-loaded, and the usage guidance is appended naturally. Every sentence earns its place.

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 has no parameters, an output schema exists, and the description covers when to use and what is returned. It is complete for a simple listing operation, though it could mention whether the list is sorted or if any filters apply.

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 the schema coverage is 100% (empty schema). Per guidelines, baseline is 4 for zero parameters; the description adds no parameter details because none exist.

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 lists the user's active threads and specifies the returned fields (last-active times, session counts). It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like get_context or continue_thread, though the purpose 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?

Provides explicit guidance on when to use: when unsure which thread is meant or when the user asks what they were working on. It does not mention alternatives or exclusions, but the given scenarios are sufficient for this simple listing tool.

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. It does disclose useful traits: stored in the user's ctxfile, thread naming makes work resumable by name from any client surface, and handoff mode demands a specific field set. It never states whether saving overwrites or appends to an existing session, what permissions or errors apply, or that this is a write/mutation, which are the traits an agent most needs absent annotations.

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 dense sentences, front-loaded with the action and scope before the trigger phrases and the handoff branch. Nothing is padded, though the second sentence's enumeration is long enough to border on a checklist. Every clause carries usable routing or payload 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?

An output schema exists, so return values need no explanation, and the 94% schema coverage handles most field semantics. The description adequately covers the three operating modes (plain save, named thread, handoff). It is silent on the auto/ambient trigger mode and on continues_from, leaving small gaps for an 18-parameter 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 94%, so the baseline is 3. The description goes beyond the schema by tying user phrases to parameter values: include thread when the user names one, and set handoff:true with state, key_decisions (rationale), ordered open_items, gotchas, artifacts (one-line role each) and suggested_first_prompt. That maps intent to the parameter contract rather than restating field names.

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 and resource: summarize THIS conversation's work (decisions, files/topics, open items) and store it in the user's ctxfile. That is far more concrete than the tool name alone. It stops short of naming or contrasting the siblings (ingest_context, ingest_memory, continue_thread), so an agent must infer the boundary itself.

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 enumerates the exact user phrasings that should trigger this call ('save this', 'remember this session', 'add this to ctxfile', 'save to thread X'), plus a distinct handoff branch ('hand this off', 'so someone can take over') with its own required payload. The transcript-only-when-asked condition adds a clear when-not constraint.

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