never4ga-mcp

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait: capture defers classification and lands the item in an Inbox rather than a categorized location. However it says nothing about authentication, persistence/durability, duplicate handling, or what the agent gets back, which matters for a write 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?

Two tight sentences with zero filler, and the core action is front-loaded before the usage condition.

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 simple two-parameter capture tool with full schema coverage and no output schema, the description covers purpose and timing adequately. Minor gaps remain around persistence and what happens to the captured item afterward.

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 both parameters are documented in the schema, so baseline is 3. The description adds only marginal meaning beyond the schema by noting that content may be a 'thought, link or fragment' rather than just the generic 'text' field.

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 concrete action ('Put a thought, link or fragment in the Inbox') and the object it produces ('Inbox'), which distinguishes it from siblings like never4ga_work_create or never4ga_decide. It is clear about the resource, though it never explicitly contrasts itself with those 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?

Gives an explicit trigger condition with a rationale: 'Use when something is worth keeping and classifying it now would interrupt the work.' This is genuine when-to-use guidance. It stops short of naming alternatives (e.g. use never4ga_decide when classification is warranted) or stating exclusions.

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 disclose one genuinely non-obvious trait: it is runtime-only, never touches the vault, and cannot leave a partial log on interruption. That is valuable, but it says nothing about required session state, what the checkpoint reports back, or how recorded items flow into wrap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste. The core action is front-loaded and the atomicity guarantee follows immediately as supporting context.

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 an eight-parameter tool with no output schema, the description covers the key safety property but omits what happens after recording and how these entries surface at wrap. The rich per-parameter schema descriptions compensate substantially, keeping this at a minimum-viable level rather than inadequate.

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 each of the eight parameters carries a detailed description in the schema itself, so the baseline of 3 applies. The prose adds no parameter-level syntax or meaning beyond what the schema already provides.

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: recording what the session has done so far. It is clear this is an incremental checkpoint rather than a finalization, but it never names or contrasts against siblings like never4ga_wrap or never4ga_capture, so differentiation is left to inference from the name.

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?

'What this session has done so far' implies a mid-session, incremental recording moment, but there is no explicit when-to-use or when-not guidance and no routing to never4ga_wrap for the final summary. Usage is implied rather than stated.

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 burden. It does not state whether the operation is read-only, what form the returned 'context' takes, whether depth affects latency or cost, or any caching or rate-limit behavior. The depth semantics in the schema hint at behavioral gradation, but the description adds nothing beyond the phrase 'at a stated depth'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and immediately followed by the usage condition. 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?

The input schema is complete and self-describing, but with no output schema and no annotations, the description leaves the return format, safety profile, and behavioral differences between depth levels unspecified. It is minimally adequate for a context-retrieval tool but has clear gaps.

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

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

Schema description coverage is 100%, so every parameter including the depth enum and default value is already documented. The description only vaguely restates 'terms' and 'depth' and adds no syntax, format, or interaction guidance beyond what the schema provides, 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?

States a specific action (fetch more context) on a specific object (particular terms) and notes a scoping parameter (stated depth). It implicitly differentiates from the startup pack by positioning itself as the follow-up step, though it does not name the sibling never4ga_context_startup explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear triggering condition: use it when the startup pack was insufficient or work shifted to an unfamiliar area. It does not name an explicit alternative tool, but the condition itself routes the agent correctly relative to context_startup.

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. It does disclose the key side effect and return value ("Opens a session and returns its id"), but says nothing about persistence, auth requirements, or whether repeated calls create multiple sessions.

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 tight sentences with the action front-loaded and zero padding. The clause "what it is, what binds it, what the last session did" is slightly abstract but does convey payload content efficiently.

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 should say more about the shape of the returned context and the effect of creating a session. It covers the essentials for calling the tool but leaves the return contract vague.

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 cwd, task, and client are already well documented, including the useful 'never pass a whole prompt' warning. The description adds no parameter-level meaning beyond that 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 names a concrete verb and resource: it opens a session and returns its id, and it characterizes the payload as minimal startup context. It does not, however, distinguish itself from the closely-named sibling never4ga_context_focus, so an agent must infer the split.

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?

