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

Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), and the description adds the genuinely useful behavioral trait that memories are persistent and shared across agents. It says nothing about expiry semantics, result volume, or what 'recall' returns, which the annotations do not 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?

Two sentences, zero filler, front-loaded with the defining capability followed by the usage instruction. The 'what one agent learns, any agent can recall' clause earns its place by conveying the cross-agent scope that is the tool's whole point.

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

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

Given 13 parameters fully documented in the schema, no output schema, and annotations carrying safety hints, the description covers the essential read/write duality adequately. It is slightly thin on how the four actions differ in results and on the persistence/expiry model, but nothing critical to correct invocation 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%, and every parameter is already documented in the schema with per-action hints, so the baseline is 3. The description adds no parameter-level detail (e.g., interplay of query/tags/limit or action-specific parameter usage) beyond what the schema 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?

The description names a specific resource (cross-agent persistent memory) and the two core verbs (store, recall), so an agent immediately knows this tool reads and writes shared memory. It does not, however, distinguish itself from closely related siblings such as decision_memory, get_context, or what_should_i_know, 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?

It gives concrete usage context on both sides: 'store a discovery, decision, or warning' and 'recall prior context before starting work.' That is clear when-to-use guidance, but it offers no exclusions or explicit routing to the sibling memory tools, so it does not reach 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 declare readOnlyHint=true, so the safety profile is known. The description adds the behavioral guidance to call before changes, but doesn't disclose return format, rate limits, or what happens if no decisions are recorded. Adds some value beyond annotations but leaves gaps.

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 written sentences: first states what it does, second states when to use it. No wasted words, front-loaded purpose.

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

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

For a read-only check with fully documented parameters and no output schema, the description covers purpose and timing. It could mention what the check returns (e.g., aligned/misaligned) or how to interpret results, but is largely complete.

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

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

Schema coverage is 100%, with each parameter having a clear description and examples. The description itself adds no parameter details, so it meets the baseline 3 when 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 (check) and resource (alignment with recorded decisions), and distinguishes itself from siblings like dependency_check and decision_memory by naming what it validates. It doesn't explicitly differentiate from decision_memory, which likely stores decisions, but the purpose is clear.

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 tells the agent when to call: 'BEFORE suggesting a major tech change, new library, or architecture shift.' This is a clear pre-action trigger that no sibling provides.

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=false and idempotentHint=false, so the mutation/idempotency profile is covered structurally. The description adds only the notion of 'supersede' (implying the prior decision is retained rather than deleted), but says nothing about persistence scope, permissions, or what happens to state on update/supersede beyond that inference.

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, no redundancy: the first front-loads the action set and resource, the second front-loads the trigger condition. Every word 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 20-parameter, five-action tool this is thin. The description lists only four actions and omits check_alignment entirely, which is exactly where it collides with the sibling check_decision_alignment tool, and it gives no indication of what list/record returns (no output schema exists to compensate).

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

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

