Chip MCP

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

Annotations already establish readOnlyHint=true, and the description adds behavioral context the annotations cannot: the one-shot calling pattern and the relative cost vs whats_new. It also explains what depth actually changes (summaries vs verbatim). It stops short of any mention of size, latency, or output shape, so not a full 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 compact clauses: what it returns, when to call it (with the cheaper alternative front-loaded as a condition), and the depth option. No filler, and the critical call-once instruction appears before the depth detail.

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

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

An output schema exists, so return-value explanation is unnecessary, and the annotations cover the safety profile. The description supplies the cost and idempotency guidance an agent needs to invoke it correctly; only the required project_id parameter's semantics are left uncovered.

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 parameters with enums is 0, so the description carries real weight here: it documents the two depth values (brief/full), the default of brief, and what each produces — adding meaning the schema's bare string type does not convey. However, project_id, a required parameter, is left entirely unexplained in both schema and description.

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 and enumerates exactly what it returns: instructions, tasks, map table of contents, memory, files, dialogs. It is clearly distinguishable from siblings, particularly whats_new, which it explicitly routes away to for repeat visits.

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 precise when: call ONCE when you first take on a project, and an explicit when-not plus alternative: for a familiar project use whats_new because it is cheaper. Both the selection condition and the fallback tool are stated, not implied.

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

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

readOnlyHint=true already tells the agent this is a safe read, and an output schema exists, so the description's contribution is limited to naming the returned fields (name, size, readability). It adds no information about ordering, pagination, or behavior for an empty/unknown project, which is a modest but real gap given the annotations already cover safety.

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: the first front-loads what is returned, the second carries the usage rule. Nothing is redundant and nothing could be cut without losing meaning.

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 readOnlyHint covering safety and an output schema covering return values, the description only needs to establish purpose and call sequence, which it does. The one remaining hole is the undocumented project_id, which is why this is not a 5.

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 the single parameter project_id gets no explanation in the description — no format, no note on where the id comes from (e.g. list_projects), no failure behavior for an invalid id. The description neither compensates for the coverage gap nor adds anything beyond the bare property name.

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 concretely what the tool returns — the project knowledge-base files with name, size and readability — and explicitly distinguishes itself from the read_project_file sibling by saying it is the discovery step used when the exact filename is unknown.

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?

"Зови перед read_project_file, если точное имя неизвестно" gives both the trigger condition (unknown filename) and the alternative to reach for once the name is known (read_project_file), so the routing decision is unambiguous.

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?

Beyond readOnlyHint=true, the description discloses what the payload contains and that the list is nearly static, which is genuinely actionable cache guidance that annotations cannot express. It does not discuss pagination or ordering, but for a small static list that is minor.

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: the first front-loads the returned fields, the second the routing condition and the caching caveat. Nothing is wasted or buried.

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

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

A zero-parameter read tool with an output schema and readOnlyHint — the description covers purpose, trigger, and caching, which is sufficient to call it correctly. Only the explicit contrast with get_project_context/search_project 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?

Zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The mention of project_id refers to an output field consumed by other tools, not an input, so it does not mislead.

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

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

