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

With no annotations, the description carries the full burden and does disclose real traits: it runs without a shell, auto-strips Gutenberg boilerplate, sets a tier, requires user confirmation before downloading, and enforces a license=public-domain gate for non-PD hosts. It omits idempotency/conflict behavior and permission requirements, so it is strong but not exhaustive.

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-loads the core action, then uses pipe delimiters to compactly present the three input modes, safety rule, and next step. Dense but every clause earns its place; no 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?

For a 10-parameter mutating tool with no annotations and no output schema, the description covers the workflow and key safety/license rules but leaves several parameters and the result of ingestion undocumented. Adequate but with material gaps given the tool's complexity.

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 30% across 10 params, so the description must compensate. It usefully explains url (fetch + strip), text (insertion), path (local file), tier assignment, and the license gate, but leaves basename, back_from, front_until, and advisor_dir unexplained in both schema and description. Partial compensation only.

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 ('pull a source into the advisor's sources/') and enumerates the three intake modes (url/text/path). It also names the follow-on sibling build_advisor, so the agent can distinguish ingestion from corpus assembly. Slightly dense with parenthetical detail, but the core action is 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?

Guides mode selection (url=fetch+strip, text=insertion, path=local file) and routes the next step to build_advisor. It also states a precondition ('confirm the download with the user') and a gating rule (non-PD host requires license=public-domain). It stops short of naming explicit when-not conditions or alternative ingestion siblings.

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 usefully discloses the Laplace-smoothed default (neutral weight when data is absent), which is real behavioral context. However, it says nothing about persistence of the updated weights, idempotency, permissions, or what the call returns, leaving meaningful gaps for a mutation-style calibration 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?

Very compact and front-loaded: purpose first, then the record shape, then the default-behavior caveat. The telegraphic arrow notation ('→') and jargon ('петля U1') cost some clarity but nothing is wasted.

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

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

For a single-parameter calibration tool with no output schema and no annotations, the description covers the input shape and the no-data fallback but omits the return value and any indication of side effects on stored weights. Adequate but not complete.

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

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

Schema coverage is 0% and the schema only declares 'records' as an untyped array, so the description must compensate. It does by giving the item shape: records=[{advisor,outcome,endorsed}], which names the three expected fields. It still does not define value types, allowed outcome/endorsed values, or how they are interpreted, so it is not fully self-sufficient.

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: it calibrates ('Калибровка') the council ('совета') using outcome data, and identifies the mechanism (loop U1, who was right for you → voice weight). This distinguishes it from generic siblings like calibrate or prediction_calibration. It does not explicitly name or exclude a sibling, so it falls short of a 5.

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

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

The phrase 'кто был прав ДЛЯ ТЕБЯ' and the 'loop U1' label imply this runs after outcomes are known, but the description never states when to use it versus calibrate / prediction_calibration / pending_outcomes. It does note the fallback case (no data → neutral), which is useful but is behavior rather than usage routing.

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 behavioral burden. It sketches an internal pipeline (split → gate → gap) but says nothing about side effects, whether it is read-only, permission requirements, cost/latency, or determinism. The 'advisor_dir' parameter hints at filesystem access but this is never confirmed.

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

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

A single dense sentence that front-loads the core action and ends with the distinctive output (inflation gap). No filler, though the compressed jargon limits immediate comprehension.

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, no annotations, and two undocumented parameters, the description leaves major gaps. It names the headline output metric but does not describe the return structure, the role of advisor_dir, or any failure modes — insufficient for a tool of this apparent complexity.

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

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

Schema description coverage is 0% and there are two required parameters. The description implies 'text' is the statement being split ('разбить заявление на атомы'), but 'advisor_dir' is entirely unexplained in both schema and description. With 0% coverage the description must compensate and it does not.

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 multi-step operation: decompose a claim into atoms, verify each with a gate, and produce an 'inflation gap' metric. This is more than a restatement of the name, though the jargon ('gates', 'atoms', 'inflation gap') is domain-specific and never defined. It does not explicitly distinguish itself from siblings like fidelity_check or gate_verdict.

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

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

There is no when-to-use guidance, no stated preconditions, and no mention of alternatives such as fidelity_check or gate_verdict that appear to operate in adjacent territory. The agent is left to infer when atomic decomposition is preferable to a plain fidelity check.

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 disclosure burden. It does add real behavioral value by warning that the response may include pending_outcomes and a loop_nudge, and that the nudge should be followed. It does not state that this is a read-only/status operation, whether it has side effects, or anything about permissions 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?

Three short sentences, front-loaded with what the tool reports and what it returns, with no filler. Jargon-heavy ('Шасси-онбординг', 'Принцепс/советники/линзы') adds density but not padding.

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 status tool with no output schema, the description usefully sketches the return shape (board readiness, one next step, possible pending_outcomes and loop_nudge). That covers what an agent needs to act, with only the safety/read-only profile 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level meaning is missing.

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 resource and scope: a board/onboarding status check reporting what is ready (Princeps/advisors/lenses) plus one prioritized next build step. That's more than a restatement of the name. However, it never differentiates itself from siblings like loop_status or pending_outcomes, which overlap conceptually with the outputs it mentions.

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 when to call it (at the start of a session, to guide the user). It gives clear invocation context but names no when-not condition and no alternative tool, so it stops short of full routing 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?

With no annotations, the description carries the full burden and does disclose the key non-obvious trait: this is a long-running BACKGROUND JOB that returns {job_id} immediately and must be polled via job_status. It does not cover permissions, failure modes, or rate limits, keeping it just short of a 5.

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

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

Front-loaded and dense: pipeline, then advisor_dir path, then the async warning, then the prerequisite. Every clause carries signal, though the arrow notation and abbreviations assume shared vocabulary.

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, but the description explains the return value ({job_id}) and the polling mechanism, filling that gap well. For a 4-param tool it is only incomplete on parameter meanings, but the operational behavior an agent needs is present.

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 compensate, but it only clarifies one of four parameters (advisor_dir = advisors/{name}). The stages 'corpus → kernels → индекс' hint at run_kernels/run_index, yet neither those flags nor 'author' is given any meaning.

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 ('Собрать советника' / build an advisor) and enumerates the pipeline stages (manifest-gate → corpus → kernels → index), so the agent understands it is a turnkey build operation. It is clearly distinguishable from validate_manifest and the catalog/federation 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?

Explicitly prescribes the prerequisite ('Сначала validate_manifest' – run validate_manifest first) and the correct follow-up pattern ('не жди здесь' – don't wait, poll job_status). It names the alternative tool and the condition under which it is used.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the write destination and that output is 'personal, not shipped', plus the interactivity requirement — real behavioral context. But it omits overwrite/idempotency behavior, whether existing lenses are destroyed, and any permission or rate-limit constraints.

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?

Dense and front-loaded: purpose first, then source options, kind, output, and workflow. Uses arrows and private notation (P1/U1, rule #8) that is cryptic but compact; nearly 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?

For a 12-parameter tool with no annotations and no output schema, the description covers the core concept, source modes, kind, destination, and interactive requirement. It is, however, incomplete on the many undocumented parameters and on behavioral traits, leaving gaps an agent must guess at.

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 document all 12 parameters, yet it only explains ground_text/ground_url/ground_path, kind's enum values, and reading_notes. axis, dest, name, slug, author, license, and run_kernels are left undocumented, so a majority of parameters carry no semantics anywhere.

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: 'build a grounded-LENS from any source', and distinguishes the concept from personalities ('lenses > personalities'). It also explains the P1/U1 layering, so an agent understands what artifact is produced. It stops short of naming a sibling tool it should be chosen over.

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 workflow guidance: the result lands in advisors/<slug> and should 'immediately' be used with cite/retrieve, and it flags that assembly is interactive (ask for source + 'how YOU read'). No explicit when-not-to-use or sibling alternative is given, so it is context without exclusions.

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

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

With no annotations, the description carries the full burden, and it only gestures at behavior with 'guardrail захвата' and a mention of a metric. It never discloses side effects, permissions, whether the call mutates the journal, or what the recommendation/guardrail actually does.

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, but they are cryptic and under-specified rather than efficient — heavy jargon and an ambiguous metric clause that do not front-load an actionable 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 single-parameter tool with no annotations and no output schema, the description should at least define the input and the returned recommendation. It leaves the agent guessing about both the parameter's expected form and the tool's actual effect.

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% and the single parameter log_text has no description. The phrase 'по журналу решений' loosely implies the input is a decision journal, giving marginal meaning, but nothing explains format, size, or expected content of log_text.

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 deliverable ('Рекомендация подачи (светлый/тёмный)') and an input source ('по журналу решений'), but the verb is implicit and the phrasing ('guardrail захвата', 'одобрено-задним-числом') is jargon that never states plainly what 'calibrate' does. An agent cannot confidently distinguish this from prediction_calibration or calibrated_consult_* 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?

There is no when-to-use statement, no prerequisites, and no mention of any alternative. The description says nothing about the conditions under which this tool should be chosen over its many calibration-related siblings.

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 full burden. It discloses the computed return content (the 'mirror' metrics) and the optional prediction contract, which is useful, but says nothing about mutation semantics, permissions, idempotency, or whether the consult must still be open. Adequate but incomplete for a write 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?

Dense but front-loaded, leading with the core action and result before the parameter and sequencing notes. Every clause carries information; the heavy caps emphasis is slightly noisy but not wasteful.

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

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

No output schema and no annotations, so the description must cover everything. It does cover purpose, the returned 'mirror', and workflow placement, but omits behavioral traits (auth, idempotency, error/edge conditions) and several parameter meanings, leaving real 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 0% with 6 parameters, so the description must compensate. It explains followed_council ('did you accept the council position') and prediction (optional, decision_card contract), but leaves consult_id, posterior_call, posterior_confidence, and posterior_abstain undocumented in both schema and text.

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: records YOUR position after the council answer and produces a 'mirror' with concrete sub-metrics (position shift, confidence inflation, suppression of 'I don't know'). Clearly differentiated from the open/resolve siblings by its 'after the council response' placement.

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 places itself in the workflow: 'Идёт после calibrated_consult_open; закрой исход позже через calibrated_consult_resolve', naming the preceding and succeeding siblings. No explicit when-not condition, but the sequencing leaves little ambiguity.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral trait: small N yields trustworthy=false, telling the agent how to interpret output. However it omits read-only/side-effect disclosure, authentication expectations, and any return-format context beyond the flag.

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?

Compact at roughly two clauses: the metric summary is front-loaded and the trustworthy=false caveat follows. Information-dense with little waste, though the heavy Russian jargon makes it slightly harder to parse on first read.

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

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

For a no-parameter, read-only summary tool with no output schema, the description does the needed work by naming the metrics returned and the trustworthy flag that qualifies them. It leaves minor ambiguity around the acronym-heavy metric names but is otherwise sufficient for correct invocation.

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

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

The tool takes zero parameters (empty schema, none required), so there is no parameter semantics to document. The baseline for a 0-parameter tool is 4.

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 resource and scope: a summary ('Сводка') of overreliance OSI metrics over the user's consults, enumerating concrete signals (confidence inflation, suppressed 'don't know', advisory-vs-independent calibration). This differentiates it from siblings like calibrated_consult_open/close/resolve and calibrate, which handle the consult lifecycle rather than reporting on it. The dense jargon slightly obscures the verb, but the intent is discernible.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite the presence of closely related siblings (calibrated_consult_close, calibrate, prediction_calibration). Usage can only be inferred from the metrics listed.

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 behavioral burden. It discloses the critical trait that this is a mutation ("Пишет запись (Rule 0)"), which is valuable, but it does not cover permissions, idempotency, re-call behavior, or what exactly gets recorded. "Rule 0" is unexplained jargon rather than usable disclosure.

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 tight sentences, front-loaded with the tool's identity and the anti-overreliance framing before the sequencing instructions. No filler, though the density of Russian jargon and "Rule 0" reduces immediate clarity.

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 4-parameter mutation with no annotations, no output schema, and 0% schema coverage, the description conveys the workflow and the write behavior but leaves the parameter contract and side effects largely unexplained. Adequate for sequencing, incomplete for actually invoking 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% across 4 parameters, so the description must compensate and largely does not. It only implies the meaning of prior_confidence by giving the range "(0..1)", which adds a little beyond the bare "number" type; question, prior_call, and prior_abstain are never explained.

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

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

States a concrete verb+resource ("зафиксировать ТВОЮ позицию + уверенность" – record your position and confidence) and explicitly frames itself as a tool, not advice ("ИНСТРУМЕНТ (не совет)"). It also names the sibling it pairs with (calibrated_consult_close), so it is distinguishable, though the purpose is somewhat entangled with the multi-step workflow.

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

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

Explicit sequencing: call in calibrated-consult mode BEFORE asking the council, then call calibrated_consult_close AFTER the response. The alternative sibling is named with its condition. No explicit when-not guidance, but the ordering 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?

No annotations are provided, so the description carries the full burden, and it delivers meaningful behavior: it is a fail-closed mutation that rejects the call without an existing prediction and a valid outcome type, and it feeds the overreliance-axis calibration. It stops short of saying what failure looks like (error vs no-op) or whether a set outcome can be overwritten.

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?

Four tight sentence-fragments with the action front-loaded, then shape, then effect, then prerequisites and cross-reference. Dense but every fragment carries information; only the terse 'occurred|actual' shorthand costs clarity.

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 a nested object at 0% schema coverage and no output schema, the description does substantial work (shape, fail-closed prerequisite, journal cross-reference) but leaves the outcome payload underspecified and the resolve-vs-close distinction unaddressed for a tool in a three-part consult lifecycle.

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% and the outcome parameter is an opaque nested object, so the description must compensate – and it does partially by enumerating the shape {resolved_on, occurred|actual, endorsed?}. But the 'occurred|actual' alternation is ambiguous (two field names or one?) and consult_id is never explained, leaving real gaps for a nested object.

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

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

States a specific action verb ('Проставить ИСХОД' – set the outcome) on a named resource (consult), and anchors the effect ('Кормит калибровку оси оверрелайанса'). Sibling differentiation is partial: it points to calibrated_consult_journal for the summary but never clarifies how this differs from calibrated_consult_close, which an agent could easily confuse it with.

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 usage condition ('когда факт лёг' – when the fact has landed) and a prerequisite ('нужен прогноз в консульте'), which is better than nothing. However it never states when to use this instead of calibrated_consult_close, nor any when-not conditions, leaving the open/close/resolve lifecycle ambiguous.

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 behavioral burden. It discloses the transformation shape (raw → structured) but says nothing about persistence, side effects, permissions, or whether anything is stored — an agent cannot tell if this is a read-only parse or a write.

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

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

A single dense sentence using an explicit arrow from input to output, front-loaded with the core action. The arrow notation is compact and readable; 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?

With no annotations and no output schema, the description must cover behavior, and it only sketches the transformed result. It omits side effects, storage, and failure modes, leaving real gaps for a tool that appears to feed a larger decision workflow.

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% and the single parameter is documented only as a string. The description compensates partially by defining what the text should contain ('сырой дамп: чат-лог конфликта/описание решения'), but never names the 'text' field or gives format/length guidance.

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 transformation: 'Захват контекста' turns a raw dump (conflict chat log / decision description) into a structure of actors, utterances, and explicit questions. That is a concrete input→output contract rather than a restatement of the name. It does not explicitly distinguish itself from nearby siblings like situation_analyze or situation_stress_test, so it stops short of a 5.

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

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

Usage is only implied by 'Вход для карты и рейм-чека' — it tells the agent this is a preprocessing step feeding the decision map and frame-check. There is no explicit when-to-use/when-not or named alternative among the many situation_* and decision_* siblings.

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 so well: it discloses the fetch→signature-verify→assemble pipeline, fail-closed behavior on drift, and the output location advisors/<id>. It omits permission/auth requirements and the shape of the response, but the failure semantics are unusually transparent.

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 with the core action, then the confirmation rule, then the pipeline in a compact arrow-chained sentence. Dense but every clause carries information; the telegraphic style costs a little readability.

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 multi-step mutation tool with no output schema and no annotations, the description covers the workflow, the safety gate, and the artifact destination. The main gap is the return value and any error/auth surface an agent would want before invoking.

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%, so the description must compensate. It hints that ref is a catalog reference or url and explicitly ties license=public-domain to non-PD hosts, adding real meaning to the optional parameter, but leaves ref's exact format and the accepted license values 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?

The description states a specific verb+resource+scope: assembling a PD-advisor LOCALLY from a catalog or url. It differentiates from the catalog_* siblings by naming catalog_preview as a prerequisite and by emphasizing local assembly, though it does not explicitly contrast with build_advisor or federation_assemble.

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 precondition (Rule 0 user confirmation) and names catalog_preview as the tool to run first, which routes the agent correctly. It stops short of stating when NOT to use the tool or fully enumerating alternatives.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that no fetching occurs and what fields are returned, but says nothing about ordering, result size/pagination, permissions, or side effects for what is presumably a bulk listing.

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 segments, front-loaded with the resource and its return fields, with no filler. It is appropriately terse for a simple list tool, though the final sentence is idiomatic enough to be slightly ambiguous.

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 parameters and no output schema, the description compensates by naming the returned fields. For a simple catalog listing that is close to sufficient, though ordering and pagination behavior for a potentially long list remain unaddressed.

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 per the rubric the baseline is 4. The description correctly implies a parameterless, unfiltered listing and adds the returned field set, which is the relevant semantic content 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?

States a specific verb and resource ('Список PD-фигур каталога') and enumerates the returned fields (id/имя/место/издание/PD-basis), so the agent knows exactly what it gets. It does not explicitly distinguish itself from siblings like catalog_search or catalog_preview, though 'Без фетча' hints at the difference.

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

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

The phrase 'Без фетча' implies this is a lightweight listing rather than a detail fetch (catalog_preview) or query (catalog_search), and the council remark gestures at why one would list. But no alternative tool is named and no explicit when/when-not condition is given, leaving the routing to inference.

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

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

With no annotations, the description carries the full burden and does well: 'НЕ собирает' signals this is a non-mutating read, and it discloses the return contents (sample, caption, PD-host, warnings) and the consent-card role. It does not mention auth requirements, rate limits, or what happens on an invalid ref, so it stops short of a 5.

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

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

Extremely compact (three short clauses), front-loaded with the core action and return contents, then the critical behavioral constraint and the param semantics. Every phrase carries information; nothing is waste.

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

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

No output schema exists, but the description compensates by listing the preview's fields. Combined with the explicit non-assembly statement and the catalog_add sequencing rule, an agent has enough to call it correctly; only error handling and auth remain unaddressed.

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 param has no schema description, so the description must compensate — and it does: 'ref = id каталога ИЛИ прямой url' explains the accepted reference forms. It does not specify URL format or id syntax, keeping it at 4 rather than 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?

States a specific verb (превью/preview) and resource (PD-издание), and enumerates exactly what the preview contains: sample text, caption, PD-host, warnings. It distinguishes itself from sibling catalog_add by explicitly saying it does NOT assemble, so an agent can separate it 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?

Explicit sequencing rule: 'show to user BEFORE catalog_add', and it names catalog_add as the follow-up alternative. The consent-card framing tells the agent this is a mandatory human-in-the-loop step, which is actionable guidance, not mere implication.

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 usefully discloses return content ('candidates with PD-basis') and a failure mode ('offline → honest error'), but says nothing about permissions, rate limits, or how results are ranked/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?

Three terse sentences, purpose front-loaded, no filler. Every clause adds a distinct fact (external source, return shape, offline behavior). Slightly telegraphic but efficient.

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

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

For a simple one-param read tool with no output schema, the description covers purpose, return content, and one failure mode, which is adequate. It still leaves the author parameter semantics and when-to-use guidance 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 coverage is 0% and the single 'author' parameter is undocumented in the schema. The description only alludes to 'фигуры' and adds no format guidance (full name? surname? transliteration?), so it fails to compensate for the coverage gap.

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

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

States a specific verb (поиск) and resource (PD-издания фигуры), plus an explicit scope boundary (ВНЕ каталога, via Gutenberg/gutendex). This boundary implicitly separates it from the catalog_list/catalog_verify siblings that operate inside the catalog, though no sibling is named directly.

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

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

The phrase 'ВНЕ каталога' implies you should reach for this when the figure is not in the local catalog, but there is no explicit when-to-use statement, no named alternative, and no stated prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden. It does disclose that this is a read-style integrity check that reports drift and does not perform assembly (no build side effect), which is useful. However it omits any statement about mutation safety, permissions, or what the drift report contains.

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

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

A single compact sentence that front-loads the core action and appends the key constraint ('без сборки'). It wastes little space, though the untranslated jargon reduces immediate clarity.

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 tool with no output schema and no annotations, the description covers the action and the non-assembly constraint. It stops short of describing the drift report's shape or the meaning of 'PD-basis', leaving an agent with a partial picture of the result.

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 per the rubric the baseline is 4. Schema coverage is 100% and there is nothing for the description to clarify at the parameter level.

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 (catalog integrity verification) and details the operation: traverse records, verify signature/PD-basis, report drift. This distinguishes it from siblings like catalog_list, catalog_search, and catalog_add. The opaque 'как moat-check' analogy and undefined 'PD-basis' jargon keep it short of a 5.

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

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

The phrase 'Без сборки' (without assembly) implies it is not the build/assemble path, hinting at one exclusion. But there is no explicit when-to-use guidance versus close alternatives such as validate_manifest, doctor, governance_verify, or fidelity_check, all of which plausibly overlap with catalog verification.

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 shape ({quotes[], best}), the empty-result behavior (quotes:[], 🟡), the judgment_request branch with follow-up action, and the rule not to rewrite text. It omits error/permission behavior, so not 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?

Front-loaded with the core purpose and return shape, then the query-formatting and branch guidance. Dense but every sentence carries information; the emoji/symbol shorthand adds minor noise.

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

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

No output schema exists, but the description supplies the return shape, the empty case, and the alternate phase flow, which is what an agent needs. The unexplained `limit`/`top_k`/`use_kernels` parameters are the main remaining gap.

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

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

Schema coverage is only 20% (advisor_dir documented), so the description must compensate. It explains that `query` accepts a list of formulations and should be in the corpus language (English), which is real information beyond the schema, and hints at kernel anchoring (implying use_kernels). However `limit` and `top_k` are left entirely 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 a specific verb and resource: retrieve ready-made quotes for an argument, explicitly contrasting with manual assembly ('ручной сборки'). It does not name a sibling such as `retrieve` to disambiguate, so it stops short of a 5.

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

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

Gives concrete usage context: how to formulate `query` (list of phrasings, in the corpus language), what to do when nothing matches verbatim, and routes the agent to `gate_verdict` in the phase=judgment_request case. It never states when NOT to use this tool or how it differs from the sibling `retrieve`, so no explicit exclusion.

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 discloses a lot: it is explicitly MUTATING (Rule 0), it is fail-closed (refuses foreign units and pre-created dates), and it explains the division of labor (numbers into the Card, glyph left to the human). Missing only things like persistence effect on existing card data or return 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?

Dense and front-loaded – the mutating nature and core behavior come first, then lookup mechanism, then outcome shape, then fail-closed rule and the follow-up call. Every clause carries information, though the packing is heavy.

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-param mutating tool with no annotations and no output schema, the description covers the mutation semantics, both lookup keys, the nested object, the failure policy, and the next step. It is close to complete, lacking only return-value expectations.

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%, yet the description compensates: card_id scans decisions/ while path is the alternative, and it spells out the nested outcome shape {resolved_on, occurred|actual, endorsed?, note?} with unit semantics (occurred for event, actual in the same units for metric). This meaningfully exceeds the bare 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 ("Закрыть") plus resource ("Decision Card") and the exact scope of the operation – recording the outcome fact. It clearly distinguishes itself from save_decision_card (create) and prediction_calibration (a follow-up), so an agent can tell what it does without opening the schema.

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

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

Gives explicit sequencing ("Потом зови prediction_calibration") and preconditions (fail-closed on foreign units or a date before created). It implies the when-to-use context well but never explicitly contrasts with the sibling save_decision_card, so it stops short of full alternative routing.

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 burden. It usefully discloses the read-only, non-mutating nature ('без правки файла'), which is genuine behavioral context beyond the schema, but says nothing about permissions, response format, or failure modes.

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 that front-loads the resource and its read-only constraint, then the scope. No filler; the ellipsis hints at additional keys without bloating the text.

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 low-complexity read tool with one optional param, no output schema, and no nested objects, the description covers resource, scope, and safety adequately. Only a note on the returned structure would add value.

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% and the single 'key' parameter is a bare string, so the description must compensate. It does by explaining that key selects one config entry and gives concrete examples (retrieval_mode, abstain_threshold, hybrid_alpha), clarifying intended values where the schema offers nothing.

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

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

States a specific verb (read) and resource (board_config.json), plus scope: the entire config or one key. The parenthetical 'тюнинг без правки файла' distinguishes it from the write-side sibling config_set, though it does not name that sibling 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?

Implies read-only usage versus file modification, giving the agent context for when to pick this over config_set, but it never names the alternative or states conditions/exclusions explicitly.

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 but does disclose two meaningful traits: the write is persistent and requires user confirmation. It omits what happens on invalid keys, whether existing values are overwritten, and any error/return behavior, leaving significant gaps for a mutation tool.

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

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

Three short clauses, front-loaded with the core action, then the safety prerequisite, then examples. Every sentence adds information with no padding.

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

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

For a mutation tool with no annotations and no output schema, the description covers purpose, persistence and confirmation, but omits validation behavior, overwrite semantics, and full parameter semantics. It is adequate but not complete for a config-writing operation.

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% for two required params, so the description must compensate. It partially does by giving concrete key examples (retrieval_mode with allowed values auto|hybrid, abstain_threshold=0.5), but it does not explain the value type constraints or enumerate valid keys, leaving one of the two params thinly covered.

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: writing a key into board_config.json, and adds the scope 'тюнинг из хоста, persistent'. An agent can tell it is the write counterpart to the sibling config_get, though no sibling is named explicitly.

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

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

It gives a real prerequisite ('ПОДТВЕРДИ у юзера перед вызовом') and example keys/values, which imply the intended tuning context. It never says when to prefer this over config_get or how to pick valid keys, so guidance stays implied rather than 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?

With no annotations, the description carries the full burden and does so well: it discloses read-only, zero-LLM, code-computed behavior, enumerates output components (scores, dispersion, council confidence, overrides, missing), and names override triggers (ruin ceiling, irreversibility under split, unanimity anxiety, WAIT). It also clarifies that errors are surfaced as council questions. It stops short of stating auth or rate 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?

Purpose is front-loaded ahead of the output and parameter details, and the arrow-separated clauses keep it information-dense rather than padded. It is still a single heavy paragraph, which makes the later clauses harder to scan.

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

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

For a complex tool with 3 params, nested objects, no annotations, and no output schema, the description usefully substitutes for the missing output schema by listing return components and override behaviors. It remains incomplete on the nested scorecard shape and the lang parameter.

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%, so the description must compensate. It documents track_weights semantics (advisor_weights output as-is, multiplier clamped 0.5..1.5) and sketches scorecard contents (per-advisor scores 0..10, lens weight 1..3, confidence 1..5, ruin_risk, door, change_my_mind, question_for_user). The required nested scorecard structure and the lang enum are not explained, leaving a real gap.

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

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

States a specific verb+resource ('вердикт совета по scorecard') and qualifies it precisely as read-only, zero-LLM, code-computed. It enumerates the output labels (ИДТИ / ИДТИ С УСЛОВИЯМИ / ПЕРЕДЕЛАТЬ / НЕ ДЕЛАТЬ / ЖДАТЬ), clearly distinguishing it from verdict-adjacent siblings like gate_verdict.

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?

Sequencing guidance is present ('после форума по вопросу-решению'), which implies when to call it. However, no alternative tool is named and no explicit when-not condition is given (e.g., vs gate_verdict or advisor_weights), so usage is implied rather than routed.

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 usefully discloses that the tool is deterministic ('Ноль LLM, чистая агрегация') and invariant-preserving (tiers copied as-is from session.advisors[].opinions[].marker; never raises or invents 🔵). But it omits whether it persists/writes a record (the name 'decision_record' implies a side effect), auth requirements, and return shape.

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-loads the identity and trigger condition, then the output contents, then the key invariant — each clause earns its place despite dense jargon and capitalization. No filler or repetition.

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

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

Covers purpose, trigger, output contents, and a core determinism/tier invariant, which is substantial for a nested-object tool with no output schema. Gaps remain on the optional 'surface' param, whether the tool persists an artifact, and its return value, so it is adequate but not complete.

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

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

Schema coverage is 0% for two parameters, so the description should compensate. It does add meaning for the required 'session' object by referencing its nested structure (advisors[].opinions[].marker, disagreement), which is genuine value beyond the schema. It says nothing about the 'surface' parameter or its md-only enum, leaving that half undocumented.

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: assembles a meeting protocol/minutes from the council's canonical output, itemizing what it collects (advisor positions, dissent, decision+status, review triggers, marker provenance). The purpose is concrete and distinguishable from a generic renderer. However, it never names or contrasts against the many nearby siblings (council_verdict, render_session, save_decision_card, close_decision_card), so the agent must infer differentiation.

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 activation condition — only on an EXPLICIT user request, with trigger phrases quoted ('протокол', 'минуты', 'оформи решение'). This is a clear when-to-use cue. It stops short of naming alternatives or stating when NOT to use it relative to sibling tools that also produce session artifacts.

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

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

With no annotations, the description carries the full burden and does disclose the key traits: read-only, the 0..1 output scale, the duplicate threshold, and the follow-up action on a low score. It does not cover edge behavior (empty/single-advisor lists, error handling) or performance, but for a local read-only analysis tool the disclosure is solid.

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?

Purpose is front-loaded, then the mandatory-usage rule and thresholds; two dense sentences with almost no filler. The parenthetical metric list is information-packed rather than wasteful, though the sentence is long enough to be slightly hard to parse.

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

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

Covers the missing output schema by describing the return values (diversity score, dup flags, uncovered axes) and supplies the decision threshold and required next action. The remaining gap is the undocumented advisor_dirs format, which the description should have specified given 0% schema coverage.

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% and there is a single parameter, advisor_dirs, whose array-of-paths format is never explained in the description. The phrase 'состав совета' implies these are the advisor directories to be evaluated, so the meaning is inferable, but no format, expected structure, or minimum count is given.

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 (checks orthogonality of council composition) and enumerates exactly what it computes: diversity 0..1, duplicate-voice detection (similarity >= 0.5 → flag=dup), and uncovered thinking axes. Neither the resource nor the output metrics could be confused with any sibling such as board_status or council_verdict.

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?

'ОБЯЗАТЕЛЬНО перед созывом совета (правило 18в)' gives an explicit mandatory trigger plus the interpretation rule (diversity < 0.5 = echo chamber → warn user, propose a counter-voice). It is very clear on when to call it, but never names an alternative tool or a when-not condition, so it stops short of full routing 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?

With no annotations, the description carries the full burden, and it does disclose two useful traits: 'Read-only' and 'БЕЗ выхода из агента' (self-contained, no external calls). It also hints at return shapes ('P1→🔵, фейк→None'). It stops short of describing return format or what failure states to expect, leaving meaningful gaps for a diagnostic 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?

It is compact and front-loads the purpose, but the mixed Russian/English with arrow-and-emoji notation ('P1→🔵, фейк→None') and a parentheses aside '(ollama?)' makes the structure cryptic rather than cleanly scannable.

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

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

For a zero-parameter, annotation-less, output-schema-less diagnostic, the description covers the essentials: what is checked and the reason to call it. It is nearly complete, with only the return semantics left partly opaque.

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 (empty schema), so there is nothing for the description to disambiguate. Per the baseline, a 4 is appropriate; the description correctly implies the tool is parameterless.

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 ('Health-check машины') and enumerates the concrete checks: Python, skill installed, tier, and a self-test of the moat. It is clear what the tool does, but it does not name or distinguish itself from siblings such as ollama_status, ollama_ensure, or setup_full, which also probe readiness-tier concerns.

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 closing clause 'Зови, чтобы понять, готова ли эта машина собирать' gives an implied use case (determine whether the machine is ready to assemble). However, it names no alternatives and gives no when-not conditions, so an agent must infer whether this precedes setup_full or overlaps with ollama_status.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the return is FACTS with source_ref and instructs the agent to relay them to the user, which is useful output behavior, but says nothing about permissions, whether it is read-only, or any constraints.

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?

Purpose is front-loaded and the topic syntax list, though long, earns its place by compensating for the empty schema. Slightly dense but no wasteful sentences.

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 still covers purpose, input syntax, and return content (facts with source_ref). Only the routing-vs-siblings guidance and permission profile 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 coverage is 0%, so the description must carry the parameter fully, and it does: it enumerates empty/overview, tool:<name>, rule:<N>, recipe:<id>, concept:moat|firewall|architecture|extend, term:<word>, and free text. This is exactly the syntax and value set the bare 'topic' string property lacks.

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 (explain) and resource (the project itself / a tool, rule, concept, or term), with the sub-scope enumerated explicitly. An agent can distinguish it from siblings like catalog_list, retrieve, or cite without opening any schema.

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

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

The topic taxonomy (overview | tool:<name> | rule:<N> | concept:... | term:<word>) clearly frames when this tool applies versus other lookups. It gives strong context but never names an alternative or states an exclusion, so it stops short of the top tier.

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 that it writes no files, operates only on the current session object, and instructs the caller to return `content` to the user rather than persisting it. It does not describe size limits, latency, or auth requirements, but the privacy/write behavior is clearly conveyed.

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 paragraph with the trigger condition and privacy constraint front-loaded, and every clause carries information. The heavy symbolic notation (🔵-quotes, rule 0) slightly reduces scannability but does not waste space.

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 export tool with no output schema, the description covers output format, artifact contents, and the return-vs-save contract adequately. The main remaining gap is the untyped nested `session` parameter, which matters given the nested object.

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% for 3 parameters (one nested object), so the description must compensate. It implies `surface` (md default | html) and references abstentions (mapping to `include_abstentions`), but the nested `session` object's expected shape remains entirely undocumented 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?

States a specific verb (exports/returns) and resource (a shareable session proof artifact), and enumerates the artifact's content flow (question → advisors → quotes → synthesis → abstentions panel). It is clear what the tool produces, though it never names or distinguishes itself from the nearby render_session sibling.

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

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

Explicitly states the trigger condition — only on EXPLICIT user request ('по ЯВНОМУ запросу юзера — правило 0') — which is strong when-to-use guidance. It stops short of naming alternatives (e.g. render_session, proof_card) for the non-explicit case.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: verification is centralized on the SERVER (workers do not certify), divergence is preserved rather than best-of-N collapsing, model identity is retained, and a fallback path plus verdict values are given. It still omits auth/permission needs and side effects on session state.

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

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

It is compact and front-loads the verb, but reads as telegraphic fragments with heavy jargon (🔵, best-of-N, host_single_brain) crammed into one run-on block, which reduces legibility.

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

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

For a no-annotation, no-output-schema tool the description covers behavior, fallback, and verdict outcomes reasonably, but it leaves the sole input undocumented and does not clarify return shape beyond the verdict labels.

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% and the single required parameter (session_id) is never mentioned in the description, so the agent gets no semantics for the one input it must supply. The description's detail is entirely about behavior, not parameters.

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

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

States a concrete verb and resource ('Собрать совет' / assemble the council) and describes the operation's substance: grouping candidates by role, server-side citation verification, preserving divergence. It is distinguishable from siblings like seed_council or council_verdict, though it never names an alternative explicitly.

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

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

There is no statement of when to use this tool versus the many federation_* and council_* siblings. The only conditional mentioned ('Пустая роль → host_single_brain') is an internal edge-case behavior, not guidance on tool selection.

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

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

With no annotations, the description carries the full burden and does disclose concrete behavior: it kills worker processes plus their CLI children and cleans the registry, and it is flagged МУТИРУЮЩИЙ. It does not say whether cancellation is reversible, what happens if no workers are running, or what permissions are needed, 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 compact clauses: the operation and its effects come first, the mutating/user-request caveat second. Every phrase adds signal, though the parenthetical '(передумал, квота горит)' is more color than specification.

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 single-parameter, no-output-schema, no-annotation mutation tool, the description covers purpose, counterpart, destructive effects, and trigger context. The remaining gaps (return value, no-op behavior, auth) are modest but real given nothing structured carries them.

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% and the single session_id parameter has no schema description. The description implies session scope through 'сессии' and the reference to federation_run_subscriptions, but never states that session_id identifies the session whose workers are being stopped, so the mapping is inferable rather than stated.

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 (остановить фоновых подписочных воркеров сессии) and explicitly names the sibling that creates them (federation_run_subscriptions), so an agent can distinguish cancel from run without opening either schema. The added detail (гасит процессы вместе с CLI-детьми и чистит реестр) sharpens what 'cancel' actually means.

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 the trigger context explicitly: 'по просьбе юзера (передумал, квота горит)', i.e. use when the user changes their mind or is burning quota. It does not name a preferred alternative (e.g. subscriptions_status for inspection-only) or state when NOT to use it, so it stops short of 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?

With no annotations, the description carries the full burden and does disclose two real behavioral traits: the call blocks until timeout, and it returns either a structured brief {task_id, claim_token, role, advisor_dir, question} or an empty result. The claim_token strongly implies an exclusive lease. It omits auth requirements, retry/backoff semantics, and what an empty result should trigger.

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 dense sentences front-loaded with the core action, followed by the return shape and the next-step instruction. Arrow notation keeps it compact, though the telegraphic style sacrifices some readability.

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 describing the return payload is valuable and the description does it. But for a 3-parameter blocking worker-loop tool with zero annotation coverage and 0% schema descriptions, the missing parameter meanings and failure/empty handling leave meaningful 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 0% and the description never explains worker_id, roles, or timeout individually. 'Blocking until timeout' hints at the timeout parameter's effect, but the required worker_id and the roles filter are left entirely to the schema's type declarations, so the description does not compensate for the coverage gap.

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

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

The description names a specific verb and resource: the executor claims a role-task ('Исполнитель забирает роль-таск'), and it distinguishes this from the downstream federation_submit that follows. It is clearly a claim/lease operation rather than the submit, assemble, or poll siblings. The non-English text is a minor accessibility cost but the purpose is 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?

It implies a workflow: claim a task, play advisor_dir on your own model, cite quotes, then call federation_submit. That sequencing gives usable context, but it never states when NOT to use this tool, nor contrasts it with close siblings like federation_poll or federation_open. Usage is inferable but not 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?

With no annotations, the description carries the full burden and it does disclose one important behavioral trait: a stale response means the task has already been reassigned. However, it omits lease duration, heartbeat cadence, and what happens if heartbeats stop, leaving meaningful gaps for a stateful operation.

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 terse fragments with no filler; the core action is front-loaded and the stale condition is appended as a useful caveat. Efficient for the amount of information conveyed.

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

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

For a simple three-string heartbeat with no output schema and no annotations, the description covers the essence (what it does, what stale means). It is adequate but leaves renewal semantics and failure modes unstated.

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

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

Schema description coverage is 0%, so the description is expected to compensate, but it only repeats the parameter names in parentheses without explaining what task_id, worker_id, or claim_token represent. The claim_token is implicitly framed as a lease claim, which is a small gain, but per-parameter meaning is essentially absent.

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 verb (продлевает/extends) and resource (lease роль-таска), and lists the three identifiers involved, so an agent can distinguish it from federation_claim, federation_submit, and federation_poll. It is clear but does not explicitly contrast itself against those siblings.

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

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

"пока играет роль" (while playing the role) implies the tool is called repeatedly during task execution, giving implicit usage context. There is no explicit when-to-use/when-not guidance or named alternative, so the agent must infer the timing.

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 full disclosure burden. It adds real context: state is persisted locally in .consilium/ and executors run roles on their own models, which tells the agent this is a stateful, multi-model orchestration entry point. It still omits lifecycle, permissions, and whether openings are idempotent or reversible.

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 with the role/resource, and the plan structure is embedded compactly. It is dense and jargon-heavy with parentheticals, but every clause carries information and nothing is redundant padding.

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 coordinator tool sitting in a large async workflow (claim, submit, heartbeat, poll, cancel), the description says nothing about the session lifecycle, how opened sessions are consumed by sibling tools, or what a caller gets back. Combined with 0% param coverage and no output schema, meaningful gaps remain.

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%, so the description must compensate. It does document the nested shape of the 'plan' parameter ({role, advisor_dir, question, replicas?}), which the bare array schema does not, and 'replicas' maps to the N replicas / replicas_default concepts. But session_id is never explained, so compensation is only partial.

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

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

States a specific action (queue a role plan into N replicas as a multi-brain council coordinator) plus the resource (federation council), which an agent can distinguish from siblings like federation_claim or federation_assemble. It does not name a sibling explicitly, so it stops short of a 5.

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

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

The closing note 'Personal/attended (optional multi-brain mode)' hints at the usage context, implying this is the attended/personal entry point. However, there is no explicit when-to-use vs alternatives guidance and no reference to the surrounding federation_claim/submit/poll workflow, leaving usage largely 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?

With no annotations, the description carries the full burden, but it usefully discloses the returned counters (pending/claimed/done/dead), implying a read-only polling operation. It stops short of stating side effects, whether it is safe/idempotent, or any rate/polling cadence for a tool literally named 'poll'.

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 compact sentences that front-load the status/counters and then the workflow. No redundancy or 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?

For a single-parameter polling tool with no output schema and no annotations, the description covers the essential value (returned counters) and the orchestration context. The only real gap is the undocumented session_id, which slightly undercuts completeness.

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 description never mentions session_id at all, so neither the schema nor the description explains where the id comes from or its format. With a required, undocumented parameter the description fails to compensate for the coverage gap.

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

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

The description names a specific resource (federation session) and output (pending/claimed/done/dead counters), which is more informative than a bare 'poll'. However it does not explicitly distinguish this status tool from status-like siblings (e.g. federation_heartbeat, loop_status), leaving differentiation to inference.

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

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

It gives explicit when-to-use ('Опрашивай, пока роли набирают кандидатов') and names the concrete follow-up alternative ('затем federation_assemble'), so the agent knows both when to call it and what the next step is. Nothing is left implicit.

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

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

No annotations are provided, so the description carries the full burden and does so well: it declares the tool is MUTATING + EGRESS, that the question is sent to subscription providers and quota is spent, that it runs as a background worker, and that it answers immediately (async). This is the critical side-effect/cost disclosure an agent needs before calling.

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?

Information-dense and front-loaded with the core action, then the consent/cost constraint, then workflow. Almost every clause earns its place, though the run-on style and mixed purpose/behavior content make it slightly harder to scan than it could be.

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 no annotations, no output schema, a nested 'models' object, and 0% schema coverage, the description covers behavior and workflow well but leaves genuine gaps: it does not explain how roles/models should be structured, and return-shape expectations are only loosely implied by 'answers immediately'. Adequate but not complete for a tool of this complexity.

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% for 4 parameters, so the description must compensate. It indirectly illuminates backends (claude/codex/kimi) and roles ('plays each role') and hints at models ('with its model'), but never defines the format or meaning of the roles/models inputs or the session_id, and the nested 'models' object is left 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 a specific verb+resource: 'play an OPEN federation session with the user's subscriptions' via a background worker, with each subscription (claude/codex/kimi) playing each role. It distinguishes itself from siblings by explicitly naming the federation_open prerequisite, the poll loop, and federation_assemble. Dense, but an agent can tell what this does versus federation_open/claim/submit.

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

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

Explicit when-to-use condition: ONLY with explicit user consent, naming the subscriptions. It also gives the surrounding workflow (replicas in federation_open = number of subscriptions; then federation_poll until pending=0/claimed=0, then federation_assemble), routing the agent to the right siblings at the right time.

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

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

With no annotations the description carries the full burden, and it does disclose meaningful behavior: server-side validation of size/types/control-chars, that markers must NOT be added (assemble does the check), and that a stale claim_token causes rejection. It stops short of describing success behavior, idempotency, or the response shape.

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 dense sentences, front-loaded with the core action, using capitalization to emphasize RAW and the marker prohibition. No filler, though the telegraphic style and jargon make it slightly harder to parse than a plain statement would be.

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

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

For a 5-required-param, nested-object mutation with no annotations and no output schema, the description covers the submission semantics and validation/rejection behavior but omits the identity params (task_id, worker_id) and any success/return expectations, leaving 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 0% and all 5 params are undocumented in the schema, so the description must compensate. It explains candidate structure and worker_model, and mentions claim_token's stale-rejection semantics, but leaves task_id and worker_id entirely 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?

The description states a specific verb and resource: the executor ('Исполнитель') submits a RAW candidate. It names the candidate shape {argument, quotes:[{text}]} and ties the action to the sibling concepts of claim_token and assemble, so an agent can place it in the federation workflow.

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 implies the submit must follow a claim and warns 'stale claim_token → отклонён' and 'маркеры НЕ ставь — сервер сверит на assemble', which is real routing guidance. However, it never explicitly contrasts this with siblings like federation_assemble or federation_claim or states the full preconditions for calling it.

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 disclosure burden. It does add real behavioral information beyond the schema: the three outcome classes (verbatim→🔵, partial→🟢, not-found→🟡) and a strict rule that 🔵 may only be applied when this tool returns 🔵. But it omits permissions, whether the corpus is read-only, and what P1/P2 and S1/S2 actually mean, leaving the disclosure opaque.

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 packed sentences with the core purpose front-loaded and zero filler. The density is a virtue, though the emoji/code shorthand makes it cryptic rather than merely brief.

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

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

No output schema and no annotations, so the description must cover return semantics and prerequisites itself. It covers the three result categories but never defines the P1/P2 and S1/S2 codes, does not explain advisor_dir, and says nothing about the corpus corpus source or failure modes — a gap for a gate that governs downstream 🔵 marking.

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 compensate. It implicitly maps both parameters — 'цитата' for quote and 'корпус советника' for advisor_dir — which is partial compensation. It adds no format, path syntax, or case/whitespace-sensitivity guidance for a verbatim-match check where such details matter.

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: verify whether a quote is verbatim ('дословна ли цитата') within the advisor's corpus, and frames itself as a 'protocol-gate'. An agent can grasp the core operation. However, it does not distinguish itself from overlapping siblings like cite, atomic_grounding, governance_verify, or gate_verdict, and the 🔵/🟢/🟡 outcome codes (P1/P2, S1/S2) are unexplained jargon.

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

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

No statement of when to call this versus alternatives. The second sentence ('Помечать 🔵 ТОЛЬКО при 🔵 отсюда') is a downstream behavioral instruction about how to consume the result, not guidance on when this tool should be selected over cite or governance_verify.

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 that the server applies thresholds/markers in code, that ratings are logged, that ratings gate only relevance, and that inflation corrupts the loop. It omits what the successful return value looks like beyond the 🟡/0 failure marker.

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 paragraph that front-loads the phase, mode, and action before the constraints. Little waste, though the fail-closed clause repeats the fail-closed concept already implied by the threshold/validation statements.

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 nested-object, no-output-schema, no-annotation tool, it covers the essential contract: inputs, validation, server-side decisioning, logging, and failure behavior. Only the shape of a successful verdict is 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 coverage is only 33%, but the description compensates: it defines the ratings payload shape {id: 0-3}, the per-candidate requirement, and the origin of the nonce. advisor_dir is explained in the schema itself (must match the nonce's advisor).

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 action (phase-2 judging of 'cite', host mode) and a specific resource (relevance ratings submitted via a judgment_request nonce). It clearly positions itself as the second phase of the cite workflow, though it does not name an alternative sibling to route away from.

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

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

It states the trigger condition (you hold a nonce from judgment_request), the required coverage (ratings for EVERY candidate), and the failure condition (bad/expired/reused nonce or missing ratings → fail-closed). It does not explicitly name alternative tools, but the sequencing guidance 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?

With no annotations, the description carries the full burden. It does disclose meaningful behavior beyond the schema: the hash-chain mechanism, that substitution breaks the chain, and that output is a fingerprint-hash plus a tier histogram. It does not state whether the operation is read-only or mutating, permission requirements, or failure behavior, leaving real gaps for a no-annotation 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 with no filler; the integrity mechanism and the tamper consequence are front-loaded, followed by output and parameter guidance. Tightly sized for the tool's scope.

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

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

No output schema and no annotations, so the description is the only source of truth. It names the outputs (hash, tier histogram) and the accepted path forms, but omits what a failure/tamper result looks like and how it relates to sibling verification tools, leaving it only minimally 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 0% and the single 'path' parameter has no schema description, so the description must compensate. It does, by defining accepted inputs: an advisor/lens directory or a path to a .jsonl file, which is concrete guidance an agent could not get from 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?

States a specific verb+resource: it verifies corpus integrity via a 'Барсик hash-chain' and reports a fingerprint-hash plus tier histogram, which is far more than a restatement of the name. However, it does not differentiate itself from verification-family siblings such as catalog_verify, fidelity_check, or validate_manifest, so an agent cannot tell which verify tool to pick from the description alone.

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 text implies a tamper-detection use case ('подмена рвёт цепь') but never says when to run this versus catalog_verify, validate_manifest, or doctor, nor does it state prerequisites or when not to use it. Usage is left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses asynchronous/background execution over the network, the {job_id} return and required polling loop, and the failure semantics (0 posts = private/invalid/sandbox network block). It does not mention auth, rate limits, or how content lands in the corpus, keeping it short of a 5.

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

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

A single dense sentence with the core operation and target front-loaded, then the async contract, then the input format, then the error case. Every clause carries information; no filler. Slightly telegraphic but appropriately sized.

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 covers the essential contract: what it ingests, that it is async, how to poll, and what a zero-result means. The only gap is out_path semantics.

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%, so the description must compensate. It clarifies the handle format ('@name или name') but says nothing about out_path, leaving one of two parameters undocumented in both schema and description. Partial compensation.

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-by-implication and resource: 'Public Telegram channel → Princip's corpus'. The direction and target are clear, and it is unambiguous against siblings since it is the only ingestion-of-telegram tool. It loses a point only because the action is expressed via arrow notation rather than an explicit verb.

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?

Provides operational guidance: it is a background job, returns {job_id}, and instructs to poll job_status (a known sibling). It also gives the handle format. What is missing is any explicit 'use this when...' framing versus alternatives, but the tool is unique enough that this is minor.

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 discloses the return state machine: running | done (с result) | error (с error), telling the agent exactly what each response means. It omits poll cadence/backoff guidance, so it is strong but not exhaustive.

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 covering purpose, source, possible states, and the polling action, with zero 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?

For a simple read-only polling tool with no output schema, the description supplies the job origin, the state values, and the poll-until-done loop. Reasonably complete, though it leaves the result/error payload shapes only loosely implied.

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?

Parameter count is 1 with 0% schema description coverage, so the description must compensate — and it does by defining job_id as the id returned by build_advisor/seed_council/ingest_telegram, which the bare 'string' schema does not convey.

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 ('Статус фонового джоба по job_id') and names the exact producer tools (build_advisor/seed_council/ingest_telegram), which cleanly separates it from the many sibling *_status tools it could be confused with.

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 instructs the agent to poll until done ('Опрашивай, пока не done'), giving a clear usage pattern. It stops short of naming alternatives (e.g. loop_status/board_status) or stating when NOT to poll, so it lands just below the top.

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 disclosure burden. It adds useful output-shape information (raw data vs clickable widget vs standalone HTML), which is genuinely beyond the schema. But it says nothing about read-only nature, cost, or side effects of the widget path.

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-loads purpose in the first clause, then packs the surface variants into a compact pipe-delimited list. Every element earns its place; only the somewhat dense inline formatting keeps it from a 5.

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

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

With no output schema and no annotations, the description covers both the 'why/when' and the single parameter's valid values, which is sufficient for a zero-required-parameter listing tool. Minor gap: no note on what the data/shape of the returned recipes actually looks like.

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% and the single 'surface' param has no enum in the schema, so the description must compensate. It does: it enumerates all three values (data = raw recipes/default, widget = clickable HTML for show_widget in Cowork, html = self-contained fallback) and marks the default, which is exactly the missing semantics.

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

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

States a specific purpose: a menu of what the council can do, expressed in simple phrases. The verb 'list' plus the 'recipes' concept is clear from name+description together. It does not, however, distinguish itself from plausible siblings like explain_self or quote_of_day, 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?

Explicitly names the trigger conditions: show it when the user doesn't know what to ask, or asks 'what can you do / where do I start'. That is clear when-to-use guidance. No when-not-to-use or named alternative (e.g. explain_self) is given, so not 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?

With no annotations the description carries the full burden, and it does disclose meaningful behavior: the journals it self-reads, that zero pending yields a quiet {count:0}, and that it only emits a hint to close decisions rather than closing them (implying non-mutating). It omits permission/auth requirements and any note on whether session state is written.

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 paragraph that front-loads the argument-free mode before the ledger mode, so the highest-frequency path is read first. It is efficient but jargon-heavy (emoji, mixed Russian field names) and could be split for faster scanning.

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 dual-mode session-state tool with no annotations and no output schema, the description covers both invocation paths and sketches the return payloads, which is enough to call it correctly. Remaining gaps are minor: exact hint text, decision_id semantics, and behavior on malformed ledger entries.

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 compensate, and it does: the single ledger parameter is documented by shape [{decision_id,predicted,actual,endorsed}] and by effect (open/closed, prediction accuracy, share endorsed). That is more than the bare 'array' type in the schema, though field-level types and nullability remain undefined.

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 spells out two concrete behaviors: with no arguments it reads the principis.md and relationship.md journals and returns pending ⏳-decisions plus a hint; with a ledger it returns an open/closed summary plus prediction accuracy. That is a specific verb+resource pair, not a restatement of the name. It does not, however, distinguish itself from close-siblings like pending_outcomes or prediction_calibration, which appear to overlap with its two modes.

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 condition for each mode: no arguments = start of a new session, ledger supplied = summary mode. The agent knows which input selects which behavior. It stops short of naming alternatives or when-not to use it versus the many sibling outcome/calibration tools.

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

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

With no annotations, the description carries the full behavioral burden. It discloses one trait — the tool reflects rather than advises — but says nothing about determinism, cost, whether both arrays must be aligned, or what the report contains. For a 2-required-param analytical tool with zero annotation coverage, this leaves major 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 terse sentences, front-loaded with the core comparison before the disclaiming clause. Nothing is padded, though the compressed jargon edges toward cryptic rather than economical.

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 0% parameter documentation mean the description is the only source of truth, yet it omits return format and array element structure. The 'разрыв + дрейф' framing hints at the output but never says what metrics or form come back.

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 compensate. It does map the two params semantically: 'заявленные векторы (во времени)' corresponds to stated and 'одобренные выборы' to decisions, which helps an agent know what to supply. However, it never specifies the element shape of either array (vectors as numbers? choice records?), so half the semantics remain guesswork.

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 conveys a specific concept — comparing stated vectors/values over time against approved decisions to surface a 'you say X, you choose Y' gap plus vector drift. The verb 'отражает' (reflects/mirrors) is metaphorical rather than operational, so the concrete action is inferable but not crisply stated, and no sibling (e.g. fidelity_check, validate_decision_map, stability) is referenced.

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?

'Не советует, отражает' establishes a negative boundary (this is not an advisory tool), which is a faint usage cue. There is no guidance on when to reach for this versus fidelity_check, stability, or prediction_calibration, and no prerequisites or input expectations 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?

With no annotations, the description carries the full burden. It does disclose the key branch (starts serve only if the binary exists; otherwise falls back to manual) and the next step, but says nothing about idempotency, safety of repeated calls, or the shape of the response.

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 the primary action and followed by the caveat and next step. Efficient, though 'FULL-тир' is unexplained shorthand.

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-param, no-output-schema tool the description covers the main behavior and failure path, but leaves 'FULL tier' undefined and does not state prerequisites or how to verify the result afterward.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing in the schema for the description to compensate for.

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: it brings up the FULL tier by starting `ollama serve` when the binary exists. It also distinguishes itself from the `ollama_pull` sibling by naming it as the follow-up step, though the jargon 'FULL-тир' is never defined.

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 sequencing hint ('Потом ollama_pull') and a fallback condition (first binary install is manual, will return to manual), but there is no explicit when-to-use vs. when-not guidance and no mention of the `ollama_status` alternative for checking state.

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, but it does disclose two genuinely useful behavioral facts: the operation is idempotent and the default model is bge-m3. It omits other important traits such as download size/time expectations, network requirements, and failure behavior, so it is helpful but incomplete.

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

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

Two short sentences with zero padding; the action and its target are front-loaded, followed by the two most useful qualifiers (idempotent, default model). Tight and well-ordered.

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

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

For a one-parameter, no-annotation tool with no output schema, the description covers the core action and default but leaves out the return/result behavior and any prerequisite detail about the running ollama instance. Adequate, not complete.

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

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

The single parameter has 0% schema description coverage, so the description must compensate. It does supply the default value ('default bge-m3'), which the schema does not show, but it says nothing about accepted model name syntax or how the parameter interacts with the idempotency claim.

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 verb and resource ('Скачать модель эмбеддингов' = download an embedding model) plus the target ('в запущенный ollama'), so an agent knows exactly what happens. It does not, however, differentiate itself from the close siblings ollama_ensure and ollama_status, which is the only thing keeping this from a 5.

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

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

Usage is only implied: the tool is for getting an embedding model into a running ollama. There is no explicit when-to-use or when-not, and no routing to the obvious alternatives (ollama_ensure, ollama_status) despite their presence as siblings.

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

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

With no annotations, the description carries the full behavioral burden. 'Без падений' hints at a stable, non-destructive read but it never states read-only semantics, side effects, or what the result looks like. It doesn't explain what a passing vs. failing state means or what fields it 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?

A single compact sentence with the subject (FULL-tier state) front-loaded and the two checked conditions enumerated. Zero waste.

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

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

For a simple health-check tool the description covers what is being examined, but without an output schema it should at least imply the shape of the answer (a boolean running flag, a download flag) or point to the ensure/pull tools for remediation. Adequate but with clear gaps.

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

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

There are zero parameters, so the baseline of 4 applies. No parameter meaning needs to be conveyed and none is missing.

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 resource and scope: the status of the FULL tier, checking whether ollama is running and whether bge-m3 is downloaded. This clearly distinguishes a read-out from the sibling write-oriented tools ollama_ensure and ollama_pull, though it does not name them explicitly.

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

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

No when-to-use guidance is given, and the description never references the obvious alternatives ollama_ensure or ollama_pull (which are the remediation actions for whatever this status reports). The agent must infer the check-then-fix workflow entirely on its own.

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

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

No annotations are provided, so the description carries the full burden. It does not state whether this is a read-only surfacing operation or a mutation, what the required journal_text must contain, or what form the surfaced outcomes take. The 'without this the loop never accumulates' line hints at consequence but gives no operational detail.

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

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

Two short sentences with no filler, and the core scope (unclosed decisions from the journal) is front-loaded before the motivational tail. The only cost is the opaque 'U1' tag, which consumes space without informing an agent.

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

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

For a tool whose sole input is an undocumented string and which has no output schema, the description should at minimum explain what journal_text expects and roughly what is returned. Neither is covered, so an agent cannot confidently construct a call.

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

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

One required parameter with 0% schema description coverage. The description mentions 'из журнала' but never clarifies whether journal_text is raw journal content, a path, or an identifier, nor what format it expects. The schema provides no help, so this gap is real.

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 does identify a concrete action: surface unclosed decisions (⏳) from the journal. However, the framing 'Сёрфейсер петли U1' is undefined internal jargon that doesn't map to a recognizable verb+resource, and nothing distinguishes it from siblings like loop_status, close_decision_card, or calibrated_consult_journal. Purpose is inferable but murky.

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

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

The phrase '«вернись и закрой»' and the warning that outcomes otherwise 'hang forever' imply a use case, but there is no explicit when-to-use guidance and no named alternative. An agent is left to guess how this relates to close_decision_card or decision_record.

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 full behavioral burden. It does add real value: input source (closed cards), grouping by kind+unit, the warning that small N is noisy and only trustworthy=true groups should be shown, and the interpretive note that forecast/fact divergence reflects model calibration rather than failure. It does not, however, disclose permissions, cost, rate limits, or whether any state is mutated (a read-only nature is only implied).

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?

Dense and front-loaded: the core action leads, followed by metric details, output filtering, and interpretation. Every clause carries information, though the sentence is long and semicolon-chained rather than cleanly broken.

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, no parameters, and no annotations, the description is the whole specification and it covers what is computed, how results are grouped, how to present them, and how to interpret them. Minor gaps remain around access prerequisites and whether the operation is purely read-only.

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 the schema has nothing to document and the baseline of 4 applies. The description adds no parameter meaning because none exists.

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

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

States a precise verb+resource (computes numerical calibration of forecasts from closed Decision Cards) and enumerates the metrics produced (Brier/log score for events, MAE/interval coverage for quantities). It also carves out its domain by contrasting with 'подачи', but never names the sibling tools it differs from (e.g. calibrate, calibrated_consult_journal), so sibling differentiation is implied rather than explicit.

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

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

Implicitly scopes usage to 'closed Decision Card' inputs and gives a presentation rule (show only trustworthy=true groups), which tells the agent how to use the result. But it never states when to choose this over the many sibling calibration/consult/journal tools, nor any when-not condition or prerequisite.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the return includes edge cases, and a 'trustworthy' flag is set to False when there is no hit history (anti-theater guard). It does not cover permissions, determinism, or how the ledger influences trust, leaving real 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?

A single dense sentence with the purpose front-loaded and no filler, which is appropriately compact for a computational tool. The terseness comes at the cost of some missing detail rather than being wasteful.

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

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

For a tool with no annotations, no output schema, and 0% parameter coverage, the description does mention outputs (expected outcome, edge cases) and the trust flag. However the ledger input and the tool's relationship to adjacent decision/prediction tools remain undefined, so it is only partially complete.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully documents the shape of the scenarios entries ([{label,value,prob}]), but the 'ledger' parameter is never mentioned, so compensation is only partial.

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 function: it takes scenarios [{label,value,prob}] and produces an expected outcome plus edge cases, which is a concrete verb+resource transformation. It clearly conveys what the tool computes, though it does not name or contrast any sibling tool.

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

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

There is no statement of when to use this tool versus alternatives such as prediction_calibration, situation_stress_test, or the calibrated_consult family. The only conditional note (trustworthy=False without hit history) is a behavioral property, not routing 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?

With no annotations the description carries the full burden and does well: it discloses the fail-closed policy, the exact failure return shape ({verified:false, content:null}), and the verification criterion (verbatim in the advisor's P1/P2 corpus). It omits permissions and success-path output shape, but the core behavioral traits are explicit.

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 with the purpose, and the fail-closed clause plus the parameter format each earn their place. The closing phrase about 'the essence is torn' is flavor text that could be cut, but overall it is dense rather than bloated.

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-parameter tool with no output schema and no annotations, the description supplies the failure return shape and the verification precondition. The success-path card content is only loosely specified, but nothing critical 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 coverage is 0%, so the description must compensate. It explains advisor_dir's expected format (advisors/{name} or lenses/{name}), which is genuinely useful, but says nothing about the quote parameter beyond what its name implies. Partial compensation for the coverage gap.

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

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

The description states a specific verb and resource: it produces a self-contained HTML card for ONE quote with its source and a verification badge. An agent can tell what artifact it creates. It does not, however, differentiate itself from related siblings such as cite, fidelity_check, or atomic_grounding.

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 describes the fail-closed condition (non-verbatim quote yields no card), which is a behavior rather than usage guidance. There is no statement of when to prefer this tool over cite or fidelity_check, nor any prerequisite or exclusion 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?

With no annotations, the description carries the burden and does so well: it discloses deterministic-by-date behavior that is stable within the day, the advisor_dir fallback to the first collected advisor, and that a missing P1/P2 quote yields a {note} rather than fabricated generic wisdom. Auth/rate-limit details are absent, but for a pull-only read tool this is solid disclosure.

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?

Information-dense and front-loaded with the core purpose, but the single packed paragraph relies on jargon (P1/P2, 🔵-verbatim, retention hook) and mixes purpose, behavior, and failure mode without structure, hurting scannability.

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-optional-param tool with no output schema, the description covers what an agent needs: what is returned (quote + source), the fallback shape ({note}), and default resolution of advisor_dir. Only the date parameter's expected format is left unaddressed.

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%, so the description must compensate. It explains advisor_dir well ('optional, absent → first collected') and establishes that date drives determinism, but adds no format/type detail for the date parameter (e.g. expected date format), leaving half the parameter surface only loosely covered.

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

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

States a concrete verb+resource: returns one verbatim quote of the day from the advisor's P1/P2 corpus plus its source. 'Retention hook (PULL-ONLY, on demand)' frames the intent, though sibling differentiation is only implicit — the adjacent retrieve/cite tools are not named or contrasted.

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?

'PULL-ONLY, по запросу' (on demand) implies the agent should call it rather than expect a push, and 'retention hook' hints at the surface use. But there is no explicit when-to-use vs. when-not, and no alternative tool is named for related retrieval needs.

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 and does so well: it discloses that rendering additionally validates attribution, downgrading unverifiable blue/green quotes to violations and downgrading 'blue' on S-tier comment quotes to green, and warns against moving quotes between advisors. It stops short of describing the exact return payload beyond `content` and the failure/degradation modes.

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 critical directive is correctly front-loaded, but the paragraph crams sequencing, surface routing, gate logic, attribution-validation rules, field-name guidance and a code reference into run-on sentences with heavy parenthetical nesting. Much of it earns its place, yet the density hurts scannability.

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 nested 4-param mutation-style tool with no output schema and no annotations, the description covers the workflow, parameter conventions and validation side effects an agent needs. Gaps remain around the unexplained `kind` parameter and the precise shape of the returned `content`.

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

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

Schema description coverage is only 25%, so the description must compensate, and it largely does: it enumerates exact canon field names for `session`, lists accepted aliases, explains the `surface` values and the `depth` default. The `kind` enum (session/opening) is never explained in either the description or schema, leaving one parameter undocumented.

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 (canon-объект заседания) and frames it as the mandatory final step of a council session, which distinguishes it from siblings like council_verdict, gate_verdict and export_session. The purpose is clear but delivered inside a dense procedural paragraph rather than a clean one-liner.

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

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

Explicit sequencing (call it as the LAST action, then feed `content` to mcp__visualize__show_widget, don't write the verdict in prose), explicit surface selection rules with defaults and fallbacks (widget default, md only if show_widget unavailable, html fallback), and a stated depth default. When-to-use and which alternative to pick are fully spelled out.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses only that output is 'clean context'. It says nothing about read-only vs mutation, permissions, rate limits, result ordering, or the shape of the returned passages.

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 compact sentence with the resource front-loaded and no filler, which is efficient. The brevity is not wasteful, though it contributes to the overall thinness rather than being a structural flaw.

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-parameter retrieval tool with no annotations, no output schema, a generic name, and 33% parameter coverage, the description is far too sparse. It never explains the return format, result count behavior implied by top_k, or how it relates to sibling retrieval tools.

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

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

Schema description coverage is only 33%: the advisor_dir parameter is well documented in the schema (name-or-path plus explicit error on unknown), but 'query' and 'top_k' are undocumented in both schema and description. The description adds no meaning for those two parameters, failing to compensate for the coverage gap.

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

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

The description names a concrete output (grounded passages from the advisor's corpus) mapped to a query, which is more specific than the generic name 'retrieve'. However, it does not distinguish itself from plausible siblings like catalog_search, atomic_grounding, or cite, so an agent cannot tell them apart from the text alone.

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 parenthetical '(чистый контекст для ризонинга)' implies the tool feeds a reasoning step, but there is no explicit when-to-use, no when-not-to-use, and no named alternative among the many retrieval-adjacent siblings. Guidance is left almost entirely to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses determinism (fixed seed, same seed → same result), zero LLM involvement, fail-closed behavior on invalid input, and the full set of returned metrics. It omits cost/latency expectations and what exactly the 'errors' payload 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?

The core purpose is front-loaded, which is good, but the single dense sentence crams computation semantics, failure handling, return fields, and emoji/label rendering rules together. The presentation rules are useful but read as operator instructions that compete with the tool's purpose for attention.

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 enumerating the return metrics (mean/median/p10/p90, P(best), expected_regret, tornado, top_uncertainties, label_text) and the invalid-map error path. Only the undocumented 'n' parameter and any performance expectations remain gaps.

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

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

Schema description coverage is 0% and the schema documents nothing, so the description must compensate. It only partially does: it establishes that 'map' must be a valid decision map and alludes to the seed being fixed, but 'n' is never mentioned and the seed's relationship to the parameter (is it settable, or forced?) is ambiguous rather than explained.

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 verb and resource: a deterministic Monte Carlo run over a valid decision map, and stresses that the computation is code-driven, not LLM-driven. That clearly separates it from siblings like validate_decision_map or save_decision_map, though it never names those siblings explicitly.

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

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

It states the prerequisite (the map must be VALID), the failure path (invalid map → refusal with errors, fail-closed), and how the output should be presented (only alongside the 📐 frame, never mixed with other labels). It gives clear context but does not name an alternative tool or route the agent to validate_decision_map first.

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 labels itself MUTATING, requires user consent, constrains invocation to once after a choice, and states the return (card_id + journal_line with anchor). It stops short of failure modes (e.g. what happens on a duplicate or missing map) and the exact side effects beyond writing the artifact.

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 action and artifact path are front-loaded, but the rest is a dense run-on that interleaves purpose, field semantics, invocation rules and sibling routing without any separation, making it harder to scan than it needs to be.

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 16-parameter, annotation-less, output-schema-less tool the description covers purpose, side-effect profile, output and alternatives well, yet the required parameter 'map' is never explained and nine parameters remain undescribed, leaving a real gap for correct invocation.

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

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

Schema description coverage is 0% across 16 parameters, so the description must compensate. It explains chosen_option (id from map.options or null), review_date / review_horizon_days, and the conceptual content of the card, but leaves n, form, seed, owner, map_path, statement, session_id, reversibility and situation_ref entirely undocumented, so it only partially covers the surface.

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

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

States a concrete verb and artifact: writes a Decision Card to decisions/<date>-<slug>.card.json capturing the decision moment, with the record's contents enumerated (UUID, prediction contract, assumptions, success criterion, review date). It is clearly distinguishable from save_decision_map (the map) and close_decision_card (the outcome).

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

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

Explicit when-to-use and when-not: 'call ONLY with user consent (Rule 0), ONCE after the user has chosen an option', plus the prerequisites (chosen_option id or null for defer; a needed review_date or review_horizon_days). It also routes to the sibling tools by function: close_decision_card for closing the outcome and prediction_calibration for accuracy.

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 substantial work: it flags the tool as MUTATING, states the consent requirement, describes the side effect (writes a JSON file), and describes the return value (path + journal_line). It omits overwrite behavior and permission details, keeping it short of a 5.

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

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

Front-loaded with the core action and artifact path, then the mutation/consent warning, then the return value. Dense but every clause adds operational value; slightly heavy on parentheticals.

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?

It covers the side effect, consent gate, and return value well, but with no annotations, no output schema, and two fully undocumented parameters, an agent still lacks enough to call it reliably without guessing at n and seed.

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%, so the description must compensate for four parameters. It explains the slug format (latin/digits/hyphens) and what map contains, but n and seed are entirely undocumented, leaving half the parameters ambiguous.

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 verb (save) and resource (the decision map) and even specifies the exact artifact path decisions/<date>-<slug>.json plus its contents (map + MK-summary with predicted). This lets an agent distinguish it from save_decision_card/validate_decision_map without opening any 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 gives an explicit precondition and sequencing rule: call ONLY with the user's explicit consent and propose it ONCE after calculation. That is strong when-to-use guidance, though it never names a sibling alternative to compare against.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return type (markdown) and one non-obvious behavior (missing vector leaves a deliberate gap rather than failing), and it transfers responsibility to the caller to write the file. It does not state where the file is written, whether an existing principis.md is overwritten, or what validation the answers must pass.

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

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

Two short sentences with no filler; the action is front-loaded and the conditional rule and return contract follow compactly. The only friction is the terse 'запиши его', which assumes context about where the markdown belongs.

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

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

For a one-parameter scaffolding tool with no annotations and no output schema, the description covers the essential workflow (consumes answers, returns markdown, caller persists it). It still leaves the file destination, overwrite semantics, and per-key expectations unspecified, which an agent would need to call it 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?

There is a single nested 'answers' object with 0% schema description coverage, so the schema alone conveys nothing. The description compensates by naming the five expected keys, which is real added value, but gives no types, allowed values, or format for any of them (e.g., what interface_mode or temperament accept).

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 artifact: assemble principis.md from the user's answers, and enumerates exactly which answer keys feed it (who/vector/interface_mode/temperament/not_known). An agent knows what it produces. It does not compare itself to any sibling, and 'principis' is unexplained jargon, but the action itself is 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?

Usage is implied by the input requirement (must have user answers) and there is one conditional rule ('вектор не дан → пробел держим живым'), plus the instruction to persist the output. There is no explicit when-not-to-use and no named alternative among the many siblings, so the agent must infer the trigger 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?

With no annotations, the description carries the full burden and does disclose a lot: it is a BACKGROUND JOB, it is long-running, it requires network access to Gutenberg, it returns {job_id} immediately, it must be polled via job_status, and it is idempotent for already-assembled data. Only failure/timeout behavior and what exactly gets created are left unstated.

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?

Dense but front-loaded: the resource is named first, then the cold-start condition, then the async contract (job_id + poll), then idempotency. Every clause carries information, though the telegraphic jargon style ('PD-мудрецов') is slightly cryptic.

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 must explain return behavior — and it does, stating that it immediately returns {job_id} and that job_status is the polling mechanism. Combined with the zero-parameter schema, an agent has what it needs to invoke and follow up 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?

The tool takes zero parameters, so the baseline is 4; there are no argument semantics to add beyond what the empty schema already conveys. The description does not need to explain any inputs.

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: assemble a starting council of PD sages (Aurelius + Epictetus) from scratch, cold start without a shell. That is concrete and distinguishable in intent from generic federation/scaffold siblings, though it never explicitly names an alternative tool to route away from.

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

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

It implies when to use it ('холодный старт без шелла' — cold start, no shell) and tells the agent to poll job_status afterwards, plus notes idempotency for already-assembled state. There is no explicit when-not guidance or named sibling alternative (e.g., setup_full, scaffold_principis), so usage is only implied.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the no-silent-install policy, the OS-instruction fallback, the bge-m3 auto-pull side effect gated on consent, that a final status plus steps are returned, and the dry-run semantics of consent=false. This is meaningful side-effect and safety disclosure.

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

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

A single dense sentence with the outcome front-loaded and the consent branch last. Every clause adds information; only the acronym-heavy phrasing costs a little readability.

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 and no output schema, but the description covers the operation's effects, safety constraints, the consent gate, and the return shape (steps + final status). For a one-parameter setup orchestrator, this is close to sufficient.

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

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

One parameter at 0% schema coverage, so the description must compensate. It does explain the consent=false branch precisely, but does not clarify what consent=true enables beyond the auto-pull already mentioned (e.g. whether it proceeds with the actual tier setup).

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

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

States a specific action (bring up the FULL/semantic tier) and enumerates what it does: returns OS-specific instructions instead of silently installing system ollama, auto-pulls bge-m3, returns steps + final status. The 'FULL-тир (семантика)' framing is jargon, and it doesn't explicitly distinguish itself from siblings like ollama_ensure/ollama_pull, but the verb+resource 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?

Gives one useful conditional: consent=false yields plan only, no execution. However, it never states when to choose this orchestration tool over the sibling primitives it wraps (ollama_ensure, ollama_pull, ollama_status), leaving the agent to infer the relationship.

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

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

With no annotations, the description carries the full burden. It does disclose the honesty/grounding constraint ('fabrication (grounded:false) doesn't win') and the shape of the returned verdict, which is genuine behavioral context. It says nothing about side effects, cost, or whether the call is read-only, so significant gaps remain.

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?

Dense and front-loaded in a single compact block, with the action first and parameter domains trailing. Every clause carries information, though the telegraphic style slightly hurts readability.

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

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

For a tool taking a nested, structurally undocumented tree object with no output schema and no annotations, the description is on the thin side. It covers return values and enum domains but leaves the tree's expected shape and the operating context underspecified.

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%, so the description is the only source of parameter meaning, and it does substantial work: it defines the opponent domain {self,person,world}, the stance domain {competitive,cooperative}, and characterizes tree as a tree of moves for you and the opponent. The internal structure of the tree object is still left 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 a concrete verb and resource: evaluate a move tree (you + opponent) and return an evaluation, main line, and verdict. An agent can grasp the operation without opening the schema. It does not, however, distinguish itself from close siblings like situation_stress_test or capture_situation.

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, and no alternatives named among the many decision-analysis siblings. The enum hints for opponent/stance are parameter facts, not usage routing.

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