Schema description coverage is 100% and every one of the 20 parameters carries its own inline '(for <action>)' hint, so the schema does the heavy lifting. The description adds no per-parameter meaning beyond what the enum documentation already supplies, 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 names specific verbs (record, list, update, supersede) tied to a concrete resource (the developer's architectural and tech decisions), so the tool's function is unambiguous. It does not explicitly differentiate itself from the overlapping siblings check_decision_alignment or agent_memory, which keeps it out of 5 territory.

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?

A clear triggering condition is given: 'Call when the user makes, changes, or asks about a settled decision or convention.' That covers the main invocation contexts, but there is no when-not guidance and no routing advice against the sibling check_decision_alignment tool even though this tool also exposes a check_alignment action.

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 openWorldHint, so safety and side-effect profile are covered structurally. The description adds the shape of the response (the five verdict values), which is genuine value, but says nothing about latency, registry lookups, or how evidence is sourced for the open-world calls.

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, no filler, and the most actionable item (the verdict vocabulary and what it covers) is front-loaded before the call-timing instruction.

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

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

For a read-only batched check with no output schema, the description supplies the decision vocabulary and correct invocation timing, and the parameter schema carries the input contract. It could do slightly more on how multiple items are reported back, but nothing essential is missing.

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

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

Schema description coverage is 100% and the single nested parameter set is fully documented (exact version semantics, omit-from-when-adding, ecosystem enum values). The description adds nothing beyond the schema, 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 deliverable (a verdict enumerating proceed/wait/review/avoid/unknown) with evidence, and a specific scope: adding a dependency or bumping one to a version. A reader can tell it is a pre-flight decision tool, though it never names which sibling (vulnerability_scan, dependency_health, upgrade_planner) it supersedes.

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?

"Call BEFORE you add a package or apply any version bump" gives an explicit trigger condition and sequencing relative to the action being gated. It stops short of naming alternatives or stating when this check is unnecessary, so it is clear context but not full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network-access profile is covered. The description adds that results span four ecosystems and include CVE/deprecation counts, but says nothing about pagination, cost, or freshness of the data source.

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, both earning their place: the first states scope and data covered, the second states the invocation trigger. Front-loaded and free of filler.

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

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

With no output schema, the description carries the burden of signalling the return content, which it does by naming freshness, deprecation and CVE counts. The only gap is return shape/pagination, minor for a read-only listing 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 all four parameters (limit, sort_by, include_dev, ecosystem_filter) are documented with defaults and enum meanings in the schema itself. The description adds no parameter-level detail, 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?

The description names a concrete verb-less but specific resource: version freshness, deprecation and CVE counts across npm/Rust/Python/Go. An agent can tell it produces a dependency-health report. However, it does not distinguish itself from close siblings such as vulnerability_scan or dependency_check, leaving overlap ambiguous.

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

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

It gives a clear trigger: 'Call when the user asks whether their dependencies are outdated, stale or need updating.' This is explicit when-to-use guidance. It stops short of naming alternatives or when-not-to-use, so the agent must infer that vulnerability_scan handles deeper security 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 and openWorldHint, so the agent knows this is a safe, externally-sourced read. The description adds the meaningful constraint that results are limited to named dependencies the project uses, which is real behavioral context. It says nothing about recency window, ranking, or how the ecosystem is resolved, so a 3 is appropriate with annotations carrying the safety profile.

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, zero filler, and the scoping constraint is front-loaded before the usage trigger. Every sentence earns its place.

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

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

For a two-param, no-required-argument read tool with annotations covering safety and no output schema, the description is essentially complete. The only unaddressed item is how 'the project's ecosystem' is determined, which is minor.

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%: limit and min_points are both documented with defaults in the schema. The description adds no parameter 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?

The description gives a specific verb+resource: it surfaces recent Hacker News discussions, filtered to dependencies or frameworks the project actually uses. That scoping constraint ('actually uses') is the distinguishing feature and is stated plainly. It stops short of naming which sibling to prefer for adjacent questions (e.g. what_should_i_know), so it is clear but not fully sibling-differentiated.

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

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

It gives an explicit trigger: 'Call when the user asks what is new or being discussed in their ecosystem.' That is a clear use context. There is no when-not guidance or named alternative for overlapping questions like general project news, which keeps it below 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=true and openWorldHint=false, so safety and scope are covered. The description adds the useful detail of what the payload contains (role, stack, interests, exclusions, project context), which matters because there is no output schema, but it says nothing about freshness, caching, or empty-result behavior.

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, no waste. The content listing comes first and the invocation guidance second, which is the right front-loading for a tool meant to be called early.

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

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

For a read-only tool with two optional boolean flags, the description covers purpose, contents, and invocation timing, and the absence of an output schema is offset by the enumeration of returned context categories. Minor gaps remain around what happens when context is missing for a new user.

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 (include_ace, include_learned) are documented with defaults in the schema. The description never mentions either toggle, so it adds no meaning beyond the structured fields; baseline 3 applies.

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

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

The description names a specific resource (the user context that 4DA holds) and enumerates its contents: role, tech stack, interests, exclusions, detected project context. It is clear what the tool returns, but it does not distinguish itself from siblings such as what_should_i_know or agent_memory, which also surface user-relevant knowledge.

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

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

It gives an explicit trigger and priority: 'Call FIRST when you need to know what the user works on before answering or recommending.' That tells the agent both when to reach for it and that it should precede other calls. It stops short of naming an alternative or a when-not-to-use condition.

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 openWorldHint=true, so safety and network behavior are already covered. The description adds that it consults the registry for changelog data, but doesn't mention caching, latency, or handling of missing/unpublished versions. With annotations doing the heavy lifting, this is adequate but not rich.

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 core purpose and followed by the call trigger. No filler; every clause carries information.

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

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

Given annotations cover safety and open-world behavior, and the schema fully documents all five parameters, the description supplies the output contract and a usage trigger. It is nearly complete, though it doesn't address result size or error cases when the package/version isn't found.

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%, with clear descriptions for all five parameters including defaults and enum semantics. The description adds no parameter detail beyond naming what the tool returns, so 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+resource: what changes between installed and target version of one dependency. Enumerates the outputs (changelog entries, breaking changes, deprecations, security fixes, importer files), which distinguishes it clearly from siblings like vulnerability_scan or dependency_health.

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 'Call before upgrading or bumping a dependency,' which gives a clear when-to-use. However, it doesn't distinguish itself from upgrade_planner, the closest sibling, nor state when another tool is preferable.

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 cover the safety profile (readOnlyHint true, openWorldHint true), so the description's burden is reduced, and it still adds real behavioral context: the result is a prioritized plan whose per-line targets come either from a computed work order or from the minimal fixing version per vulnerability. With no output schema, it carries return-value information reasonably well, though it never describes the shape or ordering of the returned plan.

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 deliverable front-loaded before the computation details and the trigger sentence last. The parenthetical is dense but each clause carries information; 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 read-only tool with four optional params and no output schema, the description supplies the two computation modes and the natural-language trigger, which is most of what an agent needs to decide to call it. It leaves the structure of the returned plan and the meaning of risk levels undescribed, a modest gap given the absent output schema.

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

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

Schema description coverage is 100%, and each parameter (package, include_dev, risk_threshold, max_recommendations) already documents itself including defaults and the enum. The description adds no parameter-level detail beyond what the schema provides, 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?

The opening clause states a specific resource — a prioritized upgrade plan — and explains the two ways it is computed (a computed 'work order' versus the smallest version fixing each vulnerability). That is enough for an agent to recognize the tool. It loses a point because internal jargon ('4DA app', 'manifest vs lockfile fix', 'per-line targets') is never unpacked and no sibling tool is named to contrast against.

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

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

Ends with an explicit trigger: 'Call when the user asks what to upgrade.' That is clear, actionable usage context. It offers no when-not guidance and does not distinguish itself from adjacent siblings like upgrade_impact or vulnerability_scan, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds useful behavior beyond them by stating transitives are included, that fix versions and pin locations are returned, and that advisories come from OSV.dev. It does not mention caching/refresh behavior or output size limits, which are only in the schema.

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

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

A single dense sentence front-loads the scope (lockfiles, ecosystems) and closes with the trigger condition; every clause earns its place and nothing is repeated from structured fields.

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

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

For a read-only scan with no output schema and full schema coverage, the description covers scope, ecosystems, transitives and the returned fix/pin information. Minor gaps remain around output limits and caching, but these are addressed in the schema rather than being genuinely 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 schema already documents all six parameters including enums, defaults and the `package` scoping mode. The description's '`package` for one dep' merely echoes the schema, 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 ('Scan this project's lockfiles ... for known OSV.dev vulnerabilities'), enumerates the ecosystems covered (npm/pnpm/yarn/bun, Cargo, Python, Go) and scope (transitives included, fix versions, pin locations). It is clearly a vulnerability scanner, but it never names or contrasts the closest siblings (dependency_check, dependency_health), so an agent must infer 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?