Names the resource (the user's projects) and enumerates the returned fields (id, name, last activity, open tasks), so an agent knows exactly what it gets back. It does not explicitly differentiate itself from get_project_context or search_project, which are the closest siblings.

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

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

"Нужен project_id — сюда" gives a concrete trigger condition (you need a project_id), and "список меняется редко, не перечитывай" adds a caching rule that prevents redundant calls. No explicit when-not or named alternative is given, but the usage 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 readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that: tasks come from the user and previous session, and unfinished items 'всплывёт снова' (will resurface again), implying persistent open-task behavior. It does not cover pagination, authentication, or return format, but the output schema handles returns.

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

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

The description is three short sentences, front-loaded with the core purpose and usage timing. The phrase 'хвосты «Осталось»' is cryptic and less clear than the rest, but there is no redundant 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 an output schema present, the description need not explain return values, and readOnlyHint covers safety. The main missing piece is parameter semantics: project_id is required but undocumented in both schema and description. The workflow guidance around complete_task partially compensates.

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

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

The schema has one required parameter, project_id, with 0% description coverage, and the description never explains it. The phrase 'в этом проекте' implies project scoping but does not specify that project_id is the required integer identifier. The description fails to 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?

The description clearly states that the tool returns 'Поручения тебе в этом проекте' (tasks assigned to you in this project), with sources including the user and the previous session. This is a specific verb+resource, though it does not explicitly differentiate from every sibling read tool such as read_journal or get_project_context.

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

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

It gives explicit timing: 'Зови в начале работы и когда ищешь, чем заняться дальше' (call at the start of work and when looking for what to do next). It also names complete_task as the way to close finished items, providing a clear workflow. No explicit exclusions or alternative sibling routing 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, so the safety profile is covered; the description adds real context on top: newest-first ordering, verbatim content, and that paging continues via a hint at the end of the response. It does not mention volume or size limits per page, which is the only notable gap.

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

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

Three compact clauses, each doing distinct work: what the journal is, when to call it versus the alternative, and how to page. 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?

An output schema exists, so return values need not be described, and the description still adds the paging-in-response detail an agent needs to iterate. Combined with readOnlyHint annotations, nothing essential for 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 0%, so the description must carry the load, and it explains offset meaningfully (0 = freshest, then page following the hint in the response) rather than restating the type. project_id is left unexplained but is self-evident from the tool's resource.

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 the specific resource (the project journal), what it contains (session summaries and milestone notes), and its ordering (newest first, verbatim). The phrase 'Зови за «что было N сессий назад»' plus the explicit hand-off to search_project makes it unmistakable against its siblings.

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

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

Gives an explicit use case ('what happened N sessions ago') and names the alternative tool for the competing need (topic search -> search_project). The condition that selects each tool is stated rather than inferred.

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?

readOnlyHint=true already establishes the safe-read profile, and the description adds that the result is curated current knowledge rather than raw files. It does not say what happens when the section name is not in the table of contents, nor anything about size or structure of the returned article.

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: the first defines the return value, the second tells the agent where to get the argument. The prerequisite is stated in the position where it matters most.

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

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

An output schema exists, so return structure need not be described, and the annotations cover safety. What remains is small but real: the meaning of the map concept and of project_id are left implicit.

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

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

Schema description coverage is 0%, so both parameters rely on the description. The section parameter is well served: its valid values come from the get_project_context/get_project_map table of contents, with examples given. project_id is not addressed at all, leaving half the parameters unexplained.

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 the returned resource concretely: an article for one shelf of the map with topical knowledge, illustrated by example categories ("Решения", "Грабли"). That distinguishes it from sibling readers like read_project_file and read_journal, though the notion of a "map shelf" is never defined for an agent unfamiliar with the 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?

Explicitly tells the agent to call it with a section taken from the table of contents returned by get_project_context or get_project_map, which is a clear entry condition and points at prerequisite tools. It gives no exclusion criteria (e.g. when to prefer read_project_file over a map shelf) and cites get_project_map, which is not in the sibling list.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description's added value is the no-session_id default, which is genuine behavioral context. It does not say how many 'latest messages' are returned or whether the result is truncated relative to the full dialog, which is the key behavioral trait for this 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?

Three short sentences, front-loaded with what the tool returns, followed by usage and parameter default. The phrasing is slightly colloquial ('забери целиком, а не пересказ') but each sentence 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?

Return values need not be described since an output schema exists, and the description covers the one non-obvious parameter default plus the id-discovery route. Only the extent of truncation in 'latest messages' is left for the agent to discover.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does explain session_id's fallback semantics ('most recent' when absent) and where to obtain valid ids. project_id is left unstated, but its meaning is self-evident from the tool name.

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

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

Names a specific resource (the user's dialog with Chip inside a project) and states what it returns: a summary plus the latest messages. It is distinguishable from siblings because it points to get_project_context for dialog ids and does not overlap with read_journal or read_project_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?

Gives a concrete scenario (a plan dictated from a phone, retrieve it whole rather than a retelling) and states the default when session_id is omitted (the most recent dialog). No explicit 'when not to use' is given, but the pointer to get_project_context for dialog ids effectively 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=true, so safety is covered. The description adds genuinely non-obvious behavior beyond that: a no-page call returns a TOC rather than content for long documents, and responses carry a trailing pagination hint. It does not mention error behavior for missing 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?

Two tight sentences with the core capability first and the pagination protocol second; every clause carries actionable information and nothing is repeated from the schema.

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

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

An output schema exists and handles return-value explanation, and the description covers the tricky part — the TOC-then-paginate protocol. What is missing is identification of the file/project inputs and failure modes.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains `page` well (default behavior = TOC, page=N = section, iterative pagination) but says nothing about `filename` or `project_id`, leaving two required parameters to inference from their names alone.

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

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

Names a specific verb and resource — reading file text from the project knowledge base, delivered in pages. It implicitly separates itself from siblings like read_map_section and read_journal by scoping to files, but never names an alternative explicitly.

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

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

Gives concrete operational guidance: call without `page` on a long document to get a table of contents, pick a section, then call with page=N and keep paginating per the hint at the end of the response. Clear context for the workflow, though no when-not-to-use case or named 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?

readOnlyHint=true already covers the safety profile, so the description's job is to add scope behavior — and it does: omitting project_id widens the search to all projects. It stops short of describing ranking, result size, or truncation behavior, which would matter for a search 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?

Every sentence carries distinct information — scope, selection trigger, project_id default, query format, kind values, since semantics — with the broadest facts front-loaded. No filler or restatement of the tool name.

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 an output schema present and readOnlyHint annotations, the description covers what remains: cross-source scope, the all-projects default, query format, and both filter parameters. Nothing an agent needs to invoke this search correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry all four parameters and it does: query format constraints (1–3 keywords, not a sentence), the kind enum values, since as an ISO cursor that trims old records, and the project_id omission default. This is a strong compensation for an undocumented 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?

Opens with a specific verb+resource ("Поиск по знанию проекта") and enumerates the four sources it spans (map shelves, journal, memory, dialogues). That scope makes it distinguishable from the read_* siblings, which each target a single source, without the agent needing to open either 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 selection context: call it for a specific fact or old decision that is not already in context. It does not explicitly name the sibling alternatives (read_journal, read_map_section, read_project_dialog) to steer away from, so it falls short of the top band.

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, so safety is covered; the description adds behavioral context beyond that. It explains delta-vs-full-context behavior, the meaning of the 'since' cursor, and that 'session' controls visibility into neighboring sessions for the same token. It does not describe pagination or exact output shape, but the output schema exists.

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

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

The description is compact and front-loads the core purpose and 'call first' guidance. Every sentence contributes usage or parameter context. Some phrasing, such as 'Курсора' and 'токена', is slightly cryptic, keeping it from a full 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?

Given an output schema and readOnlyHint annotation, the description covers purpose, initial-call routing, fallback behavior, and two parameter semantics. The missing explanation of project_id is a minor gap for a tool whose primary job is clearly described. Overall it is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It usefully explains 'since' as coming from the previous response's cursor and 'session' as a branch label that exposes neighboring sessions. It does not explain the required project_id parameter at all, leaving a clear 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?

The description states a specific purpose: returning project changes since the last visit across journal, assignments, files, map shelves, and dialogs. It clearly distinguishes itself as an initial aggregator rather than a single-resource reader. It does not explicitly differentiate from all siblings like read_journal, but the aggregate scope 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?

It gives explicit usage guidance: call it FIRST when starting a project, expect delta for familiar projects and full context for first-time projects. It also names a concrete alternative/fallback: use get_project_context when the result says 'many changes'. It lacks explicit when-not-to-use cases for the individual sibling read tools, but the main routing 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?

readOnlyHint=true already tells the agent this is a safe read, and an output schema exists so return shapes need not be spelled out. The description does add one genuinely useful behavioral detail: daily-limit data is only present on paid plans, so the agent knows fields may be absent. Beyond that it says nothing about auth, caching, or failure behavior, so the bar set by the annotations is only modestly exceeded.

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: the first states what is returned, the second when to call. Content is front-loaded and every clause earns its place, with the paid-plan caveat correctly attached inline to the affected data.

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 an output schema covering return values, zero parameters, and a readOnly annotation, the description covers everything needed to decide to call it and to interpret the result. Only minor gaps remain, such as what happens if the call itself is unauthorized or rate-limited.

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

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

The tool takes zero parameters, so parameter semantics are trivially satisfied and there is nothing for the description to compensate for. No misuse of the schema is possible here.

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 concrete resource it returns: plan/tariff, project slot occupancy, and daily quota remainders. This clearly separates it from the list_*/read_* siblings, which all deal with project content rather than account state. It does not explicitly name a sibling it replaces or excludes, and the name 'whoami' alone would suggest identity rather than quota, so the description is doing necessary corrective 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?

Gives two explicit trigger conditions: at session start, and after another tool fails due to a limit. That is concrete, actionable when-to-use guidance an agent can act on without inference. It stops short of 5 because it names no alternative tool or when-not condition.

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