Antevo Wealth

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 modest context about the data sources for each kind (signal-derived vs. desk-authored) but does not disclose return format, pagination, or other behavioral traits. 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 a single, efficient sentence that front-loads the core purpose and uses a semicolon to neatly separate the two kinds. No filler or redundant wording.

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 presence of a nearly identical sibling (get_today_brief) and the unexplained 'scope' parameter, the description is incomplete. It offers no differentiation from similar tools and no explanation of the second parameter, limiting an agent's ability to use it correctly in context.

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

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

Schema description coverage is 0%, so the description must compensate. It partially explains the 'kind' parameter (only two values, market and editorial) but completely omits the 'scope' parameter, leaving its meaning and allowed values undocumented. This is a significant gap.

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

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

The description clearly states 'Today's read on markets' and elaborates on the two kinds, giving a specific resource and purpose. However, it does not distinguish this tool from the sibling get_today_brief, which appears to be a near-duplicate, leaving some ambiguity.

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 explains what each kind produces but gives no guidance on when to choose this tool over alternatives like get_market_data or get_today_brief. There are no explicit usage scenarios or exclusions, so agents must infer applicability.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the 'cross-asset' scope and 'by effect type' dimension, which is useful context beyond the annotations. However, it does not disclose behavior such as default limit handling, whether effect_type is required, or what the response structure looks like. With annotations covering the safety profile, a 3 is appropriate.

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 short sentence with no wasted words. It is front-loaded with the core concept. However, it is so brief that it sacrifices useful detail; this is under-specification rather than efficient conciseness.

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 has 2 parameters with 0% schema description coverage, no enums, and no required parameters, the description should explain what 'effect type' means, what the limit controls, and what a correlation result looks like. The output schema exists but the description still leaves the agent guessing about the meaning of the parameters and the use case. This is incomplete for a tool with this little schema documentation.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters. It mentions 'effect type' which maps to the effect_type parameter, but it does not explain the limit parameter at all. The description adds minimal meaning beyond the schema, and the limit parameter's semantics (e.g., number of results, default 30) are left entirely to the schema's default value.

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 'Cross-asset correlations by effect type' identifies a specific resource (correlations) and a dimension (effect type), but it does not clearly distinguish this from the many other get_* tools in the sibling list. It is more specific than a tautology, but an agent would still need to infer what 'effect type' means and how this differs from get_market_data or get_risk.

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 provided about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or conditions that would help an agent choose between get_correlations and the many other get_* tools. The only hint is the phrase 'by effect type', which implies a filtering dimension but does not explain when it is appropriate.

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 and idempotentHint, so the safety profile is covered. The description adds domain context (geopolitical, per-country) but does not disclose operational behavior such as how days_back affects results or any time-sensitivity.

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 with no wasted words. The essential scope and input format are conveyed compactly.

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 output schema and read-only/idempotent annotations present, return values and safety are reasonably covered. However, the description omits days_back semantics and does not explicitly route the agent away from sibling brief tools, leaving moderate ambiguity.

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%, but the description adds that iso2 is an ISO-2 country code, which is useful. It does not explain days_back, whose semantics are only inferable from the parameter name and default value.

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 identifies a specific resource scope (per-country) and content area (geopolitical drilldown), with the ISO-2 format anchoring the input. It is clear enough to distinguish from generic siblings like get_brief and get_today_brief, though it does not name them explicitly.

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

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

The 'per-country' phrasing implies the tool should be used for country-level geopolitical briefs, but there is no explicit guidance on when to choose this over alternatives such as get_brief or get_today_brief, and no exclusions are 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context such as error cases, permissions, or what 'metadata' includes, but it does not contradict 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?

One short, front-loaded sentence with no fluff. It is concise, though it could earn a higher score with more useful detail while staying compact.

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 single-document fetch with an output schema present, the description is barely adequate. Missing usage guidance and parameter semantics leave gaps, but low complexity and safe annotations reduce the burden.

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

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

Schema description coverage is 0% and the description does not explain doc_id or household_id. The parameter names are reasonably self-explanatory, but the description adds no meaning beyond the raw schema fields.

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

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

The description 'Metadata for one document' clearly identifies the verb (getting metadata) and the resource (a single document). It is distinct enough from broader list tools like list_documents, though it does not explicitly name any sibling.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as list_documents or get_entity. It only implies singular usage, with no state conditions or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description only adds the phrase 'across the household's portfolios' and provides no further behavioral context such as aggregation, data freshness, or error semantics.

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

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

The description is compact and front-loaded with the core concept, with no filler. However, it is so sparse that key scoping and parameter details are omitted, making it under-specified rather than appropriately 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?

The output schema and annotations reduce the burden, but the description still leaves unclear how the optional household_id affects the result and how this tool differs from get_portfolio_drift. This is incomplete for an agent asked to choose and invoke 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 0% and the description never mentions household_id, even though it is the only parameter. The word 'household' gives weak domain context, but the optional/default behavior of the parameter is left unexplained.

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

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

