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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds functional behavioral context by explaining that the tool computes the impact on safe-to-spend and provides a recommendation, giving the agent a clearer picture of what the tool produces.

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 single, focused sentence with no wasted words. The hyphenated addition clearly explains the output value without restating the tool name or duplicating schema details.

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 a simple read-only check with three well-documented parameters, the description provides enough context: what is checked, what is affected, and the nature of the output. With no output schema, a bit more detail about the recommendation format could be useful, but it is not required for selecting and invoking the 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 input schema already provides clear, complete descriptions for all three parameters (amount, currency, description), so the description adds no extra parameter-level semantics. Baseline 3 is appropriate because the schema fully carries the parameter documentation 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?

The description uses a specific verb ('Check') and a clear resource ('a specific purchase') while defining the output as impact on safe-to-spend and a recommendation. This clearly separates it from sibling tools like shelter_status and shelter_runway, which address broader or different financial questions.

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 phrasing clearly signals when to use the tool: when evaluating a specific purchase against a safe-to-spend position. It does not explicitly name alternatives or give when-not-to-use conditions, but the context is specific enough for an agent to select it over sibling tools.

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

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

Annotations include readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about 'active' alerts and the types of alerts, but doesn't disclose more behaviors beyond that. It doesn't contradict annotations, but adds limited value beyond 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 single concise sentence that clearly states the purpose and scope. It front-loads the key verb ('Get') and resource ('active financial alerts'), and includes examples of alert types. No wasted words.

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 optional parameter, no output schema), the description is adequate. It explains what the tool returns (alerts) and the filtering option. It doesn't explain any return format, but since no output schema exists, some ambiguity remains, but it's minor for a simple read operation.

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

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

Schema coverage is 100%, so the single parameter 'severity' is fully documented with an enum. The description doesn't mention the parameter, but it's not necessary because the schema is explicit. The parameter is optional and has a clear enum, so no extra explanation 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 clearly states the tool's purpose: 'Get active financial alerts' and specifies the types ('unusual spending, upcoming bills, low balance warnings'). It distinguishes from siblings like shelter_status and shelter_forecast by focusing on alerts.

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 for checking financial alerts, but does not explicitly state when to use this tool versus alternatives. It lacks 'when not to use' guidance, but the sibling list provides context. No explicit alternatives are named.

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 disclose readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating, open-ended query. The description adds examples of the type of questions (spending, bills, trends, advice) but does not disclose any limitations, response format, or potential for non-financial queries. Since annotations cover the safety profile, the additional context is modest but not contradictory.

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 one short sentence that immediately conveys the purpose. It is front-loaded with the main verb and object, followed by clarifying examples. There is no redundancy or filler, making it highly efficient 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?

For a single-parameter, read-only, open-world Q&A tool, the description provides sufficient context to understand its role. It does not mention the response format (e.g., whether the answer is text, JSON, or includes warnings), but given the simplicity and the annotations, this is not a critical gap. The tool's position among specialized siblings is clear, and the description is complete enough for an agent to select it appropriately.

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% for the single 'question' parameter, which already states 'A natural-language question about your finances.' The description adds value by providing concrete examples of query categories (spending, bills, trends, advice), enriching the meaning of what a valid question might contain. Though the baseline for full coverage is 3, the examples elevate understanding of the parameter's intended usage.

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 what the tool does: 'Ask Guardian AI any question about your finances.' The verb is specific ('ask'), the resource is identified ('Guardian AI', your finances), and the examples (spending, bills, trends, advice) outline the scope. It also naturally distinguishes itself from sibling tools, which are more specialized (e.g., shelter_status, shelter_runway), by positioning this as a general-purpose assistant.

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 the tool is for general finance questions, but it does not explicitly say when to use it over the specialized sibling tools (e.g., shelter_status for status, shelter_forecast for forecasts). The phrase 'any question' suggests a fallback, but no alternative tools are mentioned or excluded. Usage context is thus implied rather than 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond that, such as what output to expect, and mostly restates purpose rather than disclosing additional behavior.

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

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