"For starting a session in a workspace" implies the trigger condition, but no alternative is named and no exclusion is stated (e.g., when to use context_focus or workspace_resolve instead). Usage is only implied.

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 burden, and it does disclose the key trait: the record is created as PROPOSED and is not in effect, with acceptance reserved for the maintainer. It stops short of stating permissions, error behavior, or side effects such as number allocation from the folder.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler; the state-of-the-draft constraint is front-loaded immediately after the purpose so an agent knows the outcome before reading anything else.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter draft tool with a fully documented schema and no output schema, the description supplies the one thing structured fields cannot: the lifecycle guarantee. Only minor gaps remain (return value shape, what happens if title collides).

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 every parameter (including the numbering, series, and workspace semantics) is already documented in the schema. The description adds no parameter-level detail beyond that, 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?

States a specific verb and resource ('Draft a decision record') and immediately adds the lifecycle state the draft lands in. It is clearly distinguishable from write-ish siblings like never4ga_capture or never4ga_checkpoint, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a firm usage rule: an agent never authors an accepted decision, and only the maintainer promotes one. That is real when/when-not guidance for the drafting workflow, but it does not point to a specific alternative tool for capturing non-decision content.

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 disclose one important trait: the tool is diagnostic and non-mutating ('never repairs anything itself'). However, it says nothing about permissions, cost/duration of a full vault scan, or whether findings are blocking, which a doctor-style tool would benefit from stating.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero filler, and the core purpose plus the critical non-repair constraint are front-loaded. Nothing is redundant.

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-optional-parameter diagnostic with no output schema, the description covers what it does and what it returns in outline ('findings with repair hints'). It is close to complete; only the level semantics and return granularity are left entirely to the 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% and the single 'level' parameter is fully documented in the schema, including its default of 'strict'. The description adds no meaning beyond that, so the 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?

States a specific verb and resource ('Check vault health') and adds a scope-defining clause ('Reports findings with repair hints'). It is unmistakably distinct from all listed siblings, which are capture/search/work/context/checkpoint tools rather than diagnostics.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative. The clause 'never repairs anything itself' hints that repair happens elsewhere, but no sibling is pointed to, so the agent must infer the workflow.

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 burden. It usefully discloses the shape of the result (frontmatter, body, relations), which tells the agent this is a read operation with no mutation, but it says nothing about auth needs, not-found/error behavior, or whether relations are resolved inline or lazily.

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?

A single compact sentence with the key payload description front-loaded after the colon. Slightly awkward opening ('One concept by its Never4gA id') but no wasted clauses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the work of describing the return payload, which is the right instinct. However, for a lookup tool it omits failure modes (unknown id, missing body) and whether relation traversal is bounded, leaving an agent with gaps when the call returns unexpectedly.

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?

One parameter at 100% schema coverage, where the schema already documents it as 'The concept's UUIDv7.' The description repeats the id-based lookup without adding format, aliasing, or fallback behavior, so it matches the baseline for schema-documented params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb-resource pair (get a concept) and enumerates what is returned: frontmatter, body, and relations. That distinguishes it from search or list siblings, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisite (e.g., where the id comes from), and no mention of alternatives such as never4ga_search for when the id is unknown. The 'by its id' phrasing merely restates the required parameter.

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 so well for a read tool: it discloses that lexical search always runs while semantic runs only when an embedder is configured, that lanes are fused by rank, that each result carries a retrieval reason, and that the response signals a stale index. It omits failure modes and any auth/scope constraints, but the disclosed mechanics are substantive.

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?

A single dense sentence that front-loads the action ("Search the vault") and then layers the mechanics and return behavior. Nothing is padding, though the semicolon-packed clause about lanes requires a second read.

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 search tool with no output schema and no annotations, the description covers what is returned (ranked results plus reasons, staleness notice) reasonably well. It still leaves out pagination/default for limit and the scope of the vault relative to sibling corpora, which the schema cannot supply.

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, query, and explain. The description only alludes to "the reason each was retrieved," which overlaps the explain parameter's own schema text. It adds no meaning beyond what the structured fields provide, 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?

