Keel — Hyperliquid trading strategies

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

Annotations already cover readOnlyHint, idempotentHint, destructiveHint, so the description adds value by specifying the dual list/detail behavior based on account_id and listing the returned fields. It aligns with annotations and provides useful contextual behavior beyond the structured metadata.

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

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

The description is front-loaded with the core purpose and fields, then explains the parameter-based behavior, then gives exclusions. Every sentence contributes value—no fluff or repetition. It is compact yet complete.

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

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

With an output schema present and annotations covering safety, the description covers usage, parameter behavior, exclusions, and field summary. It omits pagination details but those are in the schema. It is sufficient for correct invocation without being overlong.

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

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

Schema description coverage is 100%, so each parameter is already documented. The description restates the account_id behavior (list vs detail) but adds no new meaning for limit or cursor. It provides marginal added value over the schema, hence the baseline 3.

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

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

States the exact resource and operation: 'List your Hyperliquid accounts' with the enumeration fields, and clearly distinguishes from deploy/authorization siblings. The verb 'list' plus the scope 'accounts' is unambiguous and does not repeat the title verbatim.

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

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

Explicitly tells the agent when to use the tool ('to find the account you need') and what NOT to use it for (authorization, deployment), naming the alternative keel_live_deploy directly. This leaves no ambiguity about 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description is not obligated to restate the safety profile — and it does not contradict them (description's 'Read' aligns with readOnlyHint). The description adds genuinely useful context beyond the annotations: that args/result_ref metadata is best-effort and may be empty, meaning the agent should not treat returned data as replay-safe. This disclosure of data-reliability limitations is valuable behavioral transparency that structured fields do not provide.

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 in the first clause, and each subsequent sentence carries essential operational guidance (the Do NOT clauses, the best-effort caveat, the alternative routing). It is longer than a minimal description, but the length is justified by the important reliability caveats and usage exclusions. Slightly verbose for a single-parameter tool, but no wasted 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?

The tool is simple (one optional param, zero required) and the description covers everything an agent needs: what the audit trail contains, why to use it, its reliability limits, and which alternatives to reach for when the audit trail is not the right path. An output schema exists to document the return structure, so not describing it in prose is fine. Nothing an agent needs to call it correctly or interpret its results is missing.

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

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

Schema description coverage is 100% — the 'n' parameter is fully documented (default 20, 'Max events to return', 'Server clamps to 1..100'). The description references 'most recent N audit events' which aligns with the parameter but adds no syntax or semantics beyond what the schema already states. With full schema coverage, the baseline 3 is appropriate.

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

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

The description states a specific verb ('Read'), a clear resource ('most recent N audit events for the current org'), and an explicit purpose ('the agent's own trail for self-debugging and recovery'). The tool is naturally distinct from all siblings — none of the 38 sibling tools are audit-related — so the description's framing of it as the org's action trail makes selection unambiguous.

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

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

The description gives explicit when-to-use ('see what was just done', 'recover the run id of a backtest you lost track of'), explicit when-not-to-use ('Do NOT use to mutate state', 'Do NOT use to fetch full backtest results'), and names the correct alternatives (call the relevant outcome tool directly; read keel://backtest/<id>/results after locating the run id). It also warns against assuming args/result_ref completeness. This is exemplary usage 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?

The description adds substantial behavior beyond annotations: it discloses opening the user's browser, waiting up to 5 minutes, persisting tokens to config, the anonymous-grant auto-claim behavior (with best-effort degradation to a notice rather than a failed login), and the pending_claim resolution workflow that avoids re-opening the browser — consistent with idempotentHint=true. No contradiction with readOnlyHint=false or destructiveHint=false.

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

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

The description is long but every sentence earns its place — protocol, side effects, timing, when-to-use, when-not-to-use, fallback, and edge-case handling. The core action is front-loaded before the routing guidance. Length is justified by the genuine complexity of an auth flow with claim semantics, though it borders on verbose.

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

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

The tool executes a complex interactive flow with browser interaction, token persistence, anonymous-workspace claiming, and a pending_claim state — and the description covers all of it: what it does, side effects, failure modes ('never a failed login'), timing, exclusion cases with alternatives, and the pending_claim decision loop. An output schema exists so return values need no elaboration, and it still notes the return format matches the CLI's summary.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description still adds value: it explains that scope='live' pre-checks the consent box (adding behavioral context), that api_url targets non-default deployments like staging, and — most valuably — the workflow condition for attach_anonymous_work ('Pass true/false ONLY after asking the user; with a pending claim stored, this resolves it without re-running the browser flow'). This is meaningful context beyond the schema's field descriptions.

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

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

The description names the specific protocol (OAuth 2.1 + PKCE), flow type (browser-loopback), resource (Keel), and concrete side effect (persisting tokens to ~/.keel/config.yaml for subsequent authentication). This precisely identifies the operation and structurally distinguishes it from the sibling keel_auth_logout and the status-checking keel_status.

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 is given ('Call this when keel_status returns authenticated: false, or whenever another tool's error envelope points here'), plus two explicit exclusions: do NOT use for refreshing an existing session (client refreshes transparently) and do NOT use in headless environments — with the CLI alternative `keel auth login --key <token>` named. This is textbook 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?

While annotations already declare idempotentHint and destructiveHint, the description adds valuable specifics by itemizing exactly which fields are wiped and that api_url is preserved. It also reinforces idempotency ('safe to call when already logged out') and adds context about the auth error recovery behavior, exceeding what annotations alone provide.

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

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

The description is concise yet information-dense, with the primary action front-loaded. Each sentence adds distinct value—what it does, when to use it, what it affects, and a crucial caveat—without redundancy or fluff.

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, destructive, idempotent tool, the description fully covers usage context, safety considerations, and relationship to siblings. It also mentions the output schema exists externally, so no return value explanation is needed, making the description complete 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 has zero parameters and the schema coverage is 100%, so no parameter explanation is required. The description adds no parameter semantics, but the baseline for zero-parameter tools is 4, and the lack of params makes this appropriate.

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

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

The description states exactly what the tool does: clears stored Keel credentials from ~/.keel/config.yaml, and explicitly distinguishes it from the login sibling by naming keel_auth_login as the counterpart. It also clarifies what is affected (api_key, refresh_token, etc.) and what is preserved (api_url), leaving no ambiguity about its role.

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

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

The description gives explicit when-to-use guidance: to sign the user out or switch accounts, with a pointer to keel_auth_login. It also specifies when not to use it for transient auth errors, explaining that the client auto-refreshes on 401, and instructs to log out only on explicit user request or for identity switching.

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?

The description is highly transparent about the non-idempotent behavior (each call queues a new run), the write-through push behavior, auto_push opt-out, and conflict handling. It also discloses polling timeout behavior. The annotations only declare non-idempotence and non-read-only; the description adds significant behavioral context about side effects (pushing commits), defaults, and edge cases. However, given the annotations already hint at non-idempotence, and the description doesn't contradict them, a 4 is appropriate — it adds substantial context but doesn't fully describe all possible failure modes or the output schema.

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

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

The description is lengthy but packed with important behavioral details. It front-loads the return fields and defaults, but the write-through and push behavior comes later. It could be restructured into clearer sections, and some sentences are dense. However, every sentence earns its place — there's no filler. Still, it's on the long side for a tool description, so a 3 is appropriate.

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 the tool's complexity (9 params, nested config, non-idempotent, write-through behavior, multiple edge cases), the description is remarkably complete. It covers return values, defaults, alternatives, usage guidance, and edge cases. The output schema exists, so it doesn't need to enumerate output fields. The only minor gap is not describing the exact format of summary_metrics, but the output schema likely covers that. For a tool this complex, this is near-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 100%, meaning the schema already documents every parameter with descriptions. The description adds value by explaining the default behavior (start_date defaults to 2024-08-15, end_date to today, config to platform values) and the write-through push behavior tied to commit_id and auto_push. It also explains the deprecated initial_capital alias. Since the schema does the heavy lifting and the description adds meaningful context on defaults and interactions, a 4 is justified — it goes beyond the baseline 3.

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

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

The description clearly states the tool submits a backtest for a strategy over a date range, with specific return fields. It also distinguishes itself from keel_backtest_summarize and keel_backtest_watch, which are the obvious sibling tools for related operations.

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

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

The description provides explicit when-to-use guidance: it defaults to running a backtest without interrogation when user says 'backtest X', and explicitly says not to re-fetch results (use keel_backtest_summarize instead). It also explains when to override defaults (only when user explicitly asks). This is strong usage guidance with exclusions and 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?

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond these: it returns a 'presigned `results.json` URL' (implying temporary access), only works 'when the run is complete', and expects the agent to be proactive and read the result to reason about mechanisms. This enriches what annotations alone do not convey. No contradiction with annotations.

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

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

The description is longer than typical, but it is front-loaded with the core purpose and then provides structured, purposeful guidance on proactive usage, interpretation, and restrictions. Every sentence contributes to correct usage, and the structure is logical. It is not concise, but it is well-organized and not 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?

The description covers when to use (after successful run), when not to use (mid-run), what it returns (including the presigned URL and hero_url), and how to interpret results (reason about mechanisms, avoid curve-fitting). Given an output schema exists, it does not need to list all return fields. The description is complete for an agent to call it correctly and interpret the output effectively.

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

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

The schema already documents the single parameter `backtest_id` as 'The backtest_id returned by `keel_backtest_run`.' The description repeats this origin but adds no new semantic meaning—only the proactive instruction to use 'the same backtest_id'. With 100% schema description coverage, the description adds minimal value beyond the schema.

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

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

The description clearly states the tool summarizes a completed backtest and lists the specific metrics it returns (Sharpe, max drawdown, total return, turnover, funding-attribution, period info, results.json URL, hero_url). It also distinguishes itself from siblings by explicitly noting 'Do NOT use mid-run' and referencing `keel_backtest_run` and `keel_backtest_watch` as alternatives.

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

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

The description gives explicit when-to-use instructions: 'after `keel_backtest_run` returns successfully, call this automatically' and warns against using it mid-run, directing the agent to poll status_url or wait for the post-run hook. It also names the alternative `keel_backtest_run` with `wait=true` for live submission, leaving no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no-destructiveness, and the description contradicts none of them (polling is indeed read-only and idempotent). Beyond the annotations, it discloses rich behavioral context: it clamps its own interval/timeout, returns the latest snapshot even when the run is still going (so 'call it again' if terminal is false), and reports stable tearsheet hero_url plus status/metrics/results_url on completion. This adds real value over the annotation flags.

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 and terminal-status semantics are front-loaded in the first sentence, and the follow-up routing plus two exclusions are placed at the end. It is longer than average (about eight sentences), but every sentence earns its place — the poll semantics, return behavior, and the important do-not warnings would each be costly if omitted. Slightly verbose given the schema already covers parameter details, but not padded.

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

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

With an output schema present, the description is not burdened with exhaustively defining the return shape, yet it still covers what an agent needs to act correctly: the terminal states, the timeout/interval clamping, the non-blocking return when a run is still active, the stable hero_url, and the explicit handoff to keel_backtest_summarize. Nothing an agent needs to invoke or reason about this polling tool is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all four parameters, including clamp ranges on timeout_s and interval_s and the meaning of backtest_id and no_ownership_hint. The description adds marginal color — it tells the agent to 'pass the run_id' and reiterates the clamping behavior — but does not introduce meaning beyond what the schema provides. No penalty, no bonus beyond baseline.

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

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

The description states a specific verb and resource ('Poll an already-running backtest until it reaches a terminal status'), names the exact terminal states, and distinguishes itself from siblings by calling itself 'the bounded way to wait' on a run from keel_backtest_run. An agent can immediately tell this apart from keel_backtest_run and keel_backtest_summarize 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?

Usage guidance is explicit: use it to wait on a run already started by keel_backtest_run, and it gives two hard 'Do NOT' exclusions — do not use to start a new run (call keel_backtest_run first) and do not hand-roll a polling loop around keel_backtest_summarize. It also names the follow-up tool (keel_backtest_summarize) to read results, leaving no ambiguity about when to reach for 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value beyond that by disclosing the richness of the returned contract (parameter names, types, slot reads/writes, examples, pitfalls) and its role as the 'source of truth' for authoring ComponentRef(...), including why it matters — the DSL should fit on the first try rather than after a dry-run bounce. No contradiction with annotations.

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

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

The purpose is front-loaded in the first sentence, and the structure flows logically: what → when → why → exclusions. There is slight redundancy — the instruction to use keel_components_search for discovery appears twice, once in the workflow sentence and once in the explicit 'Do NOT use' clause — but every other sentence earns its place with concrete routing and workflow guidance.

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 lookup tool with an output schema, the description is complete: it covers what the tool returns, when to call it versus two alternatives, how to use the result (authoring ComponentRef for keel_strategy_compose), and what it should not be used for. The output schema carries the return-format burden, and annotations carry the safety profile, so nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%; the schema already documents `name` as a case-sensitive component name with examples (RSI, RollingZScoreTransform). The description adds mild context that the name must map to a known pipeline component and that the returned contract's exact parameter names matter for ComponentRef authoring, but this does not materially extend the schema's parameter documentation. Baseline 3 is appropriate.

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

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

The description uses a specific verb-resource pairing — "Fetch the full schema/detail contract for ONE known pipeline component" — and enumerates exactly what the contract contains (parameter list, type signature, slot reads/writes, examples, pitfalls). It also explicitly differentiates itself from sibling tools by naming keel_components_search (discovery) and keel_components_detail_batch (batch verification), so an agent can distinguish them without opening schemas.

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

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

The description gives explicit when-to-use guidance ('once discovery has narrowed to a single component you're about to wire'), names the tool to call first (keel_components_search), names the alternative for multi-component verification (keel_components_detail_batch), and provides two 'Do NOT use' exclusions with correct alternatives (keel_components_search, keel_help). Nothing is left to inference.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses key behavioral traits: unknown names produce per-entry error objects rather than failing the call, partial results are normal, and found/missing counts appear in the envelope. It also explains the intended workflow consequence when shapes don't fit. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose and then layers usage, return behavior, and workflow pattern in a readable order. It is verbose and repeats a few points (canonical step, before drafting DSL), but the extra length mostly carries actionable guidance rather than 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 read-only batch lookup with strong annotations and an output schema, the description leaves nothing essential missing: what it returns, how errors are handled, when to call it, what to do before/after, and which alternative to choose for single components.

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 input schema already documents the sole parameter with a clear case-sensitivity warning and example. The description reinforces that names should reflect planned components and that the call takes a batch list, but it does not add substantial semantic meaning beyond the schema's existing 100% coverage.

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: fetch full specs for several components in one call. It explicitly distinguishes itself from the single-component alternative (keel_components_compose_help) and from the search sibling, making its role unambiguous.

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

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

The description is explicit about when to use it: as the canonical second step after keel_components_search and before drafting DSL, for both new strategies and edits. It also gives a clear exclusion: do NOT use it for one component, and names the cheaper alternative.

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?

The annotations already mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond those hints. It explains that results are compact triage entries with name/category/description/input-output type, that returned sets should feed into `keel_components_detail_batch`, that Keel re-clocks in only one direction, and that hand-rolled components from memory can misrepresent the requested concept (e.g., `ConstantForecast(-10)` vs `BetaHedgeAllocator`). No contradiction with annotations.

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

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

The description is long, but nearly every sentence carries operational value: primary purpose, workflow rules, clock-direction caveat, return-format expectation, and explicit exclusions. It is front-loaded with the most important fact (REQUIRED first step) and then structured logically. Minor redundancy in repeated emphasis on 'search is not optional' keeps it from a 5, but it is far from bloated given the tool's complexity.

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 a search tool with 9 optional parameters, 100% schema coverage, an output schema, and read-only annotations, the description covers everything an agent needs to invoke it correctly: when it is mandatory, how to decompose queries, what results look like, how to follow up, and which sibling tools handle adjacent cases. Nothing material 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 100%, so the baseline is already high; the schema documents every parameter including weighted scoring for `query` and direction semantics for `clock_direction`. The description goes beyond the schema by tying parameters to the discovery workflow (e.g., filter by `clock_direction` for the desired operator direction, pair `keyword` with `query` for narrowing, use `after`/`before` for pipeline position). This adds practical selection guidance rather than merely restating schema fields.

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 ('Search the Keel pipeline component catalog') and the full set of search dimensions (keyword, semantic query, category, input/output type, pipeline position). It also explicitly distinguishes itself from siblings like `keel_components_compose_help` (single-component schema) and `keel_strategy_search` (strategy enumeration), so an agent can disambiguate without opening their schemas.

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

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

Usage guidance is unusually explicit: it declares this tool the REQUIRED first step in every build turn, instructs decomposing the thesis into roles and searching each role, mandates searching whenever the user names a concept, and warns against planning from memory. It also provides concrete exclusions ('Do NOT use to fetch the full schema of ONE component', 'Do NOT use to enumerate strategies') with named alternatives, leaving no ambiguity about when to use this tool versus its 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?

Beyond the annotations, the description discloses that the tool is a single read-only pass, what it checks, and that it exits non-zero when any check fails so it can gate scripts. This adds real behavioral context beyond the readOnly/idempotent/destructive hints, and nothing contradicts the annotations.

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

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

The definition is front-loaded with the core purpose and each sentence earns its place: one for scope, one for when to use it, one for exit-code scripting behavior, and one for exclusions. It is dense but not padded.

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-input diagnostic tool with an output schema and rich annotations, the description covers purpose, triggers, behavioral consequences, and alternative routing. Nothing an agent needs to invoke it correctly is missing.

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

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

There are zero parameters and the schema is a closed empty object, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter compensation is needed.

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

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

The description opens with a precise verb–resource pairing: 'Diagnose the Keel CLI/MCP installation in one read-only pass' and names the checked areas (auth, API reachability, active tool surface). It also closes with explicit 'Do NOT use' language that distinguishes it from keel_strategy_search and keel_accounts_list.

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 specific environmental-failure triggers (auth rejected, API unreachable, expected tool missing) and explicitly advises against blind retries. It also names the alternative tools for enumeration, so the when-to-use versus when-not-to-use decision is fully 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?

The description goes well beyond the annotations by revealing that the tool never fails, that delivery problems are reported as success with a note, and that it is always safe to call and should not be gated upon. It also clarifies that nothing is returned in-session for support-style inquiries. These are critical behavioral traits not present in the annotations.

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

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

The description is somewhat long but well structured, front-loading the purpose and then covering usage, parameters, and exceptions. Each sentence contributes useful information; no filler. It could be tightened, but the clarity benefits from the detail.

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

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

Given the tool's simple nature and that the output schema exists, the description covers everything an agent needs: what it does, when to use it, what parameters to provide, and the safety/behavior guarantee. It also handles edge cases (never fails, no support replies) comprehensively. Nothing 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?

The input schema already documents all five parameters with descriptions (100% coverage), so the bar is set at 3. The description adds meaningful context by explicitly telling the agent to provide `goal`, `kind`, and `text` (effectively indicating they are required despite not being marked as such in the schema) and clarifying the meaning of `context_ref`. This lifts it above the baseline.

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

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

The description clearly states it sends product feedback (friction, praise, or bug) to the Keel team. It is specific about the resource (Keel) and the action (send feedback), and it explicitly contrasts with support questions and names keel_doctor as the alternative for connectivity problems, distinguishing it from 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?

The description gives explicit when: at the end of a session and whenever the same friction repeats. It also states when NOT to use: for support questions (nothing is returned, no human replies) and names the alternative tool (keel_doctor) for connectivity issues. This leaves no ambiguity about appropriate invocation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: the topic slug maps to keel:// URLs, the no-topic call returns a list, and it encourages listing before fetching. This goes beyond annotations without contradicting them.

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

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

The description is a bit long, but each sentence earns its place: it front-loads the core purpose, then gives usage pattern, then explicit exclusions. It is well-paragraphed and flows logically from what to how to when-not. Minor trimming could improve conciseness, but no sentence 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 only one optional parameter and an existing output schema (not shown but present), the description covers everything an agent needs: what the tool does, how to call it (including the list-first pattern), when to use alternatives, and the underlying topic model. Nothing critical 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 100% with a description and example slugs, but the description adds meaning: it explains that omitting the topic returns the list of available topics, and maps topics to keel:// reference and knowledge paths. This is value beyond the raw schema field description.

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

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

The description clearly states a specific verb (fetch) and resource (Keel knowledge or DSL-reference document), and explicitly names the sibling tools it is NOT (keel_components_search, keel_components_compose_help). An agent can distinguish this from siblings 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?

Provides explicit when-to-use scenarios (when a host doesn't browse MCP resources well, or for general 'how does X work?' questions) and when-not-to-use with concrete alternatives (search components -> keel_components_search, component params -> keel_components_compose_help). It also recommends the workflow of listing topics first, then fetching the specific one.

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

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

Annotations declare it non-read-only (mutation) but non-destructive, and the description adds genuinely useful context on top: the fork is a 'full copy' that behaves like any other strategy, and critically it warns that the library's published metrics belong to the verified run, not the fork — routing the agent to keel_backtest_run for the fork's own evidence. This matches and enriches the annotations with no contradiction.

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 sentences, each earning its place: the purpose, the default suggestion, the full-copy/metrics caveat, and the sibling routing. It's somewhat long but not bloated, and the core purpose is front-loaded ahead of the exclusions.

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?

Complete for a mutation tool with an output schema and 100% parameter coverage. It covers the sibling distinction, the metrics caveat, the default entry, and the full-copy semantics. Nothing an agent needs to correctly invoke it 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 100% — name, slug, and variant_id all carry descriptions. The description adds marginal value by suggesting ma-crossover-crypto as a concrete default slug value and confirming slug provenance from keel_library_list. Baseline 3 is appropriate since the schema already documents all parameters adequately.

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 ('fork') + resource ('verified Keel Library entry') + outcome ('normal, editable strategy in caller's org'). It clearly differentiates from the primary sibling (keel_strategy_fork) by specifying it targets YOUR strategies/share links, while this targets library entries. The purpose is unambiguous and scoped.

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 alternative tool and the selection condition: 'To fork one of YOUR strategies or a share link, use keel_strategy_fork (it takes ids, not slugs).' It also frames the tool as 'the supported way to start from something proven instead of composing from scratch' and calls out ma-crossover-crypto as the default for first strategies. When-to-use and when-not-to-use are both stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful context by specifying that the numbers are verified from the library's run, not a promise for any fork, which is a behavioral nuance not captured in the structured fields. No contradiction with annotations.

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

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

Two sentences, each earning its place: the first defines the tool's scope and content, the second gives usage guidance. No filler or unnecessary complexity, and the key guidance is front-loaded.

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 the tool's simplicity (one parameter) and the presence of an output schema, the description sufficiently covers the content (headline metrics, backtest window, data freshness, variants) and provides important context about data verification. Nothing an agent needs to call it correctly is missing.

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

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

The input schema provides 100% coverage for the single parameter 'slug', including its description referencing keel_library_list. The tool description adds no additional parameter detail beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

States the verb 'Read' and the resource 'one Keel Library entry's verified facts' with a specific list of data (headline metrics, backtest window, data freshness, variants). It also distinguishes from sibling tools like keel_library_fork and keel_library_list by emphasizing its role as the evidence source before forking, making it unambiguous which tool to pick.

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 explicit usage guidance: 'Use this as the evidence source BEFORE forking' and clarifies that the data is 'the library's verified run, not a promise about any fork.' This gives a clear when-to-use and implicitly contrasts with alternative actions (forking), leaving no ambiguity about its place.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by specifying the row contents, such as slug, name, category, risk band, and headline metrics from the verified run, and that entries are published/backtested.

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

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

The description is two sentences with no wasted words. It front-loads the action, then gives the row contents and cross-references to the two most relevant sibling tools, all in a compact, scannable structure.

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 parameterless listing tool with no required inputs, an output schema, and annotations covering side effects, the description is complete. It conveys what is listed, what each row contains, and how to perform related follow-up actions, leaving no critical 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?

The tool has zero parameters, and the schema completely covers this with an empty properties object. The description does not need to explain parameter behavior; a baseline of 4 is appropriate for a parameterless tool.

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: it lists the Keel Library, the verified, backtested strategy entries published in the product. It also differentiates itself from sibling tools by clarifying that keel_library_get reads full facts and keel_library_fork starts from an entry.

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

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

The description explicitly routes the agent to alternatives: use keel_library_get for full facts and keel_library_fork to start from an entry. This makes it clear when the list tool is the right choice versus those 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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds material behavioral context: it never changes a deployment, positions is an on-demand exchange snapshot, portfolio/history views may lag the live-service stream, and the tool is not a real-time tail. This significantly helps the agent interpret results correctly.

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

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

The description is dense but every sentence earns its place: purpose, defaults, freshness caveat, and exclusions are all packed into a compact paragraph. The safety-critical 'Do NOT use' guidance is clearly front-loaded with alternatives named.

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 multi-view tool with 9 parameters and no required fields, the description covers default behavior, per-view semantics, freshness/lag caveats, and routing to sibling tools. The output schema already exists, so return structure does not need to be repeated. Nothing essential is missing for correct selection and invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by documenting the no-args default behavior, the deployment_id omit/'all' behavior for portfolio, and that some views ignore certain parameters. This goes beyond the schema's per-field descriptions, though not exhaustively for every view combination.

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: 'Read-only observability for live deployments' followed by an explicit list of supported slices. It also distinguishes itself from keel_live_control and keel_live_deploy, so an agent can immediately tell what this tool is and what it is not.

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

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

The description gives concrete invocation guidance: call with no args for a cross-deployment portfolio summary, pass deployment_id to drill down, and read freshness before interpreting data. It also explicitly states when NOT to use the tool and names the alternatives: keel_live_control for state changes and keel_live_deploy for deploying new strategies.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds context beyond annotations: 'it builds the canonical URL and changes nothing' and clarifies it is read-only navigation. It also explains the return value is a URL to present. This adds value without contradicting annotations.

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

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

The description is moderately long but every sentence adds value: purpose, id variations, use case, read-only note, presentation instruction, and exclusions. It is front-loaded with the core purpose and structured logically, though it could be tightened slightly without losing content.

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 read-only navigation tool, the description is complete. It explains what it returns (a URL), how to present it, and explicitly covers what it does not do. Given the output schema likely documents the url field, nothing an agent needs to call correctly is missing.

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

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

The schema already describes the id parameter with the three possible prefixes. The description goes further by explaining that the id type determines which page is returned (strategy overview, backtest tearsheet, or share page). This adds meaningful semantic detail beyond the schema, which is worth more than the baseline 3 for high schema coverage.

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 exactly what the tool does: 'Returns a link to view and manage this strategy in the Keel web app.' It identifies the specific resource (strategy/backtest/share) and distinguishes itself from siblings like keel_strategy_get and keel_backtest_summarize by clarifying it only builds a URL. The purpose is unambiguous and specific.

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

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

The description explicitly tells when to use this tool ('whenever the user wants to see the visual result or continue with the strategy in the app') and when not to ('Do NOT use to fetch strategy data or metrics'), and names the alternatives (keel_strategy_get, keel_backtest_summarize). This is exactly what an agent needs to route correctly.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not repeat those. It adds useful behavioral context beyond the annotations by detailing the projection's purpose and what it returns (`next_recommended_action`, `missing_evidence`, `live_readiness_blockers`), and frames the tool as a steering aid. It does not mention auth, rate limits, or side effects, but for a simple read operation with those annotations, the added context is sufficient.

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

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

Two sentences, zero filler. The first sentence states the action and purpose, the second lists return fields and then gives clear exclusions. Every clause earns its place, and the most important info (read-only, projection) is front-loaded. Structure is optimal for an agent scanning descriptions.

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 one parameter, full schema coverage, and rich annotations (read-only, idempotent, non-destructive), the description is complete. It explains what the output represents, when to use it, and when not to, without needing to re-explain return structure (which the output schema covers). The 'maturation arc' concept is briefly contextualized by the listed outputs. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter `strategy_id` is already documented with type and an example ('e.g. `str_abc123`'). The description adds no extra parameter-level detail (e.g., constraints, encoding, or special values) beyond what the schema provides, so it stays at the baseline for high coverage.

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 ('Fetch'), a clearly defined resource ('first-session ownership projection for one strategy'), and the purpose ('where it sits in its maturation arc and what to do next'). It distinguishes from siblings by explicitly saying it is NOT for backtests or changing strategy source, pointing to `keel_backtest_run` and `keel_strategy_compose`. This fully separates it from the sibling tools, especially `keel_strategy_status`.

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

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

The description gives explicit when-to-use guidance ('Read it, then act with the build-loop tools') and clear exclusions ('Do NOT use to run a backtest or change strategy source') with named alternatives. It leaves no ambiguity about when this tool is appropriate versus its 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?

Annotations already carry readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds value beyond annotations with the specific 'never spends quota' disclosure, which is a concrete behavioral trait not present in the annotations. The 'read-only' phrasing is consistent with the annotations — no contradiction.

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 purpose is front-loaded in sentence one, followed by behavioral note, usage contexts, and a caution. Three sentences cover a lot of ground with no filler, but it is slightly more verbose than the minimal two-sentence gold standard. Every sentence earns its place, so it is efficient 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 zero-parameter reporting tool with an output schema present, the description is fully complete. It covers what is returned, the read-only/quota-free guarantee, when to consult it (before backtest sweeps, for live cost reasoning), and what it is NOT for (auth state, via keel_status). Nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters, so the baseline of 4 applies per rubric. Schema coverage is 100% with an empty properties object; there is nothing to document. The description focuses its energy on what the tool returns, which is appropriate given there are no inputs to disambiguate.

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 leads with a specific verb ("Report") and precise resource ("the org's current Keel plan as enforced numbers"), then enumerates exactly what is returned: plan name, per-plan limits, remaining quota components, builder fee in bps, and upgrade_options with prices and limit differences. It explicitly distinguishes itself from the sibling keel_status, so an agent can tell them apart without opening schemas.

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

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

Provides explicit when-to-use guidance: "Check it before a large backtest sweep to stay within the remaining allowance" and "when a high-turnover strategy's live cost comes up". It also states a hard when-not and names the alternative: "Do NOT use to check auth state or visible tools — call keel_status". This is textbook usage guidance with alternatives and 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?

The annotations (destructiveHint=true, openWorldHint=true, readOnlyHint=false) already flag a write/impactful action, but the description adds crucial context: the data becomes 'WORLD-READABLE' and the action 'always routes through host confirmation'. It also explains why this matters by distinguishing from private default links. This goes well beyond the annotations.

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

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

The description is compact and front-loaded with the core action, then the critical warning, then parameter interplay, and ends with an exclusion. Each sentence earns its place, though the all-caps warning is emphatic but slightly noisy. Still, it's well-organized.

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 the destructive privacy implications and the parameter interactions, the description covers everything: what it does, when to call it, what not to do, and how key parameters behave. The presence of an output schema means return values are handled elsewhere. No important context 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 100%, so the baseline is 3. The description adds extra value: it reveals the prefix-based auto-detection of target_id, and clarifies the dependency between permission='fork' and include_source=true for strategies, which the schema mentions but does not connect. This is genuinely helpful for correct invocation.

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

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

The description opens with a specific verb and resource: 'Publish a strategy or a backtest result at a public usekeel.io/share/<id> URL.' It clearly identifies the output and differentiates from reading shares via the closing exclusion. This 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 provides an explicit condition ('only call it when the user explicitly asks to share publicly'), contrasts with private defaults, and tells the agent exactly when not to use it ('Do NOT use to fetch an existing share URL') with a pointer to an alternative ('read the strategy or backtest resource instead'). This leaves no guesswork.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable context about the scope and contents of the status report (auth, quota, toolsets) and implies a snapshot behavior. It doesn't contradict annotations and supplements them with operational details, though it doesn't disclose any hidden traits like latency or network dependencies—minor gap.

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

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

The description is well-structured and front-loaded with the core purpose. Every sentence contributes: the report contents, the scenarios for use, and explicit exclusions with alternative tools. No fluff or redundancy, and the do-not-use lines are clearly separated.

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 zero parameters and an output schema present, the description needn't explain return values. It covers the tool's purpose, contents, usage scenarios, and sibling exclusions, giving an agent everything needed to decide when and how to call it correctly. It is complete for a status-reporting tool.

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

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

The tool has zero parameters, and schema description coverage is 100% (vacuous). Baseline is 4 for no parameters; the description correctly avoids repeating any param info since none exist. No additional semantic value is needed.

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

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

The description opens with a clear verb and resource: 'Report Keel CLI/MCP status in one call' and enumerates exactly what is included (auth state, identity, API URL, toolsets, quota, cross-surface hints). It explicitly distinguishes itself from siblings by naming keel_strategy_search and keel_doctor as alternatives for different purposes, so an agent can easily tell them apart.

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

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

The description gives explicit when-to-use guidance ('Start here when wiring up a new agent or when you're unsure what's authorized') and a concrete scenario (checking quota before a large backtest sweep). It also states what NOT to use it for and names the correct tools, making the routing 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?

The description discloses critical behavioral traits beyond the annotations: it is a WORKING COPY (disposable and always reconcilable), server HEAD is the single source of truth, runnable actions write through local edits by default, and edits stay local until push. It also specifies the files written and directory defaults. This gives the agent a clear mental model of checkout semantics, far exceeding what annotations provide.

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

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

The description is relatively long but every clause earns its place. It front-loads the core purpose and then layers in working-copy semantics, file outputs, push/status flow, and usage exclusions. The structure is logical and dense, though it could be slightly trimmed without losing value.

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 significant contextual nuance (working copy vs server, local edits, default directories, interplay with push/status/compose), the description covers all key aspects. It explains what happens to edits, where files go, and which sibling tools to use for other operations. An output schema exists to describe return values, so not describing them is fine. The description is complete enough for an agent to call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some practical context (e.g., default dir resolution based on workspace.yaml, example strategy_id format) but most parameter meaning is already in the schema. It does not meaningfully expand on the schema's parameter descriptions, so a 3 is appropriate.

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

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

The description opens with a specific verb and resource ('Pull a platform strategy into a local workspace') and immediately clarifies its scope as working-copy management. It explicitly differentiates from siblings by stating it is NOT for creating new strategies (keel_strategy_compose) and NOT for backtest artifacts, leaving no ambiguity about its role.

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

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

The description gives explicit when-to-use guidance ('Use this BEFORE iterating on an existing strategy') and when-not-to-use guidance with named alternatives ('Do NOT use to CREATE a new strategy — call keel_strategy_compose'). It also explains the recommended workflow (checkout → edit → push) and references keel_strategy_status and keel_strategy_push, so the agent knows exactly how this tool fits into the broader toolset.

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?

The annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false) carry only a general safety profile, and the description adds far beyond them: validation does NOT block the save (only parse/compile errors do), updates commit to server HEAD and write back into local working copies via workspace_sync unless there are uncommitted edits (never overwritten), and DSL constraints (no Python import statements; pipeline must end with a normalizer). This gives the agent accurate expectations for side effects and 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?

The description is front-loaded with the core purpose and dry_run guidance, which is good, but it is a long, dense wall of text with no visual structure. It is somewhat redundant — the no-fork/no-backtest exclusions and the pointer to keel_help(dsl_syntax) appear more than once, and the 'same knowledge chat-api keeps always-on' aside adds little. Most content is necessary given the tool's complexity, but tightening and sectioning would make it easier for an agent 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?

Given the output schema covers return values and the tool is highly complex, the description is remarkably complete: it covers purpose, create/update modes, workflow prerequisites, defaulting behavior, server/local sync semantics, validation response shape (validation.errors/warnings), DSL constraints, and explicit routing to alternatives. Nothing an agent needs to call this correctly is left to inference.

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

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

Schema coverage is 100%, so the schema fully documents all six parameters, giving a baseline of 3. The description adds meaning on top: the source/source_file exclusivity ('Pass exactly one'), the strategic use of dry_run ('use this first to iterate cheaply'), the create-vs-update semantics of strategy_id, and the default-universe behavior when name/asset scope is absent. This exceeds the baseline without duplicating the schema.

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

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

The first line states a specific operation and resource: 'Create or update a strategy from DSL source.' It distinguishes the two modes (create with empty strategy_id vs. update with strategy_id) and explicitly excludes sibling tools ('Do NOT use to fork an existing strategy — call keel_strategy_fork. Do NOT use to run a backtest — call keel_backtest_run'). An agent can immediately tell this apart from keel_strategy_fork, keel_strategy_get, and keel_backtest_run.

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?

Exceptional when-to-use guidance: it mandates a two-step discovery prerequisite (keel_components_search then keel_components_detail_batch), instructs first-time composers to invoke the strategy-creation MCP prompt, tells modifiers to use strategy-fork-and-iterate with minimal changes, and names exclusions (fork → keel_strategy_fork, backtest → keel_backtest_run). It even specifies the default universe when the user gives no asset scope, so the agent doesn't stall on an undecided parameter.

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

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

Annotations already mark this as destructive, but the description adds crucial behavioral details: strategy_id cannot be reused, entire version history is removed, and local workspace files are NOT deleted. It also clarifies that deletion does not stop live deployments, which is a meaningful side-effect boundary.

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

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

The description is longer than average, but every sentence adds either a consequence, an alternative, or a misuse guard. The most critical information (irreversibility) is front-loaded, and even the repeated do-not-use statements reinforce high-risk exclusions.

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 the destructive nature of this tool, the description fully covers consequences, scope, alternatives, and exclusions. An output schema exists, so return-value details are unnecessary, and nothing needed 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?

The input schema already fully documents strategy_id with 100% coverage, so the description need not repeat parameter details. The description does not add new syntax or format guidance for the parameter, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Hard-delete a strategy on the platform.' It clearly distinguishes this from related operations by naming restore, discard, and live control as separate tools. The irreversible nature and scope are 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?

The description gives explicit when-to-use guidance ('only when the user explicitly wants the strategy gone for good') and names concrete alternatives for related scenarios. It also provides explicit do-not-use conditions, including which tool to call instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it explains the two operating modes (version mode vs file mode) and how refs are interpreted based on strategy_id. It also describes the output structure (added/removed/modified steps, per-parameter changes) which is beyond annotations. No contradictions. Slightly short of a 5 because it doesn't mention any edge cases or error conditions, but with annotations carrying the safety burden, this is strong.

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

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

The description is longer than average but every sentence contributes. The first sentence front-loads the core result, the second clarifies parameter interpretation, the third gives the primary use case, and the final sentence gives explicit exclusions with alternatives. It's well-structured and avoids fluff, though it could be trimmed slightly with proofreading. A 4 is fair.

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

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

The description is complete for a read-only diff tool. It explains the modes, how parameters interact, when to use it, and when not to. It even tells where to find the refs (keel_strategy_log). Since an output schema exists, the description doesn't need to detail return values. Given the tool's moderate complexity (3 params), nothing essential is missing for an agent to call 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 100% (each parameter has a description), so the baseline is 3. The description adds meaning beyond the schema by clarifying that ref_a and ref_b are ambiguous between file paths and version refs depending on whether strategy_id is set, and that strategy_id itself determines the mode. It also points to keel_strategy_log for discovering refs. This adds value over the schema's terse descriptions, so a 4 is warranted.

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

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

The description clearly states the action (Compute) and the resource (structural diff between two strategy versions or two sources), and enumerates exactly what the diff includes: added, removed, modified steps, per-parameter changes, reordering, and version changes, plus a summary. It explicitly contrasts with siblings by saying 'Do NOT use to fetch the actual source — call keel_strategy_get' and 'Do NOT use to merge or apply a change — call keel_strategy_compose', which fully distinguishes it.

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

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

It gives explicit when-to-use guidance ('Use it to confirm an iteration changed ONLY what you intended — one change at a time — or to see exactly what moved between two commits before restoring or forking') and explicit when-not-to-use with named alternatives (keel_strategy_get for fetching source, keel_strategy_compose for merging/applying). This leaves no ambiguity about the tool's niche.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description reinforces this by specifying what is removed (local files) and that the server-side strategy is 'untouched and still available'. It adds context about the local-only scope and the benefit of re-checkout, which goes beyond the annotations. No contradiction, but it could also mention idempotency explicitly (though the annotation covers it).

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

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

The description is four sentences, each adding distinct value: action/scope, server-state clarification, usage scenarios, and an explicit negative instruction. The most important information (what it does and local-only nature) is front-loaded, with no redundancy or 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?

Given the tool is simple (one optional parameter) and has an output schema, the description fully covers what an agent needs: what it does, what it doesn't do, when to use it, and its local-only scope. There are no missing critical details for correct invocation.

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

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

Schema coverage is 100% and the parameter description 'Strategy workspace to discard. Auto-detected if omitted.' already conveys semantics. The description does not add further details about the parameter or its usage, so the baseline of 3 is appropriate because the schema carries the load.

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

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

The description states a specific verb ('Remove') and a precise resource ('local workspace — the checked-out strategy.py + .keel-meta.json'). It clearly distinguishes itself from the sibling keel_strategy_delete by stating it only touches local filesystem state, and mentions alternatives like keel_strategy_get/checkout. This makes the tool's purpose unmistakable.

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 use: 'clean up after you're done iterating, or to reset a diverged workspace by re-checking out fresh'. Also gives a clear exclusion: 'Do NOT use to delete a strategy on the platform — call keel_strategy_delete'. This provides concrete guidance on alternatives and triggers, leaving no 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?

Annotations already carry the safety profile (destructiveHint=false, idempotentHint=true, readOnlyHint=false), and the description adds real behavioral context beyond them: fork produces a non-destructive COPY, the source argument accepts either a str_* id or a share-link id, and the tool auto-detects which endpoint to call. This is genuinely useful and not contradictory — no annotation conflict.

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 in the first sentence, followed by usage and exclusions. It reads long, but most sentences earn their place — especially the sibling routing. The iteration/never-rearchitect guidance is arguably workflow policy beyond the tool's function, which costs a point, but the structure is strong 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?

Complete for a mutation tool with an output schema and rich sibling context. It covers when to use, when not to use, source format, workflow for edits, and the alternative tools. An agent has everything needed to call it correctly without further queries.

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

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

Schema coverage is 100%, so all three parameters (source, name, target_workspace_id) are already documented in the schema. The description adds marginal value by clarifying the source argument formats (str_* vs share-link id) and auto-detection, but the heavy lifting is done by the schema — baseline 3 applies.

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

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

Uses a specific verb (Fork) + resource (strategy) and states the outcome precisely: a safe copy in your org, never touching the original. It explicitly differentiates from siblings by naming what it is NOT for — composing from scratch (keel_strategy_compose) or creating share links (keel_share_create) — so the agent can disambiguate 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?

Gives explicit when-to-use (iterating on an existing strategy via a COPY) and when-not-to-use with named alternatives: do NOT compose from scratch, call keel_strategy_compose; do NOT create a share link, call keel_share_create. It even prescribes the post-fork workflow (smallest change, re-backtest, discovery via keel_components_search/detail_batch before compose). Nothing is left to inference.

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

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

Annotations already fully cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false), so the bar is lower. The description adds workflow-context value beyond the annotations: the 'read before you adapt' strategy and the version/HEAD semantics. It does not contradict any annotation.

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 well-organized: core function first, then flag semantics, then workflow, then exclusions. The length is justified because every sentence adds either behavioral context or alternative routing. Slightly long relative to strict conciseness, 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 read-only, idempotent tool with a rich output schema and full annotation coverage, this description is complete. It covers what it returns (metadata/source/versions), how the flags modify behavior, the correct siblings for finding ids and iterating, and what NOT to use it for.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the intended usage of the optional flags ('pass include_source=true to also read the DSL source', 'include_versions=true to list every commit'), giving them practical meaning rather than just repeating the field descriptions.

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

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

States a specific verb-resource pair ('Fetch one strategy by id') and immediately scopes the variants (metadata by default, source with include_source, versions list). The scope is unambiguous and clearly distinguishes this from keel_strategy_search (enumeration) and keel_strategy_compose (mutation).

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?

Exceptional guidance: names the exact workflow ('fetch the source first so you plan the edit'), explicitly pairs with keel_strategy_search for finding the id and keel_strategy_fork for iteration, and gives two hard exclusions with the correct alternative tool for each. Nothing is left to inference.

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

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

Annotations already cover readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: reverse-chronological ordering, default limit (50), server-enforced max of 200, and the 'server HEAD is source of truth' nuance. It also describes the entry fields. Since annotations cover the safety profile, the description's additional context earns a high score, though it stops short of pagination or error behavior details.

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

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

The description is moderately long but well-structured, front-loading the primary purpose and then detailing fields, use cases, and exclusions. Each sentence contributes value; the 'git log' analogy aids comprehension. It could slightly trim the field enumeration, but overall it is efficient for the complexity.

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

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

Given an output schema exists (so return format is handled), the description covers the essential contexts: what each entry contains, ordering, use cases, and exclusions. It doesn't mention pagination, but for a log list tool with a default and max limit, this is adequate. The description is complete enough for an agent to decide and invoke correctly.

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

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

Schema coverage is 100%, with both parameters (limit and strategy_id) described in the schema. The description repeats the default and max limit values already in the schema, adding only a note that the limit is server-enforced. It doesn't add substantial new meaning beyond what the schema provides, so a baseline 3 is appropriate.

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

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

The description clearly states the core function: showing a strategy's commit history, analogized as the 'git log' of the sync model. It specifies the verb (show), resource (strategy's commit history), and distinguishes it from siblings like keel_strategy_diff (for structural changes) and a future source resource. This is specific and unambiguous.

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

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

The description provides explicit when-to-use scenarios (audit evolution, find ref to restore/diff, see what moved) and explicit when-not-to-use cases (for single-commit source, for structural diffs). It names alternatives directly (keel_strategy_diff, future resource). This leaves no ambiguity about 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about returning notes newest first, default limit, and the durable nature of the context. It does not contradict annotations and adds useful behavioral context beyond the structured metadata.

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

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

The description is well-structured with purpose first, then usage guidance and exclusions. It is longer than minimal but every sentence serves a purpose; no redundancy. It could be slightly more concise but is front-loaded and effective.

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 only 2 simple parameters and an output schema present, the description covers purpose, usage timing, return behavior, and exclusions. Nothing needed for correct invocation is missing. The output schema handles return format details.

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

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

Schema coverage is 100%, so both parameters are documented in the schema. The description adds a bit of context (e.g., 'newest first' for limit) but this is already in the schema's limit description. No significant new meaning added, so baseline 3 is appropriate.

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

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

The description states the verb 'Read' and resource 'agent/user notes attached to a strategy' clearly, and distinguishes from siblings by explicitly naming keel_strategy_get and keel_strategy_memory_write. It is specific and 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 explicitly guides when to use ('at the START of working on an existing strategy') and when not to use, naming the alternate tools for source/metadata and writing notes. This is exactly what's needed for correct 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds value by specifying the 'Append' behavior (non-destructive, non-idempotent) and the default role='agent' with a note on how to override. It does not contradict annotations and provides context about persistence ('durable') beyond the flags.

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 sentences with zero redundancy. The core action and purpose are front-loaded, followed by concrete examples and clear exclusions. Every sentence earns its place.

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

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

Given the simple 3-parameter schema (100% coverage), available output schema, and annotations, the description fully equips an agent to call the tool correctly. It covers content guidance, exclusions, and default behavior; nothing essential is missing.

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

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

Schema description coverage is 100%, so parameters are already documented. The description goes further by explaining the semantic intent of the `note` (capture reasoning, not steps) and the `role` default/override, which adds meaning beyond the schema's brief field descriptions.

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 ('Append') and resource ('a strategy's memory'), and immediately distinguishes itself from siblings by naming `keel_strategy_compose` and `keel_strategy_memory_read` as alternatives for mutation and reading. The purpose is clear and non-tautological.

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 guidance on when to use (capture WHY, baseline metrics, risks) and when not to use (mutating strategy source, reading existing notes), explicitly naming the alternative tools. No inference is required.

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

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

Annotations already signal readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds crucial context beyond that: it refuses when local has uncommitted changes, warns that force overwrites and 'LOSES local edits', and explicitly frames this as preventing silent work loss. This is valuable behavioral detail that the annotations do not convey.

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

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

The description is dense and every sentence carries information: purpose, refusal behavior, when to use, and what not to use. Though slightly long, it is well-organized and front-loads the core action. No filler or repetition; it earns its length.

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

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

The description covers the primary use case, the safety guardrail, the force escape hatch, and explicitly routes to sibling tools for other operations. For a pull/sync operation with only two optional parameters, this is complete enough for an agent to invoke correctly. The presence of an output schema also reduces the need to describe returns.

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

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

Schema description coverage is 100%, so both parameters (force and strategy_id) are already documented in the schema. The description's mention of force=True reinforces the loss warning, but it does not add new semantic meaning beyond the schema. With full schema coverage, a baseline 3 is appropriate.

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

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

The description opens with a precise verb and resource: 'Re-fetch the server HEAD into the local working copy' and explicitly names the git pull analogy. It clearly distinguishes itself from siblings by stating what it is not: 'Do NOT use to send local edits UP — call keel_strategy_push. Do NOT use to inspect what changed — call keel_strategy_log.' This makes the tool's purpose unambiguous and separates it from related tools.

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 explicit when-to-use context: 'Use it when someone else — a teammate, the web editor, a fork, a restore — may have moved the strategy while you were working locally' and advises a preceding status check. It also gives negative guidance (when not to use) and alternatives (push, log), making the decision process clear for the agent.

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

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

Adds rich context beyond annotations: conflict-safety through expected_source_hash, the overwrite behavior of force=True, auto-detection of strategy_id, and the critical fact that unpushed local changes won't be tested. Annotations only state readOnlyHint=false and destructiveHint=false; the description explains the actual write mechanics and safety model.

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

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

Every sentence earns its place. The opening is a clear verb+resource, the analogy is immediate, workflow instructions are front-loaded, and exclusions come at the end. It covers a lot of ground without redundancy. The length is justified by the tool's complexity.

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 three parameters involving conflict handling and a workflow dependency on backtests, the description covers all needed information: what, when, why, how to stay safe, what not to do, and the relationship to backtests and history. The existing output schema reduces the need to describe return values.

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

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

Schema coverage is 100% and each parameter already has a solid description. The tool description adds marginal but useful context: clarifies that force should only be used after verifying no concurrent work (echoing schema), that message impacts keel_strategy_log readability, and details the auto-detection of strategy_id. This goes slightly beyond the schema's plain definitions.

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

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

The description opens with a precise verb-resource pair: 'Commit local strategy.py changes back to the platform as a new version' and immediately uses the memorable 'git push' analogy. It names two sibling tools it is NOT (keel_strategy_compose, keel_share_create), making differentiation 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?

Provides concrete workflow timing: 'Push AFTER editing strategy.py, BEFORE running a backtest' and explains why (backtests run against server HEAD). Explicitly lists when NOT to use and redirects to keel_strategy_compose and keel_share_create. Also notes the message requirement for log readability.

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

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

Annotations are sparse (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the behavioral burden. It fully discloses that the operation creates a new commit preserving history, explains the server-side flow, states that the restore appears in the log, and warns that local workspaces become 'behind' requiring keel_strategy_pull. It also explicitly contrasts with a destructive rewind. This enriches the agent's mental model beyond the annotations.

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

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

Every sentence earns its place. The description is front-loaded with the core behavior and safety framing, then moves to usage and exclusions. No repetition, no fluff. The structure flows naturally from 'what' to 'when' to 'when not', making it easy for an agent to parse quickly.

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 non-trivial semantics (history-preserving restore, ref types, post-conditions) and an output schema, the description covers all necessary operational details: how to find the ref, what the operation does, what side effects occur on local workspaces, and valid alternatives. An agent has everything needed to decide and execute correctly.

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

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

Schema coverage is 100%, but the description adds meaningful semantics: it explains that 'ref' accepts sequence numbers, commit IDs, or tags with concrete examples, and tells the agent to discover it via keel_strategy_log. It also clarifies the default for 'message'. These details are not present in the raw schema and are essential for correct invocation.

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

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

The description opens with a specific verb and resource: 'Restore a historical commit as the new HEAD'. It distinguishes itself from siblings by explicitly naming keel_strategy_fork, keel_strategy_pull, and keel_strategy_discard as alternatives for different intents, and frames the tool as the 'safe undo' versus destructive rewinding. This makes the tool's distinct purpose unmistakable.

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

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

It provides precise when-to-use conditions (undo an edit, revert to a better-backtested version) and prerequisite workflow (find ref with keel_strategy_log first). It also names three clear when-not-to-use cases with specific alternative tools/parameters: fork uses keel_strategy_fork, discarding local edits uses keel_strategy_pull force=True or keel_strategy_discard. No ambiguity remains.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral nuance beyond annotations: it discloses that on CLI (TTY) calls with no filters, locally checked-out workspaces are also included, which is a runtime behavior an agent would not infer from the schema or annotations. It also clarifies that this tool searches/lists but does not return full source (that belongs to get). No contradiction with annotations.

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

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

The description is somewhat lengthy (about 120 words) but every sentence serves a purpose: purpose, workflow, TTY caveat, and exclusions. It is front-loaded with the core behavior and includes the most important differentiators early. While not terse, it is well-structured and avoids redundancy, earning a strong score.

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 the tool's complexity (6 optional filters, pagination via cursor, output schema, and interactions with siblings), the description covers all essential aspects: what it returns (search results), when to use it, what it does not do, and the TTY-specific behavior. An output schema exists, so return format details are not required. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so every parameter already has a description. The tool description adds meaning above that: it clarifies that `query` is a 'name substring' filter and groups all filter parameters into a cohesive filter set. This helps an agent understand that these parameters are used for filtering rather than for other purposes, adding modest value beyond the schema.

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

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

The description opens with a specific verb-resource pair — 'Search and list strategies in the current org' — and enumerates the exact filter dimensions (`query`, `tag`, `owner`, `share_id`). It distinguishes itself from sibling tools by explicitly naming `keel_strategy_get`, `keel_strategy_fork`, and `keel_components_search` as alternatives, leaving no ambiguity about what this tool does versus others.

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

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

The description provides explicit when-to-use guidance: it is 'the entry point when the user wants to work on an EXISTING strategy rather than build a new one.' It also gives a concrete workflow — find here, then `keel_strategy_get` (with `include_source=true`), then `keel_strategy_fork` — and includes two direct 'Do NOT use' exclusions with named alternative tools. This fully covers usage 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond that: the meaning of each status, auto-detection of strategy_id, default inclusion of recent commits, and the recommendation to set include_recent=False for hot polling. It also explains why unpushed changes won't be tested (backtests use server HEAD). No contradiction with annotations.

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

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

The description is dense but every sentence earns its place. It front-loads the core purpose and return values, then moves to usage guidance and exclusions. Despite length, it is efficiently structured with no fluff — each clause adds information the agent needs.

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

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

The description covers all necessary context for correct invocation: return statuses, their implications, when to call, exclusions, parameter behavior, and auto-detection. With an output schema present and annotations covering safety, nothing an agent needs to call this tool correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3. However, the description adds value by explaining the strategic use of include_recent (hot polling loops), clarifying the default behavior of recent_commits, and noting auto-detection when strategy_id is omitted. This goes beyond the schema's bare descriptions, justifying a 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?

The description opens with a precise verb and resource: 'Compare a local workspace's strategy.py against the server's current HEAD'. It explicitly lists the four possible return values (clean, ahead, behind, diverged) and names the two siblings it is not (keel_strategy_workspaces, keel_strategy_log), making differentiation unambiguous.

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

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

The description gives explicit temporal guidance: 'Call this BEFORE keel_backtest_run' and 'after coming back from the web editor'. It also states clear exclusions: 'Do NOT use to list ALL workspaces' and 'Do NOT use to inspect full history', naming the correct alternatives. This is exactly the when/when-not/alternatives structure expected.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds useful context: 'Pure filesystem read' and the specific directories scanned (~/.keel/workspace/ plus project-local .keel/workspace.yaml-scoped workspaces), and 'no server call'. This complements annotations without contradicting them.

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

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

The description is two sentences. The first sentence front-loads the core purpose and return fields, the second gives usage and exclusions. No wasted words 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 parameterless read tool with an output schema, the description is complete. It covers scope, return contents, usage scenarios, and alternative tools. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters, and schema coverage is 100% by default. With no parameters to explain, the baseline is 4. The description correctly omits parameter details.

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 ('List'), resource ('locally checked-out strategy workspace'), and specifies the returned fieldsstrategy id, name, sync metadata). It also clarifies it's a pure filesystem read with no server call, distinguishing it from server-side listing tools.

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 when to use (lost track of checkouts, enumerate WIP before push/cleanup) and when NOT to use, naming alternative tools `keel_strategy_search` and `keel_strategy_status`. This gives clear guidance for selection.

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