The description is one concise, front-loaded sentence that states the action and scope immediately. Every word contributes, and there is no filler or redundant restatement of the tool name.

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

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

This is a low-complexity tool with one parameter and rich safety annotations, so the description is largely sufficient for an agent to invoke it correctly. The only minor gap is that with no output schema, the description could clarify the form of the returned advice, though 'financial advice' reasonably implies a text 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 schema fully describes the single topic parameter with an enum and description, so baseline is 3. The description lists most enum values but omits 'general', adding little semantic value beyond what the schema already provides and potentially understating the allowed topic set.

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 action ('Get targeted financial advice') and a resource ('financial advice') with a clear topic scope. It does not explicitly differentiate from siblings like shelter_ask or shelter_coach_daily, but the 'targeted' and 'specific topic' framing gives a solid sense of purpose.

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 conveys clear usage context: use this tool when you need advice focused on one listed financial topic. It does not name alternatives or state when not to use it, but the explicit topic list effectively scopes its appropriate use.

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 non-destructive behavior, lowering the bar for additional disclosure. The description adds that the tip is personalized and based on recent spending, which is a useful data-dependency signal, but it does not explain behavior when spending data is unavailable or what the response contains.

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

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

The description is one clear, front-loaded sentence with no filler, redundancy, or unnecessary 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?

