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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false. The description adds one behavioral detail beyond that: the tool may 'trigger re-planning,' which is a side effect worth knowing. It does not explain what triggers re-planning or how the alignment score is computed.

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, front-loaded with the action and scope. No filler, though it is terse to the point of omitting usage 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?

With no output schema, the description's mention of an 'alignment score' is the only clue about return values, and the re-planning trigger is left unexplained. For an audit tool with six parameters, this is minimally adequate but leaves 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 83%, so the schema already documents sessionId, proposedApproach, industryBestPractice, and the two narration params. The description adds no parameter-level meaning (e.g., expected format of industryBestPractice), 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+resource: 'Audit the current session trajectory against open-source GitHub standards and industry best practices.' An agent can tell it apart from siblings like kilo_grill_plan or kilo_validate_skills, 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?

No explicit when-to-use, prerequisites, or alternatives are given. 'Returns alignment score or triggers re-planning' hints at the outcome but does not tell the agent when this tool is preferred over kilo_grill_plan or kilo_trace_root_cause.

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 already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds meaningful behavioral traits beyond annotations: the 40-70% reduction magnitude and invariant preservation. It omits session registration side effects and the mechanics of preserveInvariants/targetReduction, 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?

A single front-loaded sentence with the verb first and zero wasted words. Efficient and immediately scannable.

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 tool with no output schema, the description carries the burden of describing the return value and the role of sessionId, format, and targetReduction levels. None of this is addressed, so an agent cannot know what the tool returns or how session registration 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 coverage is 80%, so the baseline is 3. The description alludes to invariants and reduction (loosely mapping to preserveInvariants and targetReduction) but adds no syntax or semantics for format, sessionId, or how the preservation list is applied. It does not meaningfully compensate 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 gives a specific verb ('Compacts') and resource (verbose logs, test dumps, noisy output) and even quantifies the effect (40-70%). It is clearly the only compaction tool among siblings like kilo_remember_fact and kilo_grep_code, though it does not explicitly name a sibling it differs from.

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 naming the input types (verbose logs, test dumps, noisy output), so an agent can infer when it applies. However, there is no explicit when-to-use vs alternatives guidance and no exclusions or prerequisites (e.g., session requirements).

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 already declare destructiveHint=true and idempotentHint=false, so the description's job is lighter. It adds valuable context by disclosing the AST-check behavior and a hard-gate protocol requirement that isn't captured by annotations, which helps an agent understand preconditions and verification.

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 tightly focused sentences with no filler, and the critical gate condition is front-loaded in capitals. It is appropriately sized for a simple edit tool, though the all-caps gate phrasing is slightly stylized.

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 exists, so the description need not explain return values. It covers the core operation, the AST check, and the session gate, which is sufficient for a 10-parameter but structurally simple tool. Minor gaps around replacement failure behavior remain but are not critical.

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 90%, so the schema already documents most parameters (targetContent, replacementContent, sessionId, aliases, narration fields). The description does not add parameter-level detail beyond what the schema provides, 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 precise verb and resource ('exact targeted search-and-replace edit on an existing file') plus the AST verification mechanism. This clearly distinguishes it from siblings like kilo_write_file (whole-file writes) and kilo_read_file.

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 hard-gate condition (valid sessionId in 'ready' state) implies when the tool can be used, but there is no explicit guidance on when to prefer this edit tool over kilo_write_file or other editing alternatives. 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?

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the burden is lighter. The description adds one useful behavioral trait, fuzzy alias matching, but omits the sessionId side effect of registering skill delivery and does not say what happens when a skill name does not resolve. Adequate with annotations, but thin on the delivery mechanics.

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 core action front-loaded and the alias capability immediately after; nothing is padded. The parenthetical alias list is somewhat redundant with the schema examples for the skill parameter, which keeps it from a 5.

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 tool with no output schema, the description should say more about what comes back. It never mentions the markdown/json format choice, whether output is truncated by maxChars, or the failure mode for an unknown skill, so an agent cannot predict the response shape from the description alone.

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 80%, so the schema already documents skill, category, maxChars, and sessionId. The description's alias examples duplicate the examples already present in the skill parameter's schema description, and it says nothing about the format enum or maxChars truncation behavior. Baseline 3 is correct.

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 ('Load a Kilo-Kit skill') with the retrieval keys ('by name or category/skill'), so the agent knows exactly what the tool returns a skill, not metadata about one. It stops short of explicitly distinguishing itself from the sibling kilo_search_skills, leaving the retrieval-vs-discovery boundary 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?