States a specific verb and resource ("Search the vault") and describes the retrieval mechanism, which is clear on its own. However, it does not differentiate from the sibling never4ga_work_search, leaving the agent to infer whether "the vault" includes works or is a separate corpus.

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?

No when-to-use, when-not-to-use, or alternative routing is given. With never4ga_work_search and never4ga_get_concept among its siblings, the description never tells the agent when this general search is preferable to those. Usage is only implied by the verb.

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 disclose the critical dry-run behavior: nothing is sent unless `apply` is true. It omits authorization requirements, whether an amendment is reversible, and what the describe-only response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler, and the dry-run constraint is stated up front where it most affects agent behavior.

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 six-parameter mutation tool with no annotations and no output schema, the definition covers the core call semantics but not the write's side effects, permissions, or preview result. Adequate but with visible gaps.

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

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

Schema description coverage is 100%, so all six parameters are already documented, including `apply`, `amends`, and `session_id`. The description adds no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific verb (comment) and resource (work item), plus the alternate mode of replacing an existing comment. It is clearly distinguishable from work_create/work_update by resource, though it never names a sibling to sharpen the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage context through the apply/describe distinction, telling the agent the default is a no-op preview. It does not say when to reach for this over work_update or when replacement is appropriate versus posting a new comment.

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 it does disclose the important dry-run default: nothing is sent unless `apply` is true. However, it says nothing about permissions, idempotency, duplicate-title behavior, side effects on the tracker, or what the call returns after a successful 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?

Two short sentences with no filler, and the core action is front-loaded before the dry-run caveat. 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 mutation tool with no annotations and no output schema, the description covers the essential dry-run behavior but omits post-write behavior and what `fields` can carry beyond the schema's terse note. It is adequate but not 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 all five parameters are already documented in the schema, including `apply`, `cwd`, `fields`, and `session_id`. The description restates the `apply` semantics but adds no new meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Create a work item on the workspace's tracker.' An agent can distinguish it from read/update siblings like never4ga_work_update or never4ga_work_get. It stops short of explicitly naming those siblings, so it lands at 4 rather than 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?

There is no guidance on when to create versus update, comment on, or search for work items, and no stated prerequisites or exclusions. The only routing information is implicit in the word 'Create'. This is essentially no usage 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?

No annotations are provided, so the description must carry the behavioral burden. It conveys read-only semantics via 'Read', which is the key safety signal, but says nothing about behavior on a missing/invalid id, permissions, or whether the cwd context affects resolution.

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?

A single front-loaded sentence with zero filler. It is efficient, though the extreme brevity leaves room for the missing usage and failure-mode context noted elsewhere.

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 simple two-parameter, single-required read tool, the description is minimally sufficient. With no output schema, however, the agent gets no hint about what a work item contains or how a not-found id behaves.

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 both parameters (cwd, work_item) are already documented in the schema. The description adds no syntax, format, or id-derivation detail beyond that 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?

States a specific verb (read) and resource (one work item) scoped to the workspace's tracker. The singular 'one work item' implicitly distinguishes it from the list-style sibling never4ga_work_search, though the distinction is not made explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is for fetching a single known item rather than searching. No when-to-use, when-not-to-use, or named alternative (e.g. never4ga_work_search) is given.

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 must carry the behavioral burden, and it does disclose that the tracker remains the system of record and that this reads it rather than mirroring it – i.e. a non-mutating read that returns fresh source data. It says nothing about pagination, result limits, or what a result set looks like, so the disclosure is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action, with no filler. The second sentence is more architectural framing than operational detail, but it is brief and does not bloat the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter search tool with no annotations and no output schema, the description omits return-shape expectations, default limits, and how the optional filters behave. The agent is left to guess what a successful call yields.

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 cwd, limit, terms, and statuses are already documented structurally; the baseline is 3. The description adds no filtering semantics beyond the schema (e.g. how terms and statuses combine), so it does not exceed 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 says it asks the tracker 'what is open', which implies listing/finding open work items, but never uses a concrete verb like 'search' or names the resource as work items. It does not distinguish itself from siblings never4ga_work_get or never4ga_search, leaving the agent to infer the scope.

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?