For a simple read-only tool with strong annotations and one well-documented optional parameter, the description covers the core behavior adequately. It omits mention of the optional category parameter's effect and the exact return format, but the schema covers the parameter and 'tip' reasonably implies the output.

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 fully covers the single optional parameter with a clear enum and description, so the description does not need to repeat it. The description adds no category-specific semantics beyond what the schema already provides.

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 pair ('Get today's personalized financial coaching tip') and clarifies it is based on recent spending. However, it does not explicitly distinguish this from sibling tool shelter_coach_advice, which may overlap in purpose.

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

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

No guidance is given about when to use this tool versus alternatives. There is no mention of exclusions, conditions, or how it differs from shelter_coach_advice or other coach-related tools.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, indicating a safe, non-mutating read. The description adds that it returns a natural-language summary, which is useful but does not add deeper behavioral context beyond what annotations provide. It doesn't mention any auth or rate limits, but with such strong annotations, the baseline for transparency is met.

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 single, clear sentence that directly states the tool's purpose. It is front-loaded and contains no extraneous information. Every word 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 tool's simplicity (1 optional parameter, 100% schema coverage) and strong annotations (read-only, idempotent), the description is adequately complete for an agent to invoke it. However, it does not elaborate on what the summary includes or how it relates to sibling tools, but the output is presumably just a summary string, so additional detail might be unnecessary.

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 the only parameter 'detail' fully described in the schema ('Level of detail — "summary" for a brief overview, "full" for comprehensive context'). The description does not add additional parameter semantics beyond what the schema already provides, 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?

The description clearly states the tool's purpose: to get a natural-language summary of the user's financial situation for conversation context. It uses a specific verb (get) and resource (financial situation summary), and the title 'Financial Context' reinforces this. It does not explicitly distinguish from siblings, but the purpose is distinct enough given the sibling names (e.g., shelter_status, shelter_runway) that it stands alone.

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

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

The description implies usage as conversation context, but does not explicitly state when to use it over siblings. It mentions 'for use as conversation context,' which suggests it is for generating context before responding to user queries, but no exclusions or alternatives are given. The sibling tools like shelter_status are likely more specific, but the description does not guide the agent to prefer this tool for general context vs. specific 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds behavioral context that this is a 'verified' and 'canonical' view, implying data quality and authoritative sourcing, which goes beyond the structured hints.

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 single, front-loaded sentence that conveys the core purpose without redundancy. Every word contributes meaningful information, making it highly concise and well-structured.

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

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

For a simple read-only forecast tool with one parameter, the description provides sufficient context: it indicates the view's verification and canonical status. However, it does not describe the return format or specific data fields, which might be expected without an output 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?

Schema description coverage is 100%; the single parameter 'days' has a const 14 and its own description. The tool description merely repeats the '14-day' aspect without adding further semantics or contextual detail 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 provides a verified 14-day view of a canonical 30-day balance forecast. It identifies the specific resource (balance forecast) and scope (14 days), but does not explicitly differentiate from sibling tools like shelter_runway or shelter_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?

No explicit guidance is provided on when to use this tool versus sibling tools. The description implies it is a verified canonical view, but lacks direct alternatives or exclusions, leaving the agent to infer usage context.

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 examples of opportunity types (subscriptions, bills) which give some content insight, but no further behavioral traits like pagination or filtering behavior are described. The addition is minimal, so a moderate score is warranted.

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 one short sentence (12 words), front-loaded with the core action, and every word contributes value. There is no redundant phrasing or unnecessary 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 simplicity (1 optional param, no output schema, read-only annotations), the description covers the essential purpose and scope. However, with multiple sibling tools, a brief note on when to use this versus others would increase completeness, but it is not critical for this straightforward read-only 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 input schema fully documents the single optional 'category' parameter with an enum and a clear description ('Filter opportunities by category'). The tool description does not add any extra meaning beyond the schema, so the baseline score 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 clearly states 'Find savings opportunities' and lists concrete examples (unused subscriptions, negotiable bills, spending patterns), specifying the resource and scope. It is distinct from sibling tools like shelter_status or shelter_forecast, which do not overlap in intent.

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 priority of finding savings opportunities is clear from the wording, but no explicit exclusions or alternatives are mentioned. Given the many siblings, some guidance on when to choose this tool over others would strengthen it, yet the context is clear enough for this simple use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to restate these. It adds the context of daily budget and payday, which is useful, but it doesn't disclose any additional behavioral traits such as how the breakdown works or if there are any assumptions about spending. The description is consistent 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 very concise, using an em-dash to provide a compact summary in one line. It gets to the point without fluff. It could be slightly more structured, but for a simple tool it's efficient.

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

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

For a simple read-only tool with one optional parameter, the description provides enough context. The annotations cover safety, and the parameter is clear. The output is not detailed, but given the simplicity, it's adequate.

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 only parameter, includeBreakdown, is well-documented in the schema with a clear description. The tool description does not need to add more since schema coverage is 100%. However, the description could mention how the breakdown affects the output, but that's optional.

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's purpose: calculating how many days until money runs out, with a summary of budget, payday, and safe-to-spend. It distinguishes from siblings like shelter_status and shelter_forecast by focusing on the cash runway metric. However, it could be more specific about the output being a number of days or a time period.

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 for financial planning (daily budget, next payday, safe-to-spend) but does not explicitly state when to use this vs. alternatives like shelter_forecast or shelter_affordability. No direct comparison or exclusion criteria are provided.

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. The description adds useful context by framing the call as a snapshot and listing the exact categories returned, which helps the agent set expectations about the response. 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 one clear, front-loaded sentence. The em-dash list efficiently conveys scope without filler, and every phrase adds useful information.

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

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

For a simple read-only status tool with one optional parameter, no output schema, and strong annotations, this description is sufficiently complete. It conveys what the snapshot contains, though it does not describe output format or the caching/refresh behavior in prose; the schema covers refresh adequately.

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% for the single optional refresh boolean, so the schema already fully documents the parameter. The description's 'snapshot' wording indirectly relates to caching, but it adds no parameter-specific detail beyond what the schema provides.

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 ('Get') and resource ('financial status'), then enumerates concrete components: safe-to-spend, balances, upcoming bills, health score. The word 'snapshot' clearly distinguishes this current-state tool from outcome-focused siblings like shelter_forecast and shelter_runway.

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

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

Usage is only implied: the agent can infer this is for pulling a current financial status snapshot. However, the description gives no explicit when-to-use guidance or alternatives, despite many adjacent sibling tools such as shelter_forecast, shelter_alerts, and shelter_affordability.

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