The description says the tool returns a 'drift snapshot' across the household's portfolios, which is more than a tautology but still vague. It does not define what 'drift' means or differentiate this tool from the sibling get_portfolio_drift.

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 guidance on when to use this tool versus alternatives. The existence of get_portfolio_drift as a sibling makes the lack of routing or distinguishing guidance a significant gap.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond 'in detail', which is minimal. It doesn't contradict annotations, but it also doesn't add meaningful behavioral disclosure like what fields are returned or whether the entity is a household-level aggregate.

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 extremely short (5 words), which is concise, but it's under-specified rather than efficiently informative. It front-loads the resource type but provides no actionable detail. A single sentence can be both concise and informative; this one is merely short.

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

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

The tool has an output schema, so return values are presumably documented there, and annotations cover safety. However, the description is too thin to be complete. It doesn't explain what 'entity' means in this domain, how it relates to list_households or list_family, or what makes this different from other get_* tools. For a tool with one parameter and no schema description coverage, the description should at least define the parameter's meaning.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented entity_id parameter. It does not. The description doesn't explain what entity_id refers to, how to obtain it, or what format it should be in. With only one parameter and zero schema coverage, the description's failure to clarify the parameter is a significant gap.

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

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

The description 'One household entity in detail' is vague. It identifies the resource (household entity) and implies a detail view, but it doesn't state a specific verb like 'retrieve' or 'fetch', and it doesn't distinguish this from siblings like get_facility, get_real_asset, or get_document. The title 'Get entity' is nearly identical to the description, making it close to a tautology.

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 on when to use this tool versus alternatives. The sibling list includes many get_* tools, but the description doesn't mention any of them or provide selection criteria. An agent cannot tell whether to use get_entity or get_facility without opening schemas or guessing.

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 the read-only, idempotent, non-destructive profile, so the description is not obliged to restate it. The description adds value by listing what the tool returns (financials, margins, valuation metrics, peers), but it says nothing about response volume, sizing, or other behavioral traits—acceptable at baseline given the annotations.

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

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

The description is a single dense line that front-loads the subject and uses the em dash to present the content; it is scannable and waste-free. The fragment style is acceptable, though a complete sentence with the verb would have been marginally clearer.

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

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

The output schema covers return values, but the parameter surface is entirely undocumented (0% coverage) and the description supplies zero parameter semantics, so an agent cannot correctly assemble values for fields like identifier_type, year_history, or peers. For a tool with six parameters and no parameter guidance, this is a significant completeness 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% and the description explains none of the six parameters. The agent gains no understanding of what 'peers', 'frequency', 'year_history', 'force_refresh', or 'identifier_type' accept, and the description does nothing to compensate for the undocumented parameters.

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

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

The description identifies a specific resource ('equity fundamentals') and enumerates its contents—financials, growth, margins, valuation ratios, and peers—which clearly distinguishes it from siblings like get_market_data or get_recent_results. The verb is only implied from the tool's title, and the scope is not spelled out, so it falls slightly short of a 5.

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

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

There is no guidance on when to invoke this tool versus alternatives such as get_market_data, get_recent_results, get_brief, or run_technical_analysis. The description leaves the selection decision entirely to the agent's inference from the dense sibling list.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations by warning about partial sector coverage and instructing the agent to read `coverage.classified_pct`. No contradiction with annotations 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?

The description is three tight sentences with no filler. It front-loads the core purpose, then gives the two most important behavioral caveats. Every sentence earns its place.

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

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

The description, combined with the annotations and output schema, is largely sufficient for safe invocation. It covers the main use case, the ranked-breakdown behavior, and the coverage caveat. The main missing piece is the role of `household_id`, though the parameter is optional and the output schema covers return values.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning for `value` and `dimension` by tying them to countries or TRBC sectors and by explaining the effect of omitting `value`. However, `household_id` is not explained at all, leaving a gap for a three-parameter tool.

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

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

The description clearly states the tool's function: measuring 'how much of the book sits behind a country (ISO-2) or a TRBC sector, with the positions behind it.' It identifies a specific resource, a specific dimension, and the output nature, which distinguishes it from broader siblings like get_portfolio_positions or get_country_brief.

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

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

The description gives clear usage context: it tells the agent when to omit `value` ('for the ranked breakdown') and advises always reading `coverage.classified_pct` because 'sector resolves for only part of the book.' It does not explicitly name alternatives or exclusion conditions, so it falls short of a 5, but the guidance is actionable and specific.

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 safety and idempotency. The description adds context about what the response includes (covenant headroom, pledged collateral), which is useful beyond the annotations, but does not disclose additional behavioral traits like pagination or error handling.

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 with no wasted words. It states the action and key scope efficiently, making it easy for an agent to parse quickly.

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

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

The tool is simple with one parameter and an output schema exists (though not shown). The description mentions what is included in the response, which gives some context, but it lacks details on how to obtain facility_id or handle potential edge cases. It is adequate but not comprehensive.

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

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

Schema description coverage is 0% and the description does not explain the facility_id parameter beyond implying it identifies a facility. The description provides no format, source, or usage guidance for facility_id, which is a significant gap given zero schema-level 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 clearly states the tool retrieves a single credit facility and specifies the key included details (covenant headroom, pledged collateral). This distinguishes it from sibling tools like list_facilities, which list facilities, and other get_* tools for different entities.

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 fetching details of a specific facility, and the sibling list_facilities suggests a complementary use case, but no explicit guidance or exclusions are given. An agent can infer when to use it, but it is not explicitly 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?

The annotations already signal safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description is not required to re-assert those. It adds mild context about the data being geopolitical and time-bounded, but it does not explain what the tool returns or how the look-back window behaves beyond the parameter name.

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 compact sentence with no filler and places the main concept first. It is concise, though the brevity comes at the cost of parameter guidance.

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

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