Gives an explicit trigger: 'Call when the user asks about security, vulnerabilities or CVEs, or before recommending a dependency,' plus a scoped-query mode ('`package` for one dep'). It provides clear positive context but no when-not conditions and does not route to an alternative tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and reach profile is covered. The description adds the useful fact that the briefing is task-scoped and aggregates multiple data sources, but says nothing about auth requirements, rate limits, caching, or latency that would matter for an open-world aggregate call.

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

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

Two sentences, no filler, with the contents of the briefing front-loaded before the call-to-action. Appropriately sized for a pre-task aggregate tool, though the long enumeration in the first sentence is dense.

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

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

There is no output schema, so the description carries the burden of describing return values — and it does list the expected briefing contents (dependencies, versions, vulnerabilities, releases, decisions, verdict). It is complete enough for an agent to know what it will get back, with only the exact format left unspecified.

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 schema already explains both 'task' and 'files' with examples, so the description is not required to compensate. It adds no syntax or format detail beyond what the schema provides, 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?

The description enumerates the concrete contents of the briefing — touched dependencies, installed versions, version-confirmed vulnerabilities, releases since, recorded decisions, and a delegation verdict — which clearly differentiates it from narrower siblings like vulnerability_scan or dependency_health. It is a clear aggregate verb+resource, though the vague tool name ('what_should_i_know') carries no signal on its own and the description must do all the 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?

It states when to call: 'Call BEFORE starting a non-trivial task, especially one that changes dependencies.' That is a clear triggering context with a qualifier. It does not, however, name any alternative (e.g. when to reach for dependency_check or get_context instead), so there are no explicit exclusions or routing rules.

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