Bazous

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=true, so the write/mutation profile is covered structurally. The description usefully adds the four possible return statuses and the form-vs-values flow, but it never explains why the tool is flagged destructive - what existing answers may be overwritten - which is the one behavioral gap the annotation leaves 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 purpose is front-loaded in the first sentence, which is good, but the remainder is dense with backticked jargon ('Bazous', 'keyed like fields') and internal references that slow comprehension. Information earns its place, but the prose is harder to parse than it needs to be.

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

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

An output schema exists, yet the description still explains the `status` values, which is helpful. For a destructive mutation tool with two undocumented parameters (`language`, `household_id`) and no sibling differentiation, the description falls short of what an agent needs to invoke 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?

With 0% schema description coverage, the description must carry parameter meaning, and it partially does: `section` is explained via the dotted-need example and `values` is described as keyed like `fields` and saved without a form. It says nothing about `language` or `household_id`, leaving half the parameters undocumented in both places.

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

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

States a specific action chain - collect missing facts for one profile section, save them, and return updated answers - so the resource and outcome are clear. However, it never distinguishes itself from the sibling update_household_profile, leaving the agent to infer which mutation path applies.

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

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

It implies usage by explaining how `section` is derived and when each return status occurs (e.g. 'ask_in_chat': no form here), which tells the agent what to expect. But there is no explicit when-to-use versus update_household_profile or get_household_answers, so routing guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuinely new behavior: no background monitoring, no alerts, and that missing balances, dates or exchange rates prevent a confident estimate. It stops short of describing staleness or refresh timing, so it is strong but not exhaustive.

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

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

Four short sentences, front-loaded with what the tool returns and followed by routing and limitations. Each sentence carries weight; only the 'it does not monitor in the background or send alerts' clause is mildly redundant with the readOnly annotation.

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

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

With an output schema present, the description need not explain return values, and it covers purpose, routing, and data-quality caveats. The one gap is the absence of any guidance on the household_id parameter, which is the only input.

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

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

Schema description coverage is 0% for the single household_id parameter, and the description never mentions it or explains what happens when it is omitted (it is optional with a null default). The one parameter that governs which household's data is returned is left entirely to the schema's type information.

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: returns today's raw cash-safety signal plus its assumptions, computed on demand, figures only. It explicitly distinguishes itself from the sibling get_household_answers by scope (detail vs. overview/budget question), so an agent can route without opening the schema.

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

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

Gives an explicit when-to-use ('when the user asks for this detail') and names the alternative for the adjacent case ('a budget question or an overview is answered by get_household_answers'). Both the selecting condition and the alternative tool are stated, leaving nothing 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: answers are ordered most-urgent-first with a tone (risk/warn/info), figures come from the Bazous engine, `focus_missing` is set when no answer exists, and single-topic queries return one card with a picture. It does not disclose anything about rate limits or audience/permission requirements.

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 example-question paragraph is front-loaded and useful, but the second paragraph is a long run-on list of covered topics that duplicates the enum in the schema, and the third paragraph repeats topic ids already given. It is verbose for what it communicates and would benefit from trimming redundancy.

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, return-shape explanation is not strictly required, yet the description still explains the key diegetic fields (headline, answers, all_clear, missing_data, focus_missing) and how filtering by `question` changes the result. Given the tool's breadth and complexity, it is complete enough to invoke correctly, with sibling differentiation remaining the notable gap.

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

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

Schema description coverage is 0%, so the description must carry the load, and it largely does: it maps `question` to the full list of topic ids and their meaning (e.g., 'what-if (the payment the engine would move)', 'avoidable-fees (bank fees)') and states that `language` is fr/de/it/rm/en. Only `household_id` is left unaddressed, though its uuid format and optional default make it largely self-explanatory.

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 clear verb+resource (retrieve ready-made budget answers for a household) and enumerates the topics it covers, but it never distinguishes itself from close siblings like get_cash_safety_brief, get_household_snapshot, or get_upcoming_obligations, whose scopes visibly overlap with topics listed here (safety-cushion, available-now, due-before-payday). Without that differentiation an agent cannot reliably choose between 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?