For a tool with five optional parameters and no schema descriptions, the definition does not explain how to construct a useful request or how layers/region/severity interact. The output schema removes the need to describe return values, but the lack of usage context and parameter semantics leaves the agent undersupported.

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 echoes 'layers' and 'look-back window' (days_back). Region, country, and severity are left completely unexplained, and there are no enums or format hints to compensate.

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 resource ('global geopolitical intelligence layers') and a temporal scope ('look-back window'), but it is a noun phrase with no explicit verb such as 'retrieves' or 'returns.' It does not distinguish get_geo_map from nearby siblings like get_country_brief or list_layers, so the purpose is recognizable but not precise.

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 provided about when to choose this tool over alternatives, and no exclusions or sibling references appear. The description only characterizes the data domain, leaving the agent to infer selection criteria from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that data is for the user's watchlist and signals are included 'where available', which is useful context. However, it doesn't disclose what 'market data' includes, whether it's real-time or delayed, or what the output structure looks like.

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

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

The description is a single sentence, concise and front-loaded with the resource. It earns its place by adding the watchlist scope and the 'where available' qualifier on signals. However, it could be slightly more informative without becoming verbose.

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

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

For a zero-parameter read tool with an output schema and safety annotations, the description is mostly adequate. The main gap is that it doesn't clarify the relationship to sibling tools like get_signals_recent or get_brief, which could cause an agent to pick the wrong tool. The output schema likely covers return values, so that's not a gap.

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

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