The description gives alias examples but no when-to-use guidance: it never says when to load a skill directly versus searching first with kilo_search_skills, nor whether a search is a prerequisite when the exact name is unknown. There are no exclusions or preconditions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds only a modest amount of context, conveying that results are line-level matches across the workspace, but says nothing about result caps, truncation, or the interaction with session state.

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?

It is a single front-loaded sentence with no redundancy or filler. It is arguably too terse for a 9-parameter tool, but nothing in it is wasted.

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 9 parameters, zero required fields, three interchangeable aliases, a format switch, an undocumented sessionId dependency, and no output schema, the description is far too thin. An agent is left unsure which alias to use, whether a query is effectively mandatory, or how sessionId affects the call.

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

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

Schema description coverage is 89%, so the schema already documents nearly every parameter, including the three aliases query/search/pattern. The description adds no extra parameter meaning (no regex syntax, no scope semantics for rootDir), 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 (search) and resource (code snippets / matching lines across workspace files), so the agent knows this is a content search rather than a filename search. However, it does not explicitly contrast itself with the sibling kilo_search_files, leaving the distinction between the two 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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as kilo_search_files or kilo_read_file. The agent must guess whether to grep content directly or first locate files by name.

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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that the analysis is automated and framed around four specific adversarial lenses, which is genuine behavioral context, but it omits whether this registers a cognitive gate, how the sessionId interacts, or what the response contains.

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

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

A single efficient sentence with the key concept front-loaded and no padding. It is compact, though the density of unexplained proper-noun lenses makes the concision partly cosmetic.

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 8-parameter tool with only one required field and no output schema, the description is thin: it does not explain the return shape, the effect of depth levels, or how sessionId/decision_narration integrate with the broader workflow. Annotations and the rich schema cover safety and inputs, so the gaps are moderate rather than severe.

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 88%, so the schema already documents plan, depth, label, context, sessionId and the narration fields. The description adds nothing about any parameter — notably the depth enum and the mandatory narration/label requirements are left entirely to the schema. Baseline 3 applies.

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

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

The verb phrase 'adversarial stress-testing' plus the named lenses (Inversion, Simplification Cascades, Blast Radius, Edge-cases) gestures at red-teaming a plan, but the description never explicitly states that the input is a plan or what the output is. No sibling is named or contrasted, and the four lenses are unexplained jargon an agent cannot act on directly.

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 statement of when to call this versus e.g. kilo_trace_root_cause, kilo_benchmark_solution, or kilo_think_step, nor any exclusion or prerequisite. The 'depth' param (quick/deep/hardcore) implies graduated use but the description never routes the agent.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description usefully says what is read (facts, decisions, suggestions) and that scope is global, but says nothing about size limits, pagination, or recency windows for 'recent suggestions'.

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 no waste. It is appropriately sized but arguably too sparse for the tool's scope.

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 idempotent read tool with one optional parameter and no output schema, the description covers the high-level content reasonably. However it omits the format parameter entirely and gives no sense of the return shape (facts vs decisions vs suggestions structure).

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% and there is one optional parameter (format, enum markdown/json, default markdown). The description never mentions the output format option, so it does not compensate for the schema gap.

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 clear verb (Read) and a specific resource (global C4 memory facts, decisions, recent suggestions). It distinguishes itself reasonably from the sibling kilo_remember_fact (which writes), though it doesn't explicitly name that 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?

