Ruforge

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

No annotations exist, so the description carries the full behavioral burden and does so richly: it discloses the return payload (next question + progress + remaining), formatting expectation, milestone/insight surfacing, and the do-not-guess constraint on options. This is far beyond what a bare schema conveys.

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 verb+resource is front-loaded, but the description is a long multi-clause run-on covering record → display → milestone → remaining → fallback. Every clause carries useful instruction, yet it is denser than a two-sentence ideal, so a small conciseness deduction is warranted.

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 fully covers what matters: the return content (next question, progress, remaining), how to render it, and control-flow to sibling tools. The only unmapped element, session_id, is inferable from the diagnostic-session context.

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% (session_id is undocumented), but the description compensates by explaining the semantic of the input: pass the letter exactly as the user gave it, do not choose on their behalf, and clarify rather than infer on text answers. It still leaves session_id meaning to inference, so not a 5.

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 opens with a specific verb+resource: it records the user's answer to the current question and returns the NEXT question with progress. It clearly distinguishes itself from siblings by naming ruforge_diagnostic_finish and the piloting workflow (questions arrive one at a time), so an agent can tell it apart without opening schemas.

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 when-to-use and what-to-do-next: record the answer, show the next question in the same format, wait for the reply. It names the exact escalation condition (remaining=0 → call ruforge_diagnostic_finish) and the edge case (text instead of a letter → ask for the letter, don't interpret).

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the ≥10-answers prerequisite and hints at the returned payload, but says nothing about whether the call is idempotent, whether it closes/locks the session, what error occurs below the threshold, or whether the link expires — all material for a terminal mutation of a 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?

One sentence, outcome first, the returned artifacts enumerated, and the prerequisite trailing. No filler whatsoever.

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

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

The return contents are described well, which partly compensates for the absence of an output schema. But with no annotations, an undocumented session_id, and undefined failure behavior when fewer than 10 answers exist, the definition leaves gaps an agent would hit in practice.

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 session_id is undocumented in both schema and description. The tool hinges entirely on a valid session_id, and the description gives no hint about where it comes from (presumably rurforge_diagnostic_start) or that it must match an in-progress diagnostic.

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

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

The description gives a specific verb and resource ('Завершить диагностику и получить отчёт') and immediately enumerates what the report contains (overall level 1–4, 10 competencies, growth zones, link with a 90-day plan). It is clearly distinguishable from start/answer/questions siblings, though it never explicitly names an alternative such as rurforge_get_report.

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 a concrete precondition for calling it ('Нужно ≥10 ответов (лучше все)'), which is real, actionable gating information an agent needs before invoking. It does not, however, name an alternative path or say what to do when the threshold is unmet.

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

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

With no annotations, the description carries the full burden. It implies a safe re-fetch that also returns progress, but it says nothing about side effects, permissions, whether it alters session state, or what the response looks like.

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

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

A single compact sentence with the retrieval action front-loaded. Efficient, though the parenthetical about the question being lost could be phrased more usefully given the space it occupies.

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 annotations, no output schema, and no parameter documentation leave significant gaps: the agent cannot know what 'limit' does or what progress data is returned. For a tool whose name suggests diagnostics, this under-specifies materially.

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 0% for 2 parameters. The description never mentions session_id, and the 'limit' parameter (default 5, max 10) is completely unexplained – what it limits is left entirely to inference.

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

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

The description states a specific verb and resource: re-obtaining the session's current unanswered question and progress. 'Повторно' (re-fetch) implicitly distinguishes it from the start/answer siblings, but it does not name any 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?

It provides a clear condition for use – 'if it is lost' – which tells the agent when to reach for it. There is no explicit exclusion or named alternative, so it falls short of a full 5.

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

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

With no annotations, the description carries the burden well: it discloses that a session is created, that the response contains the first question and a progress field, that question count varies with answers (adaptive vs classic), and that the agent must not answer on the user's behalf. It does not cover state/error behavior (e.g. calling start twice, session expiry) or any auth/rate considerations.

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?

Front-loaded and purposeful, but a large share of the text is a conversational facilitation protocol (heading format, option listing, don't-combine rules) that belongs in agent instructions rather than tool selection material, and it partly duplicates the mode description already in 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?

With no output schema and no annotations, the description supplies what is needed: what the call returns (first question + progress), how many questions to expect, and the full downstream tool sequence. Missing only edge-case behavior on repeated/invalid calls.

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 enums are documented for all five optional params, so the schema already does the heavy lifting; the description largely restates mode semantics (~25 adaptive vs 33 classic). It adds one useful workflow cue by tying the required role param to a pre-start question, but nothing beyond that.

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 (создаёт сессию диагностики) plus concrete scope: adaptive mode, ~25 questions, returns the FIRST question. It is clearly distinguished from siblings, which are named by role in the flow (answer, finish).

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 positions itself as the ОСНОВНОЙ entry point, states the pre-condition (ask role, optionally company size and direct reports), and routes to ruforge_diagnostic_answer for each answer and ruforge_diagnostic_finish at the end. Alternatives and sequencing are 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?

No annotations are provided, so the description carries the full burden. 'Справочник' implies a read-only, parameterless lookup, and the description usefully discloses the payload shape (10 items, each with description and collection links). However, it never states that the call has no side effects, is static/cacheable, or what the per-item structure looks like beyond one clause.

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 identifies the resource, its size (10), and its contents (descriptions, collection links). No filler, no repetition 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?

For a zero-parameter, no-output-schema lookup tool, the description covers what the agent needs: what the data is, how many items, and what each item contains. The only gap is any statement about stability, ordering, or interaction with the adjacent diagnostic/kb tools, which would round it out.

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 and the schema is an empty object at 100% coverage, so there is nothing for the description to clarify; baseline 4 applies. The description correctly implies the tool is unfiltered and returns the full fixed set of 10 competencies.

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 resource: a reference directory of the 10 managerial competencies of the RuForge model, including descriptions and links to thematic collections. That distinguishes it clearly from content-oriented siblings like ruforge_kb_article and ruforge_get_maturity_levels. It lacks an explicit verb, but 'Справочник' plus the enumerated contents make the intent 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 reference-directory framing implies the usage context (looking up competency definitions), but there is no explicit statement of when to call this versus ruforge_get_maturity_levels or the kb_* tools. No preconditions or exclusions are given, leaving routing to inference from the resource 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?

No annotations are provided, so the description must carry the behavioral burden; calling it a 'Справочник' implies a read-only static lookup with no side effects, which is useful signal. It does not state return format, whether the content is fixed or localized, or any auth/caching behavior, leaving real gaps for a tool with zero annotation coverage.

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 that front-loads the resource ('4 maturity levels') and then adds the interpretive scope. No filler, though it is terse enough that an explicit verb and use-case clause would have cost nothing.

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

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

With no output schema and no annotations, the description is the only source of information, and it does say what content the reference holds. It stops short of describing the shape of the returned levels or the gap-interpretation rules, which an agent needs to use the result confidently.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly adds no parameter detail, matching the empty 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?

States a concrete resource: a reference listing the 4 managerial-maturity levels (a behavioral scale) plus guidance on reading the gap against a role's expected level. An agent can tell this apart from siblings like rforge_get_competencies or rforge_kb_article, though there is no explicit verb (e.g. 'returns'/'lists') and no naming of the nearest 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?

The word 'Справочник' (reference) implies this is a static lookup consulted when interpreting maturity results, and the mention of 'reading the gap with the expected role level' hints at the interpretation step. However, it never says when to call it instead of rforge_get_competencies or rforge_get_report, nor any preconditions.

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

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

No annotations, so the description carries the burden; it discloses the return payload structure and an important behavioral trait — the output excludes personal data. It omits what happens with an unknown/unfinished session_id, error behavior, or whether the report is generated on demand.

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 listing the resource and its contents, with no filler. It is appropriately sized, though it could have used one more clause for prerequisites.

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

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

With no output schema and no annotations, the description does well to enumerate the return contents and the no-personal-data guarantee, but it leaves out session prerequisites, session_id provenance, and error/edge behavior, which an agent needs 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 coverage is 0% — session_id has no description in the schema — and the description adds nothing beyond naming it, not stating where the id comes from (presumably ruforge_diagnostic_start) or its format. With only one required parameter this is a small gap, but the description doesn't compensate for the empty 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?

States a specific verb+resource: returns a diagnostic report for a given session_id, and enumerates what the report contains (overall level, 10 competency levels, growth zones). It does not explicitly distinguish itself from close siblings like ruforge_get_competencies or ruforge_get_maturity_levels, which overlap in the data they expose.

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

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

No when-to-use guidance, no prerequisites (e.g. that the session must be started/finished first), and no alternatives named. The only implied context is that a session_id must exist, which the agent has to infer from the sibling tools.

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

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

With no annotations, the description carries the burden and does disclose the key behavioral trait: the return value is *only* a link, not the test content, which shapes how the agent handles the result. It also clarifies the division of labor with the diagnostic siblings. It does not mention permissions or side effects, but for a trivial link retrieval that gap is small.

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 scoping constraint ('ТОЛЬКО ссылка') front-loaded, followed immediately by the routing advice. No filler or 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?

There is no output schema, and the description compensates by telling the agent what comes back (just a URL). Combined with the fully documented single parameter, an agent has what it needs to call and interpret the tool; only minor operational details are absent.

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% — the single 'source' parameter is already documented as the utm_source label, so the baseline is 3. The description adds nothing about this parameter, though given the schema's completeness that is not a serious omission.

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 web-version link to the test) and constrains scope emphatically with 'ТОЛЬКО ссылка', making clear the tool does not deliver the diagnostic itself. It explicitly contrasts with the sibling ruforge_diagnostic_start, so an agent can distinguish the two without opening 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?

It states the exact condition for use ('если пользователь хочет пройти в браузере') and names the alternative for the opposite case, ruforge_diagnostic_start, along with what that alternative does (gives questions, accepts answers). When-to-use, when-not, and the replacement route are all 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?

No annotations are provided, so the description carries the full burden. For a read-only fetch it does disclose the payload shape and the citing requirement, but it is silent on what happens for an unknown slug (error vs empty) and on whether a max_chars-truncated response is flagged as truncated.

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 dense sentence front-loads the operation and the return contents, followed by a short actionable citation instruction. No filler, nothing repeated from the schema beyond the useful slug provenance.

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

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

With no output schema and no annotations, the description must explain the return value, and it does so concretely. The only gaps are error behavior for invalid slugs and whether truncation is signaled, both minor for a two-parameter read tool.

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

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

Schema coverage is 100%, so both parameters are already documented. The description still adds provenance for slug (URL path or search result), which the schema does not explain, and the max_chars truncation semantic is coherent between schema and prose.

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?

Starts with a specific verb+resource: fetches the full text of a RuForge knowledge-base article by slug. It enumerates what comes back (title, author/reviewer, date, body with section headings, tables, source links), which clearly separates it from rufoge_kb_search, the sibling that only returns search hits.

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?

Tells the agent where a slug comes from — the /knowledge-base/<slug>/ URL or a rufoge_kb_search result — which is exactly the routing information needed to pick this tool after a search. It adds the citation instruction (cite with URL) but never states exclusions, e.g. when to prefer search/recommend instead of a full fetch.

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

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

No annotations exist, so the description carries the full behavioral burden. It implies a read-only recommendation lookup but discloses nothing about prerequisites (e.g., must the session_id come from a completed diagnostic?), behavior with zero parameters (all three are optional), failure modes for an invalid session_id, or rate/limits.

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 zero waste that front-loads the resource and then enumerates both targeting modes. Everything stated 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 3-optional-parameter recommendation tool with no annotations and no output schema, the description covers purpose and the two modes but leaves the all-optional edge case, mode-precedence, and result shape undescribed. Adequate, 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?

Schema coverage is 100%, so each parameter is already documented in the schema. The description adds the key semantic fact that domain+level form one mode and session_id an alternative mode, which the schema does not state, but adds no syntax or format detail beyond that. 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 output (material recommendations for developing a competency) and defines two precise input modes: (domain + level) or (session_id). It is clearly distinguishable from ruforge_kb_search / ruforge_kb_article, though it never names those siblings to contrast itself.

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

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

The two alternative entry paths imply when each is used (level-based targeting vs. diagnostic-result-driven targeting), which is real usage context. However, it never says when to prefer this over ruforge_kb_search, nor what happens if neither mode is used or if both are supplied.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return fields (title, URL, annotation) and the non-obvious quirk that limit≤2 or a slug also returns full text. It omits result ordering, empty-result behavior, and pagination, which keeps it below 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?

Two tight sentences: the first states purpose and filters, the second states the return contract and its exception. No filler, and the most decision-relevant information (what you get back) is placed before the caveat.

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-optional-parameter search tool with no output schema and no annotations, the description covers purpose, filters, and return shape, which is what an agent needs to select and call it. It falls short only on combining multiple filters and ordering of results.

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 already 86%, so the baseline is 3. The description adds real value beyond the schema by tying the filters to searchable dimensions and, crucially, by explaining the cross-parameter effect of limit≤2 and slug on the response payload — information not present in 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 ('Поиск') and resource ('материалов базы знаний RuForge') plus the enumeration of content types (articles, practices, cases, glossary) and filter dimensions. It does not name or distinguish the closest sibling, ruforge_kb_article, even though the slug/full-text behavior clearly overlaps with it.

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 filter dimensions (competency, maturity, role, text) imply when this tool is appropriate, and the slug/limit≤2 clause hints at a direct-fetch use case. However, there is no explicit guidance about when to prefer ruforge_kb_article or ruforge_kb_recommend, and no statement of exclusions.

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