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

Annotations already disclose openWorldHint=true, non-idempotent, non-destructive, and not read-only, so the mutation/cost framing is consistent. The description adds real context beyond those annotations: the response includes cost and the cost counts toward the user's budget, which is a meaningful side effect an agent should know before calling. It does not cover rate limits or failure modes, so not a 5.

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

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

Three tight sentences: what it does, how model selection works, and the billing consequence, with the core action front-loaded. Every sentence carries information and none is 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 four-parameter tool with no output schema, the description covers the action, the model-selection default, and the cost side effect, which is what an agent needs to invoke it correctly. Minor gaps remain around what the returned payload looks like beyond 'the answer with its cost', but overall it is sufficient.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the 'auto' default and the valid auto variants. The description only restates the Auto-vs-named-model behavior already present in the 'model' parameter description, adding little new meaning 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 states a specific verb and resource ('Ask a question through Leanfare and get the answer with its cost'), so an agent knows this is a model-invocation tool that also returns billing information. It does not explicitly distinguish itself from siblings like 'delegate', 'estimate', or 'plan', which a 5 would require.

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 useful conditional guidance for model selection: the default Auto picks the cheapest ticked model that rates well for the task, and naming a model overrides that. However, there is no explicit guidance on when to use this tool rather than siblings such as 'estimate', 'trial', or 'delegate', leaving that 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 it discloses what matters operationally: costs count against the user's Leanfare budget, answers are verified by a stronger model with a re-ask one tier up on failure, runs over ~40 seconds return an id that must be re-submitted alone, and files holding secrets are refused. It also explains that named files never enter the caller's context, which is the core behavioral payoff.

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

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

Purpose is front-loaded and almost every sentence carries new information about cost, verification, or the async path. It is delivered as one dense block, so the retry mechanics and receipt semantics are harder to scan than they need to be, but there is little outright filler.

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

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

With 13 optional parameters, no output schema, and an asynchronous id-based continuation path, the description still covers the call, the return shape (short answer plus receipt), the timeout behavior, and the cost model. Nothing an agent needs to invoke it correctly appears to be 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 would be 3; the description adds real meaning on top, notably the files contract (Leanfare reads them itself so their text never enters your context) and the id retry protocol (call delegate again with only that id). Remaining parameters are left to the schema, which already carries adequate enum and default documentation.

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 and target: hand a piece of work to a cheaper model via Leanfare, to save context and usage, and it characterizes the work shape (reads a lot, answers briefly). It is clear what the tool does, but it never contrasts itself with siblings such as ask or local_model, which overlaps on the private/local path.

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

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