It does give a usage instruction — call once, then call again with `question` set to a topic id for each follow-up — which implies a conversational loop. But 'use it for any question about the household's money' is so broad it actively competes with the sibling tools, and there is no explicit when-not or alternative routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful scope context beyond that: 'figures only, with no analysis, fees or advice' tells the agent not to expect computed insight. It does not address pagination, auth, or the empty/omitted household_id case.

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

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

Two tight sentences: the first defines the payload and its limits, the second handles routing. Nothing is redundant and the most decision-relevant content (what data, what it excludes) 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?

An output schema exists, so the description needn't explain return shapes, and it correctly focuses on scope and routing instead. The only real gap is the optional household_id's default behavior, which is unaddressed in both description and schema. For a one-parameter read tool with annotations, that is a minor omission.

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

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

Schema description coverage is 0% for the single household_id parameter, so the description must compensate and it does not mention the parameter at all. It never explains what happens when household_id is null (the default), which is the key semantic for an optional parameter. The description is entirely about output content, leaving the input contract unexplained.

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

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

The description states the concrete payload — account names, types, currencies and next-income totals — which is more specific than a restatement of the title. It also explicitly carves out a boundary against get_household_answers, so an agent can separate the two. It stops just short of a crisp verb+scope framing ('get the raw snapshot for a household').

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 positive trigger ('when the user asks for this detail') and an explicit alternative for the adjacent case ('a budget question or an overview is answered by get_household_answers'). The routing decision is fully spelled out with no inference 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 declare read-only/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the output is raw figures with no analysis, and the forecast is conditional and derived from recorded balances and events. It stops short of noting freshness or staleness of the computed forecast.

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

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

Three short sentences, front-loaded with the nature of the output ('Raw data:') before the routing guidance. Every sentence earns its place, though the leading 'Raw data' framing is slightly informal.

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

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

An output schema exists, so return values needn't be described, and annotations cover safety. The one gap is the undocumented nullable household_id, which matters for correct invocation but is otherwise a complete, well-routed definition.

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

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

The single household_id parameter has 0% schema description coverage and a null default, yet the description says nothing about it. It never explains whose household is forecast or what happens when household_id is omitted/null, which is exactly the gap the description should fill.

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 ('the conditional forecast until next payday') and scopes it as computed from recorded balances and events. It also explicitly distinguishes itself from get_household_answers, so an agent can separate the two 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?

Gives an explicit when-to-use ('when the user asks for this detail') and a when-not with the named alternative ('a budget question or an overview is answered by get_household_answers'). 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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine context: the payload is raw figures with no analysis, and it includes overdue and undated obligations plus the IDs needed downstream for simulation or payment.

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 clauses front-loaded with the returned content, then usage, then the alternative. Every sentence earns its place with no filler.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description covers scope, content, and routing. It stops short of documenting the sole input parameter, a minor gap for an otherwise coherent definition.

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?

Only one optional household_id parameter exists and schema coverage is 0%, so the description would need to compensate. It mentions IDs generally but never explains household_id's role, format, or null/default behavior, leaving the parameter semantics unaddressed.

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

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

States a specific resource (known unpaid bills, including overdue and undated) and its nature (raw data with IDs, figures only no analysis). The scope is clear, though it identifies itself mostly by what it is not (no analysis) rather than a crisp verb+resource framing.

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 to use it 'when the user asks for this detail' and routes budget/overview questions to get_household_answers. Names one alternative and the selecting condition, but does not address the other siblings (simulate_payment_change, mark_obligation_paid) it feeds IDs into.

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 past the annotations by clarifying that destructive here means irreversible bookkeeping only ('moves no money and cannot be undone in the product') and that the idempotency key makes retries safe. That materially sharpens destructiveHint=true and idempotentHint=true, though it doesn't state auth requirements or what the response returns.

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

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