The tool has 0 parameters, so there are no parameter semantics to document. The description correctly implies the tool uses implicit context (the user's watchlist). With no parameters, the description doesn't need to explain parameter meaning, and the baseline of 4 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 specific resource ('market data') and scope ('user's watchlist'), and mentions signals. However, it doesn't clearly distinguish this from sibling tools like get_signals_recent, get_brief, or get_today_brief, which could also relate to market data or signals. The verb 'get' is generic but acceptable for a read 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?

No guidance on when to use this tool versus alternatives. With 35 sibling tools including get_signals_recent, get_brief, and get_today_brief, an agent would need to infer usage context. The description doesn't state when to prefer this over get_signals_recent or get_brief.

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 establish read-only/idempotent/non-destructive behavior, so the description's extra disclosure of FX conversion and scope composition is meaningful. It adds nuance not in the annotations without contradicting them.

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

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

Two dense sentences deliver the core behavior, scope options, defaults, and FX behavior with no filler. The colon-and-semicolon structure keeps related alternatives together.

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 two-parameter, no-required-args getter with an output schema and safety annotations, the description covers the key decision (scope) and a hidden behavior (FX conversion). Only the implicit household_id semantics keeps it from being fully self-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?

The description fully defines the 'scope' parameter's values and default. It says nothing about 'household_id', which has no schema description at 0% coverage, leaving the agent to infer that it selects the target household.

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

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

States a specific verb-resource pair: returns household net worth. The scope breakdown ('estate', 'aum', 'allocation') makes the tool's purpose concrete, though it does not explicitly contrast it with sibling get_* tools beyond being unique.

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

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

Provides clear context on how to choose scope, including which is default and what each returns. It does not enumerate when-not-to-use or name alternatives, but no sibling tool appears to duplicate net-worth functionality.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the 'open' filter, which is a behavioral detail beyond the annotations. However, it doesn't disclose any other behavioral traits like pagination or return format, so it adds only marginal context beyond the structured data.

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, tight sentence with no wasted words. It is front-loaded with the core purpose and appropriately sized for a simple read-only getter.

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

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

For a tool with an optional filter parameter, the description is incomplete. It doesn't explain what 'open' means, whether the result is a list, or how household_id affects the output. The output schema may help, but the description alone leaves critical usage details unspecified.

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

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

Schema description coverage is 0%, and the description does not mention household_id at all. While the parameter name is self-explanatory as an identifier, the description adds no meaning beyond the bare schema definition, failing to explain its purpose or optionality.

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 that the tool returns open compliance/policy breaches, which is a specific resource and aligns with the 'get' verb implied by the name. It is distinct enough from siblings like get_risk or get_unread_alerts because it targets breaches specifically, though it doesn't explicitly contrast with 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?

No guidance is provided on when to use this tool versus alternatives. The siblings include many getters with overlapping domains (e.g., get_risk, get_unread_alerts), and the description gives no criteria for selection or exclusions, leaving the agent to guess.

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

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

Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is low. The description adds a small semantic detail, 'versus its target allocation,' but does not disclose any behavioral context such as whether a target allocation must already exist.

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 short—one compact phrase with no filler. It is easy to read and likely appropriate for a simple getter, though the missing grammar makes it slightly more like a fragment than a clear sentence.

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 output schema is present and annotations cover safety, a brief description is acceptable. However, the description does not address the closely related sibling get_drift_snapshot, nor fully explain parameter roles, so if an agent encounters both tools the definition is not fully adequate on its own.

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

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

Schema description coverage is 0% and the description does not explain household_id or portfolio_id. The phrase 'portfolio versus its target allocation' implies portfolio_id identifies the portfolio being evaluated, but household_id isn't addressed, so the meaning must be inferred from parameter names 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 the tool's resource and scope: drift of a portfolio versus its target allocation. This clearly communicates what the tool produces, though it lacks a verb and doesn't distinguish it from the closely named sibling get_drift_snapshot.

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

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

The description gives no guidance on when to use this tool instead of similar siblings like get_drift_snapshot or get_portfolio_positions. There is no mention of prerequisites, exclusions, or when-not-to-use, leaving the agent to infer selection from naming alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds pagination and sorting behavior ('paginated, sorted by market value'), which is useful context beyond the annotations. It doesn't disclose details like default limit behavior or cursor semantics, but the output schema likely covers return structure.

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 front-loads the core purpose and key behaviors (household scope, pagination, sorting). Every word earns its place, and there is no redundancy or filler.

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

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

The tool has an output schema, which likely documents return values, and annotations cover safety. The description covers the essential purpose and key behaviors. However, with 0% schema description coverage and no parameter explanations, the agent may not know how to construct a valid request (e.g., what cursor format to use, whether household_id is required). The description is adequate but not complete for a 3-parameter tool with no parameter docs.

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

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

Schema description coverage is 0%, so the description must compensate for the three parameters (limit, cursor, household_id). The description only mentions 'household' and 'paginated', which hints at household_id and cursor/limit, but it doesn't explicitly explain the meaning of each parameter, the format of cursor, or the default behavior. This is a significant gap given zero schema descriptions.

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

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

The description states a specific verb and resource: 'Positions for a household, paginated, sorted by market value.' It clearly identifies what the tool returns and its scope (household positions). It doesn't explicitly distinguish it from sibling tools like get_portfolio_drift or list_accounts, but the resource 'positions' is distinct enough among the siblings.

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

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

The description implies usage context: it returns positions for a household, so an agent can infer it should be used when household positions are needed. However, it doesn't explicitly state when to use this tool versus alternatives like get_portfolio_drift or list_accounts, nor does it mention any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond 'detail' and does not disclose anything about the return shape, error behavior, or relationship to the output schema.

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

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

The description is extremely short with no wasted words, which is structurally clean. However, 'One real asset in detail' is under-specified to the point of being nearly tautological, so the brevity does not add much practical value.

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

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

Given the one required parameter, read-only annotations, and an existing output schema, the description needed only to explain what 'detail' means and which sibling to choose. It does neither, leaving the agent under-informed about how to invoke it correctly and what to expect.

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

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

Schema description coverage is 0%, so the description must compensate, but it never mentions asset_id or how to provide it. The parameter name is self-explanatory, but the agent receives no guidance on ID format, source, or meaning beyond the bare property name.

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 resource ('real asset') and that it returns detail, but lacks an explicit verb and leaves 'in detail' vague. It distinguishes itself from list_real_assets by implying a single asset, but does not differentiate it from get_real_asset_economics or other get_* 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 guidance on when to use this tool versus alternatives. It does not mention that an asset_id is required, that asset IDs might come from list_real_assets, or that get_real_asset_economics covers economic/financial detail rather than general detail.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the four output components but does not disclose operational behavior such as whether results are household-level aggregates, time-series snapshots, or based on current market data. No contradiction with annotations 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?

The description is a single succinct phrase with no filler words. The em-dash structure front-loads the domain and immediately enumerates the key metrics, making it appropriately sized for a simple getter.

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

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

The tool is simple, has one optional parameter, strong read-only annotations, and an output schema, so the description does not need to explain return values. However, the lack of any parameter guidance and no usage context leaves an agent to infer the role of household_id, making the description adequate but with clear gaps.

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

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

Schema description coverage is 0%, and the description does not explain household_id at all. The field is self-descriptive as an ID, but the description fails to clarify whether it filters to a single household, defaults to a current household, or is required for meaningful results.

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 ('real-asset economics') and specifies the output content: income, costs, net cashflow, and net yield. This distinguishes it from the sibling get_real_asset by focusing on financial metrics rather than asset details, though it does not explicitly name a sibling or state a verb beyond the tool's name.

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 guidance on when to use this tool versus get_real_asset, list_real_assets, or other financial getters. The description only states what the tool returns; it does not mention when it should be preferred or when an alternative would be more appropriate.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds the 'look-back window' concept and specifies the event types, which is useful context beyond the annotations. However, it does not disclose behavior such as default window, sorting, or handling of empty results.

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 sentence with no fluff, front-loading the key term 'Recent'. It is appropriately sized for a simple tool and contains no unnecessary words or phrases.

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

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

The tool is simple with two optional parameters and an output schema. The description provides the core purpose but omits context like what 'list-price events' mean or how to interpret results. Given the output schema and annotations, an agent might infer enough, but the description is minimal and leaves gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It hints at 'look-back window' which corresponds to days_back, but does not explain limit or the format of values. It omits that both parameters are strings and have defaults. Only one of the two parameters is partially addressed.

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 specifies the resource as 'auction-realised and list-price events' and the temporal scope 'over a look-back window', which distinguishes it from generic 'recent' tools. It lacks an explicit verb like 'get' or 'list', but the tool name and context imply retrieval. It does not explicitly differentiate from siblings like get_signals_recent, but the mention of event types provides specificity.

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 guidance on when to use this tool versus alternatives. The description is purely descriptive and does not mention conditions, exclusions, or compare to sibling tools such as get_signals_recent or get_today_brief. An agent would have to infer usage from the name and description.

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 include readOnlyHint=true and destructiveHint=false, and the description doesn't contradict them. It adds the key behavior of scope selection (household vs portfolio) and the metric types returned. It doesn't detail return structure, but output schema exists, so that's acceptable.

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

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

The description is concise, two sentences, and front-loads the core purpose. The dependent clause about metrics is efficient, and the usage guidance is integrated naturally without 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?

Given the tool has an output schema, the description provides enough context for an agent to select and invoke correctly: it states what it returns (risk metrics), how to scope it (portfolio vs household), and the optionality of portfolio_id. The sibling list is extensive, but the description distinguishes it via the risk metric focus.

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%, but the description explains the role of portfolio_id in the context of scope selection. It clarifies that portfolio_id is optional and omitting it gives household-wide results, adding meaning beyond the schema's minimal definitions. However, household_id semantics are not addressed, but that may be obvious.

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 retrieves risk metrics for either a household or a portfolio, and specifies the metrics (volatility, VaR, concentration, drawdown). The phrase 'household-wide dashboard' distinguishes it from portfolio-level queries, and the list of metrics is specific and actionable.

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

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

The description explicitly tells to omit portfolio_id for household-wide risk, which is a clear usage directive. However, it does not explicitly mention when to prefer this over siblings like get_net_worth or get_drift_snapshot, though the scope is clear.

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

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

The annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the look-back window concept, but it does not explain default behavior, timezone handling, or output limits, which are the natural next-level behavioral details.

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

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

The description is very short and front-loaded with the key domain and window concept. It is appropriately concise, but the noun-phrase structure and the omission of limit details keep it from being fully effective.

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

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

For a simple read-only tool with an output schema and safety annotations, the description is minimally viable: it names the resource and the primary parameter. However, it lacks an explicit verb, omits limit, and gives no usage context relative to similarly named siblings.

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

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

Schema description coverage is 0%, so the description must compensate for parameter documentation. It clarifies that days_back is the look-back window, but it says nothing about the limit parameter, leaving its semantics and interaction with days_back 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 clearly names the resource ('alt-asset trade signals') and the look-back window, which distinguishes it from broader siblings like get_market_data or get_recent_results. However, it is a noun phrase rather than a verb-led statement, relying on the title to imply the retrieval action.

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 such as get_market_data or get_recent_results. The description states only what the tool returns, leaving the agent to infer when it is the appropriate 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?

The annotations already communicate that this is read-only, idempotent, and non-destructive, so the description does not need to restate those traits. The description adds mild context about content ('what matters today') but does not disclose any additional behavior such as aggregation, date-range handling, or return-shape expectations. No contradiction with annotations 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?

The description is extremely short and front-loaded with the key noun phrase, containing no filler. However, it is a fragment rather than a full sentence, and some of the phrasing ('what matters today') is vague rather than informative.

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

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

Given the simple one-parameter input, the presence of an output schema, and annotations covering safety, the description is minimally adequate but not complete. It does not address when to choose this over sibling briefing tools or clarify how household_id behaves, leaving an agent to infer important usage details.

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

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

Schema description coverage is 0%, so the description needed to explain the household_id parameter. It only hints at household scope via 'household's daily briefing,' leaving the parameter's optionality, default behavior, and formatting unspecified. With one parameter and zero schema coverage, this is a meaningful gap.

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

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

The description identifies a specific resource ('the household's daily briefing') and a clear temporal scope ('what matters today'), so an agent understands it fetches today's household-level brief. It is not a tautology and is more informative than the bare tool name, though it lacks an explicit verb and does not directly contrast with sibling brief tools like get_brief or get_country_brief.

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 guidance about when to use this tool versus get_brief, get_country_brief, or get_upcoming_calendar. The phrase 'daily briefing' weakly implies a routine morning/current-day use case, but no explicit conditions, exclusions, or alternatives are given.

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

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

The annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds no extra behavioral context, such as whether alerts are sorted, limited, or paginated, or what 'unread' means operationally.

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 extremely short and free of filler, front-loading the core resource. However, the brevity comes at the cost of meaningful operational 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 simple one-parameter schema, output schema, and safety annotations, the description is minimally adequate. Still, it lacks any usage context or differentiation from the many sibling get_* tools, leaving some ambiguity for an agent selecting among them.

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

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

With 0% schema description coverage, the description should compensate by explaining the parameter. 'For the household' only weakly references household_id and does not clarify its format, optionality, or the meaning of the empty 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?

The description identifies the resource and scope: unread alerts for the household. Although it lacks an explicit verb, the title 'Get unread alerts' supplies the action, and an agent can infer that this tool fetches unread household 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?

No guidance is given on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or related sibling tools, so an agent must infer the appropriate context from the name alone.

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

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

Annotations already mark the call read-only, idempotent, and non-destructive. The description adds qualitative content that this calendar covers dividends, earnings, and macro events, and scopes it to 'the book,' which complements the safety profile. It doesn't mention any limits or dependencies, but this is acceptable given the strong 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?

Single sentence, no filler, and the content is front-loaded. It is appropriately short for a simple getter, though it reads as a fragment rather than a full instruction.

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 low-complexity optional parameters plus annotations and an output schema, the description gives the core semantics. It is missing explicit parameter behavior and sibling differentiation, but the tool is callable with defaults and its output is covered by 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 0%, and the description never mentions 'days' or 'household_id.' It provides no clue how the calendar horizon is set or how the household/book is selected, so the description adds no beyond what the bare parameter names suggest.

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 well-defined payload: upcoming dividends, earnings, and macro events scoped to the book. It lacks a clear verb like 'returns' or 'lists,' and doesn't contrast with sibling getters such as get_recent_results, but it is sufficiently specific to identify the 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?

No guidance on when to use this calendar versus alternatives like get_recent_results or get_today_brief. The description implies a use case for upcoming events but doesn't state exclusions or 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?

The annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description only adds household-scope context and no additional behavioral detail such as filtering defaults, result scope, or pagination, but it does not contradict the annotations.

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

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

The description is short but under-specified rather than genuinely concise. It has no structure that front-loads an action, scope, or key filtering behavior, and the brief sentence does not earn its place with useful operational content.

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

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

Even though the output schema and annotations cover some structure and safety, the description leaves the list behavior, filtering semantics, and sibling-tool boundaries almost entirely undocumented. The agent would have to guess what accounts are returned and how status/household_id affect the result.

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

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

With 0% schema description coverage, the description is expected to explain what status and household_id mean and how they affect the call. It only offers a weak hint that the resource is household-scoped and says nothing about status or accepted values.

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 is a noun phrase that mostly restates the resource named in the title. It does not say the tool lists anything, does not describe what accounts/custody means, and gives no way to distinguish it from sibling list_* tools.

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

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

There is no guidance about when to use this tool, what prerequisites apply, or when a sibling like list_households or list_facilities would be more appropriate. The description is not misleading, but it leaves usage entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful contextual detail about what the returned capability surface includes (the listed wealth domains). It does not go further into response shape, pagination, or operational behavior, but for a zero-parameter read-only listing tool, annotations plus scope are adequate.

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 sentence with no filler, but the parenthetical enumeration of thirteen domains is dense. It earns its place by conveying the breadth of the connector, though it could be slightly better structured. Overall it is appropriately sized for a simple meta-level listing 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?

For a zero-parameter, read-only, idempotent tool with an output schema and clear annotations, the description is sufficient. The only minor ambiguity is whether 'capabilities' refers to tool endpoints or data categories, but the domain list mitigates this. No critical information for invoking the tool is missing.

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

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

There are zero parameters and the schema is empty, so there is no parameter semantics burden on the description. The category list in the description indirectly tells the agent what kind of content to expect in results. The baseline of 4 for no-parameter tools applies here.

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

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

The description clearly identifies the resource as the Antevo Wealth connector's capability surface and specifies its full scope with an enumerated list of domains (portfolio, risk, credit, real assets, etc.). This distinguishes it from sibling tools that list specific resources like accounts, documents, or watchlists. The verb 'exposes' combined with 'whole wealth surface' makes the tool's purpose unmistakable.

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

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

The description implies this is a discovery/orientation tool by saying it exposes everything behind a single connection, but it never explicitly states when to use it versus alternatives. It does not say 'call this first to see available capabilities' or mention any conditions under which a sibling tool would be more appropriate. Usage context is only implied, not 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds a scope ('household vault') and a level of detail ('metadata'), but says nothing about filtering, pagination, default behavior, or result limits. This is a minimal scoping statement above what annotations already provide.

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

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

The description is a single concise phrase with no filler: 'Document metadata in the household vault.' It is front-loaded and easy to parse. While it may be under-specified, as a concise statement it is well structured and free of 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?

Despite having an output schema and safety annotations, the description leaves out essential context: what the filter parameters mean, how the tool relates to get_document, and what 'metadata' includes. With five optional parameters and many sibling tools, a one-line fragment is insufficient for an agent to invoke 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 0%, so the description must compensate for the five undocumented parameters. It does not explain limit, status, category, domain, or household_id, beyond a loose hint that 'household vault' relates to household_id. An agent would have to rely on parameter names and defaults alone to infer semantics.

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

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

The description names a specific resource ('document metadata') and a scope ('household vault'), which helps distinguish it from sibling tools like list_accounts or list_facilities. However, it is a noun phrase rather than an explicit action statement; the verb 'list' is only present in the tool name and title, not the description itself.

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 usage guidance is provided. The description does not state when to prefer list_documents over alternatives such as get_document, nor does it mention exclusions, prerequisites, or the appropriate context for using this tool. An agent must infer usage entirely from the name and title.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds essentially no behavioral context beyond the raw data categories returned; it does not mention pagination, defaults, filtering behavior, or access constraints.

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

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

The description is a compact single sentence with no filler words Opportunities to clarify parameter semantics were missed, but what is present is efficient and front-loaded with the core subject.

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

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

The available output schema and annotations cover return structure and read-only safety, so not all gaps are critical. But the description leaves the three optional parameters unexplained and offers no usage context, so an agent cannot confidently decide how to filter or paginate.

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

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

Schema description coverage is 0%, and the description does not explain limit, status, or household_id. The default values (100, ACTIVE, empty string) are visible in the schema but their meaning and effect are entirely undocumented. With low coverage spread across three parameters, the description needed to compensate and did not.

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

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

The description clearly identifies the resource ('Credit facilities') and lists the data fields returned (balances, limits, rates, maturities, covenants, collateral), so an agent understands what this list returns. It does not explicitly distinguish itself from the sibling get_facility, but the plural 'facilities' and list of attributes convey the list nature clearly.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_facility or list_accounts. There is no mention of filtering, prerequisites, or when this tool is appropriate, leaving the agent to infer usage from the name alone.

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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond entity composition; it does not mention filtering semantics, default behavior when household_id is omitted, or what happens if no matches exist.

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 extremely brief and easy to parse, but it is a fragment rather than a structured explanation. It earns brevity points while sacrificing the substance needed to make the tool self-describing.

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

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

The tool is simple and has an output schema, but the description omits parameter behavior and any decision guidance relative to sibling list tools. The combination of a 0% param coverage schema and a two-word description leaves meaningful gaps for an agent selecting or 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?

Schema description coverage is 0%, yet the description does not mention household_id or how it affects the result. With a single parameter and no compensating explanation, an agent cannot confidently determine what value to supply or what an omitted value means.

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 clarifies that 'family' means household entities and enumerates their composition ('people and structures'), which adds meaning beyond the title. However, it is a noun phrase rather than a statement of what the tool does, and it does not clearly distinguish this operation from siblings like list_households or list_facilities.

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 for when to use this tool versus alternatives such as list_households, list_facilities, or list_accounts. The description provides no context about typical use cases, prerequisites, or situations where another sibling would be more appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read behavior is covered. The description adds some output-oriented behavior by mentioning progress, gap, and status, but it does not disclose filtering semantics, defaults, or what is returned when no parameters are supplied.

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 phrase, front-loaded with the core noun 'Financial goals' and followed by the data attributes. Every word earns its place and no fluff is present.

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

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

For a tool that has 2 parameters with no schema descriptions and no explanations in the description, an agent cannot determine how to invoke it correctly (e.g., whether household_id must be minted from a household list, or what values include_inactive expects). The output schema exists, but the input side is left entirely to guesswork, and the complexity is not trivial enough to justify such a terse description.

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

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

Schema description coverage is 0% and the description does not explain either parameter. household_id and include_inactive are completely undocumented; the text does not even hint that household_id scopes the goals or that include_inactive controls whether inactive goals appear. The description provides zero value beyond the raw 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 identifies the resource ('financial goals') and the content orientation ('target vs current funding, progress, gap and status'), which is specific enough to distinguish it from sibling list_* tools such as list_accounts or list_households. It stops short of 5 because it does not explicitly say it returns a list of goals or state the intended scope (e.g., all goals 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?

No guidance is given on when to use this tool versus alternatives, nor when not to use it. With 34 sibling tools including similar list_* calls, an agent has no explicit context to decide when list_goals is the right choice or when to set include_inactive.

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 convey readOnly, idempotent, non-destructive behavior recognising the safe read nature of the tool. The description adds useful context about the connection to household_id and the single-household case, which goes beyond the annotations, though it does not disclose response shape or pagination 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 two sentences with no filler. The core statement is front-loaded empty and follow-up clarifies exactly when the tool is needed.

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

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

For a zero-parameter read-only list tool with an output schema, the description is nearly complete. It explains the meaning of the result set and the edge case that triggers its use. The only missing detail is what the output structure looks like, but the presence of an output schema reduces that need.

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

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

There are no parameters in the schema, so the schema provides no parameter semantics. The description compensates by explaining how the tool relates to household_id, even though household_id is not actually an input. This provides meaningful context for the tool's role, but there is little additional parameter detail to include.

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

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

The description states exactly what the tool returns: households this user belongs to, including their ids. The additional sentence about when it is needed clearly differentiates it from the broader set of list_* siblings by tying it to the household_id disambiguation use case.

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

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

The description explicitly specifies when this tool should be used: 'Needed only when they belong to more than one'. It also tells the agent when to omit the household_id parameter and that omitting it resolves to their household. This is direct guidance for selection and invocation.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no further behavioral detail (e.g., return format, ordering, absence of filtering), but it does not contradict annotations. It provides minimal context by calling itself a 'catalogue', implying a complete listing.

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

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

The description is one short sentence, front-loads the resource type, and contains no filler. It does the job at an ideal length for an input-free 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?

For a zero-parameter, read-only tool with an output schema, the description is almost complete. It would be enriched by a pointer to get_geo_map to clarify the layer names are intended as inputs to that tool, but the current text does not leave a functional gap for a competent agent.

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

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

There are no parameters, so the description does not need to explain any. The 4 is the baseline given to zero-parameter tools; the description correctly omits parameter detail.

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 noun phrase ('geopolitical map layers') and an implied verb ('catalogue'), matching the tool's name. It is distinguishable from sibling list_* tools because it names the specific resource type, though it does not explicitly reference get_geo_map as the downstream consumer.

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 guidance on when to use this tool vs. alternatives. It does not say to call it before get_geo_map, nor does it mention any exclusion such as 'if you already have a layer, call get_correlations instead'. The single sentence gives no routing help.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description's burden is low. It usefully clarifies that only published content is returned and names the content categories, without contradicting the annotations.

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

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

The description is a single compact phrase with no filler and leads with the core content categories. It is appropriately sized for a zero-parameter listing 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?

Given the empty input schema, existing output schema, and safety annotations, the description conveys the essential scope. It could include more usage guidance, but for a simple catalogue listing it is mostly 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?

The input schema has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. The zero-parameter baseline of 4 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 identifies the resource as a catalogue of published video, audio, and research notes, and the tool name supplies the 'list' verb. It is reasonably distinct from sibling list tools by content type, though it never explicitly names a sibling or states the verb itself.

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 instead of sibling tools like list_documents or list_capabilities. The phrase only implies a catalogue scope; there are no exclusions or alternative routing, which is a notable gap given the large sibling list.

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 communicate readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds a little semantic context about what counts as a real asset, but it discloses no behavioral details such as cursor-based pagination, default limits, or that the response is a list. It does not contradict the annotations.

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

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

The description is a single concise fragment with no fluffhol, and the example asset classes are useful. However, it is not a complete sentence and omits the core verb that would clarify the operation, so the conciseness comes at the cost of completeness.

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 four parameters, zero schema descriptions, and no guidance in the description, the tool is incompletely documented even though an output schema exists. An agent knows the operation is safe from annotations but cannot confidently determine how to use asset_class, cursor, or household_id, or how this list relates to get_real_asset.

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 carries the burden of explaining the parameters. It lists categories that likely correspond to asset_class values, but it never explicitly maps them to the asset_class parameter or explains limit, cursor, or household_id. The hint is useful but insufficient.

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 is a noun phrase defining the term ('property, vessels, aircraft, art and collections') rather than stating what the tool does with those assets. It restates the scope of the title without signaling that this is a paginated collection listing, and it does not differentiate from the sibling get_real_asset.

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

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

The description provides no guidance on when to call this tool versus alternatives such as get_real_asset or list_portfolio_positions. There is no mention of pagination, filtering by asset_class, or the fact that no IDs are 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that the result is a set of tracked instruments with specific attributes, but it does not disclose edge behaviors such as what happens when the optional household_id is omitted.

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 compact sentence with no filler or repeated title content. It front-loads the core subject and lists the returned attributes efficiently, making it easy to scan.

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

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

With an output schema present and rich annotations, the description does not need to explain return shapes or safety. Still, the tool has an optional household_id with a default of '', and the description does not clarify whether omitting it lists all households or a default household, which is a meaningful gap for correct invocation.

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

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

The schema has 0% description coverage, so the description must carry weight. 'The household's tracked instruments' does imply that household_id scopes the listing, and the parameter name plus default make its role reasonably clear. However, the description does not explain expected format, default behavior when omitted, or any constraints, so it only partially compensates for the missing schema descriptions.

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

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

The description states the resource ('household's tracked instruments') and the attributes returned ('price, momentum, how each leans and volatility'), so an agent can tell this is a watchlist-listing tool. It lacks an explicit verb, but the title supplies 'List,' and the content is clear. It does not explicitly differentiate from overlapping siblings such as get_market_data or run_technical_analysis, though the watchlist framing helps.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or sibling tools like get_portfolio_positions, list_accounts, or run_technical_analysis, leaving the decision entirely to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it accepts keywords, which is a behavioral nuance, but doesn't detail return structure or pagination. This is consistent with annotations, so no contradiction.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the core action and examples efficiently, making it easy 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?

An output schema exists, so return format is covered. The description doesn't mention limit behavior, search matching (exact vs fuzzy), or pagination, but for a simple lookup tool this may be adequate. It could be more complete but is not critically incomplete.

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 explain parameters. It clarifies that the 'brand' parameter can be a keyword, which adds value beyond the schema. However, the 'limit' parameter is not described at all, leaving ambiguity about its type (string) and purpose.

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 finds alt-asset indices by brand or keyword, with concrete examples (wine, watches, art, cars). This is specific and distinct from sibling tools that retrieve individual assets or list all assets, though it doesn't explicitly name alternatives.

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

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

There is no guidance on when to use this tool versus alternatives like get_real_asset or list_real_assets. The usage is only implied by the purpose, with no explicit exclusions or mention of when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool can produce a backtest, which implies simulation rather than live trading, and mentions 'any instrument' as a scope. It does not disclose behavior like force_refresh side effects, data source dependencies, or what 'regime' means, but the annotations carry the main 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 description is a single, compact sentence that front-loads the core purpose and lists the main output modes. It earns its place with no filler. It could be slightly more structured by separating the modes, but it is appropriately sized.

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

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

With 12 parameters, 0% schema coverage, and an output schema present, the description is too thin to fully guide an agent. It does not explain how analysis_mode differs from backtest, what trade_mode controls, how selected_indicators is formatted, or what the output schema contains. The presence of an output schema helps, but the input semantics are largely unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for 12 parameters, but it only mentions 'indicators', 'regime', and 'backtest' conceptually. It does not explain key parameters like analysis_mode, trade_mode, identifier_type, selected_indicators, or history_days. The description adds almost no parameter-level meaning beyond the schema's names and defaults.

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 ('run') and resource ('technical analysis') and enumerates three distinct outputs: indicator lean, regime, and full backtest. It distinguishes itself from the sibling tools, which are mostly getters/listers, by signaling an analysis action. However, it doesn't explicitly name a sibling alternative or contrast itself, so it falls just short of full differentiation.

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

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

The description implies when to use it: when a user wants technical analysis, indicator lean, regime, or a backtest. It does not state when not to use it or name alternatives like get_market_data or get_signals_recent. The context is clear enough for an agent to infer usage, but explicit guidance is missing.

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