It gives concrete when-to-use guidance (search or summarize big files, logs or many documents, review a file, draft a section) and a when-to-choose-private rule for sensitive or personal work. It stops short of explicit exclusions or naming an alternative tool for cases this one should not handle.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new context by confirming no model call occurs and by naming what the response contains (Auto's pick, the rationale, cheapest and fastest at the same quality). With no output schema, this is the main source of return-value information, though it doesn't describe format or precision of the cost/time figures.

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

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

A single front-loaded sentence that opens with the action and closes with the safety guarantee; every clause (cost, time, Auto's pick, why, cheapest, fastest, same quality, no model call) conveys distinct information. No filler or restatement of the title.

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

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

For a read-only, three-parameter estimation tool with no output schema, the description covers purpose, the safety profile, and the shape of the result adequately. The remaining gap is quantitative detail (units, precision, whether cost is per-token or total), which matters for an agent interpreting the numbers.

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 model, speed, and prompt are already documented in structured form. The description adds framing that helps interpret results ('the model Auto would pick', 'at the same quality'), but it does not explain parameter interactions such as how speed constrains the model choice or what a numeric seconds value does. Baseline 3 applies when the schema carries the parameter burden.

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

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

States a specific verb and resource ('estimate what a prompt would cost and how long it would take') and enumerates the exact outputs: the model Auto would pick, the reasoning, and the cheapest/fastest choice at equal quality. The closing 'Nothing is sent to a model' separates it from send-side siblings like ask, delegate, and trial without naming them.

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?

'before sending it' gives a clear temporal cue for when to reach for this tool, and 'Nothing is sent to a model' reinforces that it is a pre-flight check rather than an execution path. It stops short of naming a specific alternative (e.g., trial or ask) or stating when not to use it, so the routing is implied rather than explicit.

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

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

Well beyond the annotations, it discloses exactly what is persisted ('Leanfare keeps only the grade, with the model that answered and the kind of part, never the words'), where 'why' goes ('only to the model asked again'), and a real system side effect ('A model graded below good too often for a kind is moved down, so plans and delegate stop picking it for that kind'). It also warns that fix leanfare spawns another round producing 'a new hand off to review and grade too', which is essential for an agent to avoid a loop. The annotations only mark it as a non-idempotent write, so this text carries the substantive burden.

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 instruction is front-loaded, which is good, but the body is a single dense run-on chain of sentences with ambiguous referents ('a new hand off to review and grade too') and repetitive restatement of the fix loop. Every clause carries information, yet the compressed grammar forces re-reading, so it is information-dense rather than concise.

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

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

For a 10-parameter, nested-object tool with no output schema, the description covers the workflow, persistence, consequence and the whole-result case — far more than most. It is still silent on what a plain grade (without fix) returns and on error behaviour, which an agent would need to confirm success, so it falls short of fully complete.

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

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

Schema coverage is 100%, so the schema already documents every parameter, including enums and the nested checks object — that sets the baseline at 3. The description does add one genuinely useful routing rule beyond the schema ('grade a delegate answer with handoff; a plan's part with id and part'), which is a slight lift, but it never clarifies the model/kind pairing or when checks must be supplied, so it does not fully transcend 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 uses a specific verb+resource ('Review every answer... then say how good it was: good, partly or wrong') and identifies exactly which artifacts it grades: 'delegate, or a plan's part from plan_status'. That implicitly separates it from siblings like delegate, plan_status and report. It loses a point because the jargon-heavy, clipped phrasing ('a hand off', 'one tier up') makes the core purpose take a couple of passes to parse.

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

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

It gives a clear use rule ('Review every answer Leanfare brings back before you use it') and a separate trigger for the whole-result case ('At the end of a prompt that handed work off, grade its whole result too'). It also routes the agent on each verdict (if partly/wrong, fix myself or use fix leanfare with why). No alternatives are named, but for a terminal grading step there are no comparable siblings, so the absence is minor.

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

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

Annotations declare readOnlyHint=false, so the agent knows this is not a pure read, and the description hints that done/turn payloads record usage — roughly consistent, but it never says what a write does, whether it is persisted, or what comes back. 'Numbers only, never words' is cryptic and could describe the return value or the inputs; either way it is not actionable. With no output schema and a mutation-flagged tool, this leaves a substantial 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 text is a dense run-on with an unclear antecedent structure and jargon ('leanfare-level mod', 'the plan part it is for or else its kind of work'), forcing re-reads. The key purpose is buried mid-sentence rather than front-loaded, and several clauses do not clearly earn their place.

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

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

For a 7-parameter tool with nested objects, no output schema, and a mutation flag, the description should at minimum explain the pick-vs-record modes and the returned model-name shape. Instead it offers a cryptic 'Numbers only, never words' and no statement of persistence, idempotency behavior, or error cases, leaving the agent unable to call it confidently.

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

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

Schema description coverage is 100%, so the per-field meanings of done, task, turn, agent, asked, session and description are already documented. The description adds only marginal context beyond that, chiefly the selection rule ('by the plan part it is for or else its kind of work'), which is useful but underspecified about precedence. Baseline 3 is appropriate when the schema carries the parameter 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 does eventually convey the core purpose: return the Claude model Leanfare would pick for a subagent, named as the Agent tool names them (haiku, sonnet, opus, fable). But the opening clause ('For Leanfare's leanfare-level mod and Claude Code's hook, not for a chat') is internal jargon that obscures the verb, and mixing selection with recording ('with done... with turn...') makes it ambiguous whether this is a lookup or a telemetry sink. The sibling tools (models, delegate, plan) are not referenced, so differentiation is left to inference.

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

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

The only usage signal is the exclusion 'not for a chat', with no positive statement of when to call this instead of sibling tools like models or delegate. No prerequisites, ordering, or call-frequency guidance is given, and the two modes (pick a model vs. report done/turn usage) are not tied to any condition.

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

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

Annotations already declare this is a non-read-only, idempotent, non-destructive, closed-world tool, so the safety profile is covered. The description adds genuinely useful scope semantics beyond that: setting with 'app' or 'default' persists beyond the current chat. However, it says nothing about what a set returns, whether the caller can inspect which scope is active, or what happens when chat-level and app-level settings 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?

This is a single dense paragraph that rewards careful reading but front-loads the two call modes (no args to read, 'set' to write) before the scope details. The five level definitions are compact and each earns its place, and the closing note about passing the level to delegate/plan correctly routes the agent to siblings.

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 two optional params, no annotations gap, and no output schema, the description supplies everything an agent needs: the read path, the write path, scope persistence, defaults, and the instruction to follow the returned level. It also states that the learned level must be passed to delegate and plan, closing the loop to sibling tools.

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

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

Schema coverage is 100%, with 'set' bounded 1-5 and 'scope' enum-documented, so the baseline is 3. The description goes modestly further by spelling out what each numeric level means in behavioral terms and by reinforcing the scope default, though most of this restates the schema's own 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 makes clear this tool reads or writes a 1-5 'Leanfare level' that governs how much work is handed off, and it names related siblings ('Pass the level to delegate and plan'). The purpose is understandable, but it opens with the level ladder rather than a crisp verb+resource statement, so the agent must read the whole paragraph to learn that the tool doubles as getter and setter.

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 call conditions are given for both modes: call with nothing at the start of a chat to learn the level, and call with 'set' plus scope when the user says something like 'Leanfare 4'. The per-level definitions (1 'only when the user asks' through 5 'every part a model can do') effectively encode when each level should apply, and the scope default (chat) is 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=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses what is actually returned (running + last-minute ended calls, numbers only, per-kind token counts, tokens per second) and that the data is continuously changing, which is real behavioral context. It omits polling/refresh cadence and whether the window is a snapshot at call time.

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

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

Three sentences of reasonable length, with the usage trigger and the UI-rendering note in sensible positions. However, the first sentence is a dense run-on with an awkward nested parenthetical enumerating call purposes, which slows comprehension of what should be the primary statement.

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

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

With no output schema, the description carries the burden of explaining the return shape and does so thoroughly: model, purpose, running time, token kinds, tokens per second. For a zero-parameter read tool this is close to sufficient; only a note on refresh cadence or snapshot semantics 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 takes zero parameters, so the baseline of 4 applies. The description correctly frames this as an unfiltered, no-argument snapshot rather than implying any hidden filtering options.

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

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

The description names a concrete resource and scope: model calls currently running plus those that ended in the last minute, returned 'as numbers only' with model, purpose, duration and token breakdown. That is a specific, identifiable retrieval. It stops short of a 5 because the opening phrasing ('The model calls Leanfare is running right now') is grammatically tangled and it never names a sibling such as spend, report or plan_status to contrast against.

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

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

It gives explicit triggers: 'Use it when the user asks what Leanfare is doing now, or to watch a plan's parts run.' That covers the main invocation contexts clearly. There are no exclusions or named alternatives, so an agent gets positive guidance but no help deciding between this and spend/report/plan_status.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses locality ('nothing leaves it'), latency ('a few minutes'), the free cost of testing, that downloads consume the drive Ollama uses, and that nothing downloads without user consent. That is meaningful behavioral context the annotations do not carry. It stops short of describing response format or failure behavior for downloads.

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 entire definition is one long run-on sentence dense with nested parentheticals, which makes it hard to scan despite being front-loaded with the main purpose. The aside about Arena rating few small models and the 8-question test is justification rather than invocation guidance and could be compressed. Information density is high but structure is poor.

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

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

With no output schema, four actions and three optional parameters, the description covers what each action does, what suggest returns in outline, timing, and the consent gate for downloads. Coverage is broadly sufficient for correct invocation, though return shapes for status/download are only loosely sketched.

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, but the description adds two things the schema does not: that 'model' for download defaults to the best-rated suggested model, and the functional coupling between actions and parameters (test needs model, download accepts yes). That is genuine added meaning over the enum 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 a concrete resource (Ollama models on this computer) and enumerates the four actions it exposes: suggest, test, status and download. An agent can tell it is a local-model inventory/test/download tool. It does not differentiate itself from the sibling tool named 'models', leaving potential overlap ambiguous.

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

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

Each action carries an explicit use case: 'suggest (the default) says all this; test, with model, starts the test; status says how a test or a download goes; download asks the user...'. That is clear per-action routing guidance with a stated default. There is no explicit when-not-to-use or reference to sibling tools as 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description does add real behavioral context beyond them: results are limited to the user's ticked models, and each entry carries a USD-per-1M-token price plus an Arena rating. It does not say what happens when the user has ticked nothing or how large the result set typically is.

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

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

One compact sentence that front-loads the resource and then the payload (prices, rating). Nothing is padded, though the sentence is slightly dense and could be split to separate scope from return fields.

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

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

For a zero-required-parameter read-only lookup with no output schema, the description covers the essential questions: which models (the user's ticked, usable ones), and what comes with them (price and quality rating). Only the output shape and the provider filter are unaddressed, both minor here.

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 optional 'provider' parameter already documents its accepted values with examples. The description never mentions the provider filter, so it adds no meaning beyond 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?

The description states a concrete resource and scope: the models the user has ticked and can currently use, returned with per-1M-token USD prices and an Arena quality rating. That is specific enough for an agent to know what it gets back, though it never uses an explicit verb like 'list' and does not distinguish itself from the related 'local_model' or 'level' siblings.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as 'estimate' or 'local_model'. The agent must infer that this is the lookup step before pricing or planning, which is plausible but never 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 only say it is not read-only, open-world and non-idempotent; the description adds what actually happens: Leanfare starts local/free/paid parts on its own within the user's cap, returns only parts finishing in about 25 seconds, and a split model costing more than 40 seconds is abandoned. It also discloses pricing ("a few cents or less, $0 on free models") and the private-mode behavior of keeping every part local, none of which is inferable from 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 clause carries information, but it arrives as one dense run-on paragraph mixing the return table, the async handoff, files semantics, pricing and split modes. Semicolons do the work of structure, and key operational rules (don't re-delegate, wait 50, grade each part) are easy to miss on a first read.

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

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

For an 11-parameter orchestration tool with no output schema, the description does the heavy lifting: it sketches the returned table's columns and states the follow-up call and grading step. What it leaves thin is the level/parts interaction (only the schema spells out levels 1-4 vs level 5) and what happens when a placed part fails.

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 property descriptions already carry the run/default, files, split, checks, private and parts semantics, so most of the description's parameter prose is restatement. The genuinely additive piece is the cross-tool note that files are only measured here and read when delegate runs a part, plus that checks is once per project and replaces the prior list.

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?

"Before a task with several parts ... ask Leanfare how to split it" names the verb (split) and the resource (a multi-part task) and enumerates qualifying task types. It also separates this tool from its neighbors by naming delegate and plan_status and stating what each does instead.

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

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

It gives an explicit trigger (multi-part tasks), an explicit exclusion-by-redirect ("do not run them again with delegate"), a follow-up sequence (do your parts, then plan_status with the plan's id at wait 50), and a variant switch (split: rules when no model should be used). The only weakness is that the guidance is buried in a run-on paragraph rather than sequenced.

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 non-read-only, open-world, idempotent, non-destructive, so the description's job is to add context — and it does: background execution, dependency-ordered scheduling with answers handed downstream, immediate return, and a spending-authorization gate tied to the user's cap and monthly budget. It does not address what a repeat call does to already-finished parts despite the idempotentHint, leaving one behavioral question open.

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 action and its async nature are front-loaded in the first two clauses, and the paid-gating rules follow in logical order. Sentences are long and clause-heavy, and the closing 'The user's monthly budget in Leanfare always holds' is terse to the point of ambiguity, but nothing is clearly 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 an async, no-output-schema tool, the description correctly explains that it returns immediately and delegates result-reading to plan_status, and it covers the one risky dimension — spending. Gaps remain around failure modes, what happens if the plan is already running, and re-invocation behavior, which matter for a tool with an idempotent hint.

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

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

Schema description coverage is 100%, so the schema already documents id, paid, and yours_done thoroughly, including the enum meaning and default. The description adds workflow meaning around paid ('call again with paid yes only after they agree') and the answer-passing role of completed parts, but does not add syntax or edge-case detail beyond the schema, so this sits at the baseline-plus level.

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

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

The description opens with a specific verb and scoped resource: 'Start the parts of a plan that Leanfare runs', then narrows scope to local, free and pay-per-use models. It explicitly distinguishes itself from plan_status by naming that sibling as the way to read results, so an agent can tell the two apart without opening either schema.

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

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

It gives a clear operating context: call this to execute, then use plan_status to follow progress, and it spells out the paid-consent procedure (Leanfare asks itself where a question can be shown, otherwise the agent must ask the user and re-call with paid=yes). What's missing is any explicit 'do not call when' condition, such as what to do if the plan is already running or already finished.

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 real context beyond the annotations: finished answers are persisted to .leanfare/plans/<id>/ in a git-ignored folder, which explains why readOnlyHint is false despite this being a status check, and it documents the wait semantics (default 0, capped at 50, returns as soon as nothing is running). It does not say what happens on an unknown or stopped plan, whether answers accumulate across calls, or how peek interacts with the saved answers beyond the schema note.

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 and the text is dense rather than padded, but the wait behavior is tacked on as a mid-paragraph 'wait:' fragment that duplicates the schema's maximum of 50, and the parenthetical status list is long enough to slow scanning.

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

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

With no output schema, the description carries the return-value burden and does so by listing the possible part states and the answers of finished parts, plus the on-disk location. It covers the required id and the three optional parameters adequately; remaining gaps are edge-case behavior rather than core calling information.

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, but the description adds the default value for wait (0) and the return-early behavior ('it answers as soon as none is running'), neither of which appears in the schema, and it clarifies that folder is where the answers land. It largely restates the 50-second cap already present in the schema.

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

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

The description names the resource (each part of a plan) and enumerates the concrete states it reports (waiting, running, done, failed, yours, after yours, waiting for a yes), plus the fact that finished parts' answers are returned. That is far more specific than the title 'Progress of a plan', though the verb is implicit ('Where ... stands') and no sibling such as plan_run or plan_stop is named for contrast.

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

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

Usage is only implied: an agent can infer you call this to check a plan's progress after starting it with plan. There is no explicit statement of when to prefer this over plan_run, plan_stop, or plan, and no exclusions or prerequisites (e.g. that the id comes from plan) stated outside the schema.

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 (readOnlyHint false, idempotentHint true, destructiveHint false), the description discloses two non-obvious behaviors: completed work is preserved and a partially executed part may already have been billed. That billing side effect is exactly the kind of consequence annotations cannot express. It loses a point for not saying what the response returns or whether a stopped part can be restarted.

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

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

Two short sentences, with the core action front-loaded and the caveat about billing placed immediately after it. No filler, no restatement of the title or name.

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

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

For a single-parameter mutation with rich annotations and no output schema, the definition covers the action, the persistence semantics and the billing risk. The only real gap is the absence of any statement about the return value or whether stopping is reversible.

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

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

There is only one parameter, and its schema description ("The plan's id, from plan.") already covers it at 100% coverage. The description adds nothing about the id's format or about what happens when the id refers to a plan that is not currently running, so baseline 3 applies.

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

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

The description uses a specific verb ("Stop") on a specific resource ("the parts of a plan that Leanfare is running (plan_run)"), which lets an agent distinguish it from plan_status or plan_run. It stops just short of a 5 because "parts of a plan" is slightly ambiguous against the sibling 'plan' tool, which is the only other tool that could plausibly manage the same object.

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 implies usage, namely cancelling in-flight execution of a running plan, but it never says when to pick this over plan_run, plan_status or plan. There are no stated prerequisites (for example, a plan must be running) and no exclusions, so the agent has to infer the trigger condition.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: prompt ids like PRM-41 are permanent, and apps that support MCP Apps render the result as a card with selectable spans. It says nothing about result size, pagination, or latency for long ranges such as a year.

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 content is front-loaded, but the first sentence is a long run-on that crams seven report sections plus parenthetical asides into one breath. The enumerations earn some of their place because there is no output schema, yet the phrasing is denser and more cluttered than necessary.

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

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

With no output schema, the description carries the job of telling the agent what comes back, and it does so by listing the report's sections and the card rendering. The one-prompt drill-down mode is also covered. Minor gaps remain around result volume and behavior for very long ranges, but the picture is adequate to call the 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 description coverage is 100%, so the schema already explains app, range, and prompt, including that range and app are dropped when prompt is supplied. The description reinforces the prompt-id format and the override behavior but adds no syntax or constraint information the schema lacks. 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 names the resource concretely — a report of what Leanfare did for the user's apps over a span of time — and enumerates the sections it returns (token savings, app usage, cost, quality/grades, tokens over time, work by model, last prompts). That is far more specific than a tautology. It only weakly separates itself from siblings such as spend or models, which cover overlapping territory.

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

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

It gives an explicit trigger: use it when the user asks what Leanfare saved, how the models did, or for a report. It also states the parameter routing case (give prompt for a single prompt and its parts). It stops short of naming competing siblings like spend or models as alternatives, so the agent must infer when a narrower tool is preferable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope context — the two time windows (today and this month) and the notion of a nearest-limit per platform — but says nothing about freshness, caching, or what happens when no usage exists.

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

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

It is a single run-on sentence of roughly seventy words with nested parentheticals; the most important content (spend, budget left) is front-loaded correctly, which earns credit. But phrasing like 'the 5 hours before the week' is opaque jargon and the clause chain makes the enumeration hard to parse.

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

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

With no output schema and no parameters, the description carries the burden of telling the agent what comes back, and it does enumerate the returned sections thoroughly. Gaps remain in units, format, and undefined domain terms ('Leanfare', 'Auto', 'grades'), which a caller would need to interpret the response.

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

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

The tool takes zero parameters and the schema is fully self-describing, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not waste words restating an empty schema.

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

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

The description enumerates the resource it reports on — today's and this month's spend, budget remaining, Auto savings, top models, plan/delegate work, grades, and per-platform remaining headroom — so an agent can tell it is a spend/usage summary. However, there is no explicit verb, and the sprawl of unrelated facets (grades, platform limits, plans) blurs what the tool's core purpose is versus siblings like report, estimate, or models.

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

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

There is no statement of when to call this versus alternatives such as estimate (forecasting), report (detailed breakdown), or models (model list). The agent is left to infer that this is the daily 'dashboard' read, and nothing tells it when this tool is the wrong choice.

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?

Goes well beyond the annotations by disclosing cost ('it costs what those answers cost, $0 on free plans'), duration ('a few minutes'), the async contract (start returns at once, status carries progress/report), and a privacy guarantee ('Nothing of the user's is sent'), which is meaningful given openWorldHint=true. It also describes the report contents: lowest effort that passed plus the CLAUDE.md line.

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

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

Front-loads the purpose, then the cost/duration, then the action semantics. Dense with semicolon-chained clauses but nearly every clause earns its place. Slightly overstuffed for a single-parameter tool.

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

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

Covers the things an agent actually needs for an async, cost-incurring benchmark: what runs, how long, what it costs, how to poll, how to abort, and what the report contains; no output schema is present to carry that. Minor gaps remain (rate limits on repeated status polling, whether a stopped trial retains partial results).

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

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

Schema coverage is already 100% and the enum is documented, so the baseline is 3. The description improves on that by explaining what each action does behaviorally — start fires and returns immediately, status yields progress or the finished report, stop terminates — plus confirming status is the default.

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

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

States a concrete verb and object: measure how well 'delegate' answers on the user's models, using 10 known-answer questions at three effort levels. That is far more specific than the name 'trial' and clarifies the sibling relationship by making 'delegate' the subject under test. It stops short of naming the alternatives (grade, estimate) explicitly.

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

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

Gives a clear condition for use — 'before relying on it' — so the agent knows this is a pre-adoption check on delegate rather than a general run. It also maps the three actions to lifecycle stages (start/status/stop). No explicit when-not or named alternative is given, so it falls short of a 5.

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