No indication of when to use this versus siblings like kilo_search_skills, kilo_record_reflection, or kilo_compact_context. The agent must infer usage purely from the resource named.

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 declare readOnlyHint=true and destructiveHint=false, so safety is already covered. The description adds genuinely useful behavior (mode determination, skill selection, brainstorming gating) but never clarifies what the tool returns, that it persists session state (idempotentHint=false with a sessionId param implies this), or what happens when gating blocks execution.

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, front-loaded with the MANDATORY directive, and the capability list is packed into a single clause with no filler. Slightly dense but nothing is wasted.

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 11-parameter orchestrator with a nested context object, optional-but-load-bearing flags, no output schema, and 45% schema coverage, the description leaves too much unexplained. An agent cannot tell from this text how to populate brainstormingApproved/answers or what the orchestration step returns.

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?

Coverage is only 45% across 11 parameters with a nested context object, and the description contributes zero parameter meaning. Key inputs like brainstormingApproved, memoryConfirmations, sessionId and the mode/files/previousErrors context sub-fields get no explanation in either place, so the agent must guess at gating 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 and resource ('orchestrate task') plus the concrete outputs it produces: determines task mode, selects workflow skills, enforces brainstorming gating. The mandatory-first framing makes it trivially distinguishable from siblings like kilo_route_intent or kilo_think_step, which do narrower routing/thinking work.

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 about when to use it: 'Call this tool FIRST before diagnosing, debugging, analyzing, creating, or modifying any code, UI, backend, or project files.' That is a clear gating condition with enumerated trigger situations. It stops short of naming when NOT to call it or which sibling takes over for already-routed follow-up work.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful detail beyond annotations (line-range support, 512KB byte cap, workspace-boundary safety), but does not clarify what 'safely across workspace boundaries' enforces or how it behaves on missing/oversized files.

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 that leads with the core action and appends the key constraints. Nothing is wasted, though the parenthetical could be tightened.

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 annotations covering safety and 88% schema coverage plus no output schema, the description is mostly adequate. However, with 8 parameters including three overlapping path aliases and a sessionId, the description leaves the alias/selection ambiguity and error behavior unexplained.

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 high (88%), so the schema already documents parameters well. The description echoes line ranges (startLine/endLine) and byte capping (maxBytes) but adds no format or default details beyond the schema, and importantly does not clarify the file/path/filePath alias ambiguity.

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 (file content) with scope qualifier ('across workspace boundaries'). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like kilo_search_files or kilo_grep_code.

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 articulation of when to prefer this over kilo_search_files, kilo_grep_code, or the write/edit siblings, and no mention of prerequisites such as sessionId requirements. Usage is only vaguely implied by the word 'Read'.

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 already disclose the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description only needs to add context. It adds that records go into SQLite and persist across sessions, but does not address what happens on duplicate reflection submissions, whether entries are ever expired/overwritten, or auth requirements.

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 the verb first and no filler. It is dense with the recordable content types, though it could be split to surface usage guidance more prominently.

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 8-parameter, 5-required write tool with no output schema, the description identifies the main payload categories and the persistence target, which roughly matches the schema. It falls short on the two things the schema cannot convey: when this tool should be chosen over kilo_remember_fact and what a successful record produces.

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?

With 88% schema description coverage, the schema already documents nearly every field (taskMode, taskSummary, correctApproach, lessonsLearned, skillsEvaluated). The description merely enumerates the same content categories and adds no format, syntax, or boundary guidance, 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?