There is no explicit statement of when to use this versus never4ga_work_get (single item) or never4ga_search (general search). The only guidance is the implicit notion that it returns open items, with no exclusion criteria or prerequisites.

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 usefully discloses that the tool is mechanical and will refuse to guess rather than arbitrarily pick a workspace, which is an important non-obvious trait. However, it does not state whether the operation is read-only, what happens when no workspace matches, or what the 'why' output actually contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the main purpose followed by a behavioral note. Every sentence adds value, though 'Mechanical:' is slightly jargon-like; the structure is efficient and easy to parse.

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 simple one-parameter, no-output-schema tool, the description covers the core purpose and a key behavioral trait. It is incomplete on important details: it does not explain what happens if 'cwd' is omitted, what the return value or 'why' looks like, or how ambiguity is surfaced. These gaps matter for correct invocation but are less severe than for a complex mutation 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 description coverage is 100%, and the single parameter 'cwd' already has a clear description in the schema. The tool description adds no additional meaning about the parameter's format, default behavior when omitted, or how it is used in resolution. A baseline of 3 is appropriate when the schema does the heavy lifting.

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 core function: determining which Never4gA workspace a directory belongs to, plus the reason. It identifies the resource and the relation, though it lacks an explicit verb like 'resolve'. It is distinct from all listed siblings, none of which handle workspace resolution.

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 offers no explicit guidance on when to use this tool versus alternatives, nor any when-not conditions. The phrase 'refuses to guess rather than picking one' hints at a preference for authoritative resolution, but it does not tell the agent when to call this instead of other workspace-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?

With no annotations, the description carries the full burden, and it does disclose two non-obvious traits: writes are suppressed unless `apply` is true, and a no-op field change is rejected in either mode. It still omits permission/auth requirements, reversibility, and what happens on a partially failing update, which matters 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?

Two tight sentences with the mutation scope front-loaded and the dry-run/validation caveat immediately after; nothing is padded or redundant.

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 mutation tool with no annotations and no output schema, the description covers the dry-run contract and the no-op guard, which are the most important behaviors. It is still thin on session/permission context and on error or partial-update outcomes, leaving gaps an agent might need before calling.

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 all five parameters are already documented in the schema and the baseline is 3. The description reinforces the semantics of `apply` and the `fields` payload but adds no syntax, format, or constraint detail beyond 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 verb and resource ('Change fields on a work item'), which an agent can clearly separate from read siblings like never4ga_work_get/never4ga_work_search and from never4ga_work_create/never4ga_work_comment. It does not, however, explicitly contrast itself with any sibling by name, so it stops 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?

Usage is implied by the verb 'change' and by the dry-run default ('sends nothing unless `apply` is true'), so an agent can infer this is the mutation path when edit intent exists. There is no explicit statement of when to prefer this over never4ga_work_create or never4ga_work_comment, nor any prerequisites.

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 writes nothing but the log" scopes the write precisely, and the idempotency rule (wrapping twice updates one document; a re-passed title replaces and renames the file) is detailed behavior no structured field provides. It omits permissions/auth requirements, keeping it short of a 5.

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 key action is front-loaded, but the second sentence is an overlong, convoluted run-on ("with the question whether it changed anything they assert") that costs more reading effort than the information it delivers. The final idempotency sentence pulls its weight.

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 no-output-schema mutation tool, the description explains the single side effect and summarizes what is reported back (decisions, memories, work items, context documents). Return semantics are adequately conveyed; only auth/permission context 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 is 3. The description largely restates what the schema already documents for title and into (retitling/renaming, archived-workspace case) rather than adding syntax or format details beyond it.

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+resource: "Close a session" and "write the one activity log it leaves behind." That distinguishes it from siblings like checkpoint or context_startup, though the trailing clause about reporting declarations is wordy enough to dilute the core action. No sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by "Close a session" – an agent can infer end-of-session timing, but there is no explicit when-to-use vs. alternative guidance (e.g. checkpoint vs. wrap) and no stated prerequisites. The idempotency note helps but is behavioral, not routing.

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