Three short sentences, front-loaded with the core action and each sentence adding a distinct fact (semantics, irreversibility, usage gate). No filler or restated title text.

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

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

Output schema exists, so return values need not be covered, and the description supplies the safety and usage context an agent needs. The one notable hole is that it never says what obligation_id refers to or how to obtain it, which matters for a required-parameter mutation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only explains idempotency_key ('makes a retry safe'). obligation_id and household_id are left completely unexplained in both schema and description, which is a real gap on a required UUID.

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 ('Records that the user has paid a bill') and immediately bounds the semantics with 'moves no money', which separates it from payment-execution tools. An agent can distinguish it from siblings like simulate_payment_change or get_upcoming_obligations without opening a 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 an explicit gating condition: 'Use it only when the user says a bill is paid and asks to record it.' That is clear when-to-use guidance with an exclusion. It does not name the closest alternative (simulate_payment_change for hypothetical scenarios), 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.

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, but the description adds real value on top: it states that nothing is saved, that the stored bills remain unchanged, that `add` uses the household currency, and that the response carries `baseline`, `scenario`, and `persisted: false`. That is a meaningful disclosure of the side-effect-free and comparison semantics, though the return-key listing partly overlaps 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?

Three short sentences, front-loaded with the core purpose, then the action semantics, then the usage trigger. Every sentence carries non-redundant information and nothing is 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 five-parameter simulation tool with an output schema already present, the description covers purpose, side-effect profile, and usage routing. The remaining gap is parameter documentation for the three identifier/date fields, which is a gap the schema does not fill either.

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

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

Schema description coverage is 0%, so the description must carry the param burden. It explains the `action` enum values and notes that `amount` is in household currency, but leaves `household_id`, `payment_date`, and `obligation_id` entirely undocumented. Roughly half the semantics are inferred from the schema shape alone.

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

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

The description states a specific verb and resource — it compares a payment scenario against the current forecast without persisting. It also spells out what each action value does (`move` reassigns a date, `remove` drops a bill, `add` inserts one), and explicitly distinguishes itself from the related `get_household_answers` tool.

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

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

It gives an explicit trigger — 'Use it when the user names a payment, a date or an amount' — and routes the agent to the alternative (`get_household_answers`) for the engine's own best move. Both the when and the when-not are covered, so 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 declare idempotentHint=true and destructiveHint=true, so the safety profile is known. The description adds genuinely useful merge semantics ('Only the sections passed are replaced; the others are kept'), which explains why a destructive replace is still idempotent and partial, and confirms a return value. It stops short of stating auth or permission requirements.

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

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

Front-loaded with the save action and the concrete fact types, and the merge rule is stated plainly. 'The adviser's answers need them' is an awkward, low-value sentence that slightly blunts an otherwise tight definition.

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

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

With an output schema present, the description need not detail return values, and annotations cover the destructive/idempotent profile. The partial-update contract is the key behaviour an agent needs and it is stated; the main residual gap is that household_id and the required per-section fields are left entirely to the schema.

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?

Reported schema description coverage is 0%, so the description must carry the load; it compensates partially by mapping the four content areas (health insurance premiums, tax bill, pillar 3a contributions, contract end dates) to the parameter sections. It says nothing about household_id, value formats (base currency, YYYY-MM-DD), or the per-section required 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?

States a specific verb (Saves) and resource (profile facts), and enumerates the four content areas so an agent knows what data belongs here. It contrasts implicitly with the read-oriented siblings (get_household_snapshot, get_household_answers) by describing a save operation, but never names a sibling to disambiguate it from complete_household_profile.

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

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

Gives a usage trigger ('when the user has just given a fact that an answer needs') which is decent implied guidance for a save step in a flow. However there is no explicit when-not, no mention of alternative tools such as complete_household_profile, and the trigger is phrased in vague terms ('needs') rather than a concrete condition.

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