Specific verb 'Record' with a clear resource set (correct approaches, wrong paths/pitfalls, skill ratings, lessons learned) and a stated destination and motivation ('into SQLite to drive Kilo-Kit's continuous self-improvement across sessions'). An agent can tell what it does, but the description never distinguishes it from siblings like kilo_remember_fact or kilo_synthesize_skill, which also persist learning artifacts.

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 the framing: 'across sessions' and 'continuous self-improvement' suggest calling it after completing a task. There is no explicit when-to-use trigger, no when-not, and critically no routing away from kilo_remember_fact, which appears to overlap in storing durable knowledge.

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 already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds context that facts persist 'into SQLite memory_facts' and are used for 'cross-session enforcement,' which is useful. However, it doesn't disclose overwrite behavior for existing keys, upsert mechanics, or any rate/permission concerns—gaps that matter 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?

A single, front-loaded sentence with no filler. It efficiently communicates purpose, storage location, and persistence scope without 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 mutation tool with 6 parameters (3 required), nested objects, and no output schema, the description is adequate but thin. It doesn't explain the fact lifecycle (e.g., does re-persisting the same key replace or merge?), nor the relationship to sibling memory tools, leaving some ambiguity for correct invocation.

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

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

Schema coverage is 83%, so the schema already documents most parameters well, including examples for key, kind, value, and confidence. The description doesn't add parameter-level detail beyond what the schema provides. Baseline 3 is appropriate when the schema carries the load.

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+resource ('persist a project operating rule, workflow default, or verification standard') and names the storage target ('SQLite memory_facts') along with the effect ('cross-session enforcement'). This is clearly distinguishable from siblings like kilo_record_reflection or kilo_memory_report, though it doesn't explicitly name how it differs from 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?

The description implies usage through 'Explicitly persist' and 'cross-session enforcement,' suggesting this is for durable facts. However, it offers no explicit when-to-use vs when-not guidance, no mention of alternatives (e.g., why not kilo_record_reflection), and no 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the agent knows this mutates state. The description adds the meaningful target state (HALF_OPEN), which is not derivable from annotations or schema. However, it does not describe consequences of a bad reset, permission/supervision requirements, or what happens after HALF_OPEN.

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, no filler, with the action and its outcome front-loaded. 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?

No output schema exists, yet the description supplies the resulting state so the agent knows what the call produces. For a 3-param mutation tool the coverage is nearly sufficient, with only post-reset behavior and supervision requirements left unstated.

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 67% and the two required parameters are documented in the schema. The description echoes the 'justification' and 'root-cause evidence' requirement but adds no format, syntax, or length guidance beyond the schema's minLength=10 and never mentions sessionId or format. Baseline 3 for partially covered 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?

Specific verb (reset) plus resource (open Circuit Breaker) and an explicit resulting state (HALF_OPEN). It distinguishes itself from siblings like kilo_sentinel_status or kilo_trace_root_cause without needing 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?

The description implies the trigger condition ('an open Circuit Breaker') and that evidence is required, but never states when not to use it, what prerequisites must hold, or which sibling to consult first. Usage is implied rather than spelled out.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile needs no restating. The description adds the sequencing behavior (call before workflow selection), which is genuinely useful, but says nothing about the shape of the recommendation, whether it is cached/deterministic, or what the caller receives back.

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 no filler, front-loaded with the core action and followed by the calling condition. Efficient, though the second sentence could be folded in without loss.

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

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

With no output schema, the description carries some burden for explaining returns, and it only implies a ranked skill recommendation without detail. Combined with three undocumented parameters and a nested object, the definition is adequate but leaves real gaps for an agent invoking it.

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

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

Schema description coverage is only 25% and there are 4 parameters including a nested context object. The description implies the request text goes into the message parameter but never explains limit, format, or any of the context sub-fields (mode, files, previousErrors), so it fails to compensate for the coverage gap.

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 (Recommend) and resource (Kilo-Kit skills), plus enumerates the triggering inputs (bug fix, feature, UI task, coding issue). It is clear what the tool produces, though it never names or contrasts itself with the close sibling kilo_search_skills, so the distinction for an agent is inferential.

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 timing guidance: 'Call before selecting or executing a workflow skill,' which is strong sequencing context. It does not, however, mention when NOT to call it or name an alternative (e.g., kilo_search_skills for direct lookup), so the routing decision against siblings is left implicit.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the list of aggregated metrics and says nothing about whether telemetry must exist first, how stale the data is, or whether the summary is scoped to a session or the whole history.

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

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

One front-loaded sentence that names the action first and then the payload contents. No filler, no restatement of the tool name, nothing wasted.

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 parameterless read-only aggregation report with no output schema, the description's enumeration of what gets summarized is sufficient for an agent to decide whether to call it. Missing only marginal context such as the scope/period of the telemetry being summarized.

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%, but the sole parameter is a self-documenting format enum (markdown|json) with a default. The description never mentions the format option, so it adds nothing beyond the schema; a baseline 3 is appropriate given how trivial the parameter is.

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 (Summarize) and resource (route telemetry), and enumerates the report contents: top skills, task modes, workflow chains, score averages, conflict penalties. It is distinguishable from kilo_memory_report by the 'route' domain, though the description never names that sibling explicitly to reinforce 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?

No statement of when to use this report versus kilo_memory_report, kilo_sentinel_status, or the other reporting/telemetry siblings. The agent must infer that this is the post-routing analytics view from the word 'route' alone; there are no triggers, prerequisites, or 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds meaningful context beyond that: a session hard-gate, security guardrails, and a timeout. It does not explain what the guardrails block or the failure/return format, 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?

Three tightly-packed sentences with the mandatory execution action front-loaded and the gating requirement last. Efficient, though the heavy capitalization adds noise rather than substance.

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 7-parameter destructive command tool with no output schema, the description covers the key gating and safety framing. Return format and guardrail behavior are left implicit, but the annotations and schema fill most remaining 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 86%, so parameters like cwd, timeoutMs, and the narration fields are already documented in the schema. The description adds no parameter-level detail, which is the expected baseline 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?

States a specific verb and resource ('Execute a terminal command') and immediately routes the agent away from alternatives ('Use this INSTEAD OF native Bash/terminal tools'). An agent can identify this as the sanctioned command-execution path 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?

Gives a clear use directive (prefer over native Bash/terminal) and a hard precondition ('Requires valid sessionId in ready state'). Lacks explicit when-not conditions or failure guidance, but the routing context is 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds only that the search spans the workspace, which is modest additional scope context, but it does not disclose rate limits, return behavior, or other operational traits beyond what annotations already cover.

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 sentence with no redundant wording. The core action is front-loaded and easily scanned, earning its place fully.

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 7-parameter, non-destructive search tool with 86% schema coverage and no output schema, the description is minimally adequate. However, it omits usage routing against siblings, does not mention the format parameter’s output implications, and gives no guidance on sessionId or search scope beyond 'workspace'.

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 86%, so the schema itself documents nearly all parameters well. The description adds the idea of pattern/substring/glob matching, which is already captured in the schema, but does not explain aliases like glob/query or sessionId, so it neither helps nor harms much beyond 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?

States a specific verb and resource: search for files by pattern, substring, or glob. It is clear what the tool does but does not distinguish itself from sibling search tools such as kilo_grep_code, leaving the agent to infer that this searches file paths/names rather than file contents.

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 no explicit when-to-use guidance, no when-not-to-use guidance, and no alternatives. It does not mention when to prefer kilo_search_files over kilo_grep_code or kilo_search_skills, so the agent gets only an implied usage.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only a workflow positioning ('before loading a specific skill') and says nothing about result shape, ranking, or pagination behavior beyond the schema's limit.

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, zero waste, and the core action is front-loaded ahead of the usage hint.

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 could usefully hint at what a search returns (ranked matches, snippets, IDs needed for kilo_get_skill) but does not. For a low-complexity search tool it is adequate but leaves that gap.

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

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

Schema coverage is 75% and the description adds no parameter detail beyond restating the query modality. The only undocumented-in-schema param (format) has an enum and default, so the schema carries the load; 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?

States a specific verb (search) and resource (Kilo-Kit skill library) with the query modality (natural-language). The phrase 'before loading a specific skill' implicitly separates it from kilo_get_skill, though it never names the sibling.

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 says to use it for 'broad discovery before loading a specific skill,' which gives a clear when-to-use and implies the alternative (kilo_get_skill). No explicit when-not condition, 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description adds the notion of real-time telemetry and names the observable fields, which is useful context, but says nothing about freshness, staleness, permission requirements, or what happens for an inactive session.

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 with the resource front-loaded and the four observable fields listed in order. No filler, no restatement of the title.

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 enumeration of returned telemetry partially stands in for a return-value contract, which is valuable. However, it omits the format parameter's effect on output shape and the relationship to the circuit-breaker reset sibling, leaving gaps for a diagnostic tool in a 24-tool cluster.

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

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

Schema coverage is only 50%: sessionId is documented as 'Active Kilo-Kit session ID', but the format parameter (enum markdown/json, default markdown) has no description anywhere. The description never mentions either parameter or the output format choice, so it fails to compensate for the coverage gap.

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 ('Inspect') and resource ('Sentinel supervisor telemetry') and enumerates the concrete payload: circuit breaker state, step budget, failure streaks, grounded files list. That is far more specific than the title. It does not, however, differentiate itself from the closely related sibling kilo_reset_circuit_breaker, which touches the same circuit-breaker concept.

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 says what can be inspected but never says when to call this tool, what triggers it, or which sibling to use instead (e.g., kilo_reset_circuit_breaker when the breaker is tripped). 'Real-time' hints at diagnostic use but nothing is explicit.

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 already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds that the output is 'reusable, validated,' but never explains what gets created/overwritten, whether it persists to disk, or what 'validated' implies. It neither contradicts the annotations nor richly extends them.

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 no waste. The purpose and intended input are conveyed immediately without 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 destructive, non-idempotent tool with no output schema, the description doesn't cover critical context such as what the synthesized SKILL.md contains, where it is stored, or whether synthesis requires a prior solve. The schema is well-documented, but behavioral completeness falls short.

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 86%, so the schema already documents the 7 parameters well, including enums and formats. The description contributes no additional parameter-level detail (e.g., how format affects output, keyword conventions), 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 (distill/synthesize) and resource (SKILL.md, self-evolving skill), and names the trigger condition (a newly solved architectural pattern or bugfix methodology). It is clearly distinguishable from siblings like kilo_get_skill and kilo_search_skills, which read rather than create skills.

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 phrase 'newly solved' implies the timing (after solving a problem), which gives some usage context, but no explicit when-not-to-use or alternative tool is named. It does not tell the agent to prefer this over kilo_record_reflection or kilo_remember_fact for capturing learnings.

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 already establish readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds that thoughts can be revised and branched, which is a real behavioral trait, but it does not disclose the stateful workflow (that thoughtNumber/totalThoughts drive continuity) or what the tool returns. Moderate added value over 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?

A single front-loaded sentence with no filler; the core capability set leads. It is efficient, though for a 14-parameter, branch/revision-capable tool one more sentence of workflow framing would have earned 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 complex iterative tool with 14 parameters, branching and revision semantics, and no output schema, one sentence is thin. It does not explain how to drive the loop (advancing thoughtNumber, ending with nextThoughtNeeded=false) or how branches interleave with sequential steps, so an agent must reconstruct the protocol from the schema alone.

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 93%, so the schema already documents all 14 parameters, including the mandatory label and narration fields. The description's mention of hypothesis/revision/branching is effectively a restatement of schema fields (hypothesis, isRevision, branchId) rather than adding syntax or sequencing meaning. Baseline 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 names the resource (a reasoning engine) and its distinguishing capabilities: iteration, hypothesis tracking, revision, and branching. It is clear what the tool is for, but it offers no differentiation from nearby reasoning-oriented siblings such as kilo_grill_plan or kilo_trace_root_cause.

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: nothing says to call this before planning, to drive multi-step analysis, or when to prefer it over kilo_grill_plan or kilo_trace_root_cause. The agent is left to infer the trigger condition from the tool name alone.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds only that the analysis is recursive and causal; it says nothing about depth limits, output shape, latency, or what the trace produces, so added value beyond annotations is modest.

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 no filler, and the essential concept (crash log -> systemic root cause) is stated first. Slightly dense terminology costs it the top mark.

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 9 parameters, no output schema, and no explanation of the 5-Whys output or the mandatory narration gates, the description leaves an agent with only a one-line concept. It is not misleading, but for a tool with this parameter surface it under-delivers.

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 89%, so the schema already documents nearly every parameter (label, errorLog, sessionId, narrations, etc.). The description contributes no parameter-level guidance at all; it neither clarifies the optional fields nor the enum format. Baseline 3 applies when the schema carries the burden.

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 analysis verb ('backward-propagation analysis') and target ('crash log to underlying systemic root cause'), which cleanly separates it from sibling reasoning tools like kilo_grill_plan and kilo_triangulate_research. It is jargon-heavy ('recursive causal backward-propagation') but the resource and outcome are 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 crash-log-to-root-cause framing implies when it applies (debugging a specific failure), but there is no explicit when-to-use, when-not-to-use, or routing statement relative to the many siblings that also reason about problems. Usage is left to inference.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds useful context beyond that: reasoning is persisted atomically into SQLite and this occurs before code modification, which signals a stateful write with sequencing constraints. It stops short of saying what gets written, whether repeat calls duplicate state, or what the escalation does in practice.

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, front-loaded with the action verb, so it is compact. However, the second sentence is packed with opaque capitalized jargon ('Grounded Cognitive Triangulation', 'Triangulated Cognitive Synthesis') that consumes space without adding precision.

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

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

For a 13-parameter, non-idempotent write tool with no output schema, the description covers the high-level purpose and the persistence behavior but omits usage routing and expected outcomes. The rich schema compensates for parameter detail, but the agent still lacks guidance on when this tool should be invoked versus its siblings.

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 92%, so the schema already documents nearly every parameter including the confidenceScore escalation threshold and the narration params. The description adds no parameter-level detail beyond what the schema provides, so 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?

States a concrete verb ('Execute Triangulated Cognitive Synthesis') and enumerates the distinct operations it combines (SQLite memory, GitHub grounding, ToT DAG trade-offs, research escalation) plus its persistence step. An agent can grasp what the tool does, though the jargon-heavy phrasing and lack of differentiation from siblings like kilo_think_step or kilo_grill_plan keeps it from 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?

The description never states when to choose this tool over alternatives such as kilo_think_step, kilo_grill_plan, or kilo_benchmark_solution. The routing logic (confidenceScore < 0.70 triggers escalation) lives only in the schema, not in the description, and no prerequisites or exclusion conditions are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'read-only and does not modify files' largely restates structured data. The only added value is the vague hint that it returns a 'quality-gate summary', with no detail on what that 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 short sentences, front-loaded with the action and followed by the safety note. No wasted text, though the tiny size also reflects thin content rather than tight editing.

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 read-only tool with no output schema, the description establishes purpose and safety but omits what 'skills' are being validated (all of them? a target?), what the quality-gate summary includes, and the meaning of the format parameter. Adequate but with 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?

The sole parameter 'format' (enum markdown/json) has 0% schema description coverage, so the description carries the full burden of explaining it — yet it never mentions output format at all. An agent cannot learn from the description what the format option controls.

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 ('Run the Kilo-Kit skill validator') plus the nature of the output ('concise quality-gate summary'). This clearly distinguishes it from siblings like kilo_synthesize_skill or kilo_search_skills, though it does not name those siblings explicitly.

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

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

The description says what the tool is but never states when to invoke it or how it relates to alternatives such as kilo_synthesize_skill or kilo_get_skill. Usage must be inferred entirely by the agent.

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 already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false. Beyond that, the description adds a real behavioral constraint not in structured form: the session must be valid and in 'ready' state before the call will succeed. It omits overwrite semantics for existing files, keeping it out of 5 territory.

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, front-loaded with the action and followed by the gating condition; every word earns its place. It is not quite maximally structured since the gate could be phrased with the exact consequence if unmet.

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 9-parameter destructive write tool with no output schema, the safety-relevant gate is disclosed and annotations cover the rest of the risk profile. The aliased path parameters and the two mandatory narration fields are left entirely to the schema, which is acceptable at this coverage but leaves a small 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 high (89%), so the schema already carries the parameter burden and the baseline of 3 applies. The description reinforces the sessionId gate but adds no detail on the filePath/file/path aliases or the mandatory narration parameters.

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

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

States a specific verb+resource pair ('Create a new file or overwrite an existing file'), so the agent knows exactly what it does. It does not distinguish itself from the sibling kilo_edit_file, which is the main ambiguity for file-writing tools, 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?

The 'PROTOCOL HARD-GATE' line implies a usage prerequisite (sessionId in 'ready' state), which is useful context. However, it never says when to pick this over kilo_edit_file or kilo_read_file, and gives no when-not guidance, so 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.