AdvisorIQ

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: the result comes from the same engine as AdvisorIQ's CE calculator, unconfirmed rules are refused rather than estimated, and the response includes deadline and days left. The refusal-not-estimate guarantee is exactly the kind of trait an agent needs to trust the output.

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

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

Front-loaded with the purpose and output shape, then proceeds through the per-designation input rules and the FINRA exclusion. It is dense and somewhat run-on, but nearly every clause carries actionable information; only the engine-provenance aside is strictly optional.

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

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

With no output schema, the description still tells the agent what comes back (amount owed, deadline, days left) and what happens on unconfirmed rules. Combined with the per-designation input rules, an agent has everything needed to call it correctly across CFP, CIMA, CPWA, RMA, American College and IAR cases.

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

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

Schema coverage is 100% and already documents all three parameters, so baseline is 3. The description goes further by giving concrete period_ends syntax ({"CFP": "2027-06"} or full YYYY-MM-DD, American College forced to Dec 31) and explaining why state is only relevant for IAR, adding meaning beyond the schema text.

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 (calculate) and resource (CE owed for a set of designations) and immediately frames the output as amount + deadline + days left. It is clearly separable from the sibling ce_requirements, which returns requirements rather than computed amounts.

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

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

Explicitly states an exclusion and routes the agent elsewhere: 'FINRA is not calculated... use ce_requirements.' It also names the conditions that change the call (IAR needs the registration state, American College periods always end December 31), so an agent knows which inputs a given designation demands.

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

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

Beyond the annotations (readOnly/idempotent/non-destructive), the description discloses substantive behavior: it refuses when the rule is unconfirmed, never guesses, and explains the special FINRA Regulatory Element case where measure is 'assigned' with no hour total. It also notes aggregate returns for IWI and American College keys, which an agent could not infer from the 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 core purpose is front-loaded and every clause carries information, but the opening sentence is a dense run-on and the designation list is long, making it harder to scan. It earns its length but could be broken into shorter statements.

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

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

For a read-only, single-parameter tool with no output schema, the description fully covers what is returned (hours, minimums, cycle, carryover, sources, open questions), how aliases resolve, and the one behavioral edge case. Nothing an agent needs to invoke it correctly appears missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description materially deepens the single 'designation' parameter by listing accepted values, alias keys (IWI, American College), special values (IAR, FINRA, MQP), and their differing return semantics. That goes beyond the schema's terse enumeration.

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+resource (returns the CE rule for one designation) and enumerates exactly what the rule includes: hours/credits per cycle, category minimums, cycle setup, carryover, source URL, quote and date checked. It also differentiates from siblings by pointing to iar_ce_state for single-state queries and naming FINRA/MQP behavior.

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

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

It gives clear context and one explicit alternative ('use iar_ce_state for one state'), plus a when-not rule ('Refuses when the rule is not confirmed; never guesses'). It does not compare against ce_calculate or compliance_deadlines, so routing between the CE-related siblings is only partially covered.

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

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

Annotations already establish the safe read-only, idempotent profile. The description adds real value beyond them: each deadline carries its governing rule, official source and date-checked, and unconfirmed deadlines are withheld but counted, which tells the agent about filtering and completeness 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?

Two dense sentences with the core purpose front-loaded, followed by filter semantics. Every clause carries information, though the enum explanations make the second sentence heavy.

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 three optional parameters and no output schema, the description covers the return payload (rule, source, date checked) and the default date behavior. It is largely complete, with only sibling differentiation left unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by expanding the applies_to enum values with human meaning (ria, iar, rep, 13f, private_funds) and restating the from/to defaults, adding semantic context the raw schema does 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?

States a specific verb and resource: confirmed regulatory and CE deadlines for advisers and firms within a date range. The scope is clear, but it does not explicitly distinguish itself from siblings ce_requirements or ce_calculate, leaving the agent to infer the difference between 'deadlines' and 'requirements'.

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?

Implies usage via the default date range and the applies_to filter, and notes that unconfirmed deadlines are withheld. However, it never says when to choose this over ce_requirements or ce_calculate, so the alternative-selection guidance is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (full markdown text plus author, dates, address), which the agent cannot infer from the annotations. It does not describe error behavior for an unknown slug, which is a minor gap.

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

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

Two short sentences, front-loaded with what the tool returns and followed by the accepted input forms. Every clause carries information; there is no filler or repetition.

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

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

For a single-parameter read tool with no output schema, the description supplies everything needed: the content returned, its format (markdown), the ancillary fields (author, dates, address), and the accepted identifier forms. Safety and idempotency are covered by annotations, so nothing material is missing.

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

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

Schema description coverage is 100% and the single parameter is already documented as 'The article slug or its advisoriq.com URL'. The description restates that same fact, adding no new syntax, format examples, or constraints beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific resource (one published AdvisorIQ research article) and scope (in full, markdown, with author/dates/address), so an agent knows exactly what comes back. The word 'one' implicitly separates it from the search_research sibling, but that sibling is never named, so differentiation is inferred rather than explicit.

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

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

Usage is implied: 'Takes the slug or the article's URL' tells the agent it needs an identifier, which in practice means finding one via search_research first. However, there is no explicit when-to-use statement, no when-not-to-use, and no named alternative, so guidance remains at the implied level.

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/non-destructive, so the bar is lower. The description nonetheless adds meaningful behavior: which firms are silently out of scope, that non-independent firms require a flag and are then ranked differently, and what the response contains. It stops short of describing error behavior when a CRD is outside the directory.

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

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

Front-loaded with the core purpose and constraint, then scope caveats. The field enumeration is a long run-on list, but every item carries selection value and nothing is redundant with the schema.

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

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

With no output schema, the description compensates by enumerating the returned data comprehensively, and it closes the remaining gaps: one firm per call, how to find the CRD, and which firm classes fall outside the directory.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond it by clarifying that crd accepts either a CRD number or an AdvisorIQ page URL, and that include_bd_affiliated changes both coverage and ranking population — semantics the schema only states tersely.

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: one independent RIA firm's Form ADV figures, keyed by CRD number. It enumerates the exact data domains returned (registration, AUM, clients, ranks, yearly history), so an agent knows precisely what this tool yields versus siblings like ria_rankings or ria_market_stats.

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

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

Explicitly states the one-firm-per-call constraint and routes the agent to search_ria_firms to obtain the CRD. It also defines scope boundaries: BD-affiliated firms only appear with include_bd_affiliated, and asset managers/other firms are excluded from the directory entirely.

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 readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuine context beyond them: data provenance (NASAA map and model rule, date checked) and an explicit failure mode ("Refuses when the state's status is not confirmed"), which tells the agent to expect a no-result rather than a fabricated answer.

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 dense sentence front-loads the core question and then layers source, input, and failure behavior without filler. It is somewhat run-on, but every clause carries information the agent needs.

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

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

With no output schema, the description carries the return-value burden and does so: it enumerates the answers returned (requirement status, effective date, obligations) and notes the checked-date provenance. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema description coverage is 100% and the single parameter is fully documented there, so the baseline is 3. The description repeats the accepted input forms (two-letter code or name) without adding format, validation, or edge-case detail beyond the schema.

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

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

States a specific resource (IAR CE requirement for one state) with clear sub-questions answered: whether CE is required, since when, and what it requires. The source (NASAA's IAR CE map and model rule) and scope (one state, not all) distinguish it from the plural sibling iar_ce_states.

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 by scoping to "one US state or territory" and mentioning accepted input forms, plus a refusal condition. However, it never explicitly names the alternative for multi-state lookups (iar_ce_states) or states when this tool should be preferred, leaving the routing 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 readOnly, idempotent, non-destructive, closed-world. The description adds useful non-structured detail about what the payload contains (status buckets, counts, requirement text, open questions). No output schema exists, so this return-content disclosure carries real weight.

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

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

Two sentences, front-loaded with the resource, with the usage rule trailing. The parenthetical status enumeration is dense but each element maps to real return content, so little is wasted.

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

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

With no input parameters and no output schema, the description competently stands in for the response shape by naming the statuses and accompanying data. Adequate for a fixed, read-only reference list, though it stops short of enumerating the exact status vocabulary.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 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?

States a specific resource (NASAA's IAR CE jurisdiction map) and the fields returned: status this year, counts, requirement, open questions. It reads as the aggregate counterpart to the singular sibling iar_ce_state, though it never names that sibling explicitly.

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

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

Gives a concrete triggering question type: "Use for any 'which states require IAR CE' question." That is clear context for selection, but it does not name iar_ce_state as the single-state alternative, so the routing between the two siblings is left to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real behavioral context beyond that: results are limited to published replays, sorted newest first, and CE eligibility is conditional on a body approving a self-study version.

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

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

Two short sentences, front-loaded with the resource and sort order. The second sentence partially restates the CE condition already embedded in the first, a minor redundancy that keeps it from a 5.

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

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

For a read-only listing tool with no output schema and fully covered parameters, the description supplies the missing context: what is returned (length, sponsor, CE credit), ordering, and the CE eligibility rule. Nothing essential to correct invocation is absent.

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

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

Schema coverage is 100% and the single 'topic' parameter is documented in the schema as 'Topic name or slug.' The description adds no filtering syntax or default behavior, so the baseline of 3 applies when structured data carries the parameter 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 states a concrete resource and scope: 'Published replays of AdvisorIQ webinars, newest first,' plus what each entry carries (length, sponsor, CE credit). It is clearly distinguishable from siblings like upcoming_webinars, though it never names an alternative 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?

Usage is only implied: an agent can infer this is for browsing past/archived webinars, and the CE sentence hints at the relevance of the credit field. There is no explicit statement of when to use this versus upcoming_webinars or ce_requirements.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral context: results are a snapshot, and a prior-year comparison is available only for SEC-registered firms. It says nothing about data freshness beyond the snapshot, rate limits, or auth requirements.

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

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

Two sentences, front-loaded with the resource and scope, and every clause carries information. The first sentence is dense with nested parentheticals ('each with its definition', 'for SEC-registered firms (the history)'), which slows parsing but does not pad.

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

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

With no output schema, the description does the work of enumerating the returned figures (firms, AUM, accounts, size bands, fee types) and signaling a definition accompanies each. That is enough for an agent to call it correctly; minor gaps are data recency and result format.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: segment is clarified as narrowing to all/SEC/state-registered, and include_bd_affiliated is explained as pulling in wirehouses, broker-dealers and banks that AdvisorIQ lists separately. It also disambiguates that the year-earlier history applies only to the sec segment.

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

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

States a specific resource (aggregate RIA market figures: firm counts, AUM, accounts, size bands, fee types) and scope (US or one state), which is clearly distinct from siblings like search_ria_firms or ria_rankings. It never names those siblings, so an agent must infer the boundary between 'aggregate market stats' and 'rankings/search'.

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 how to narrow results via scope and segment and what include_bd_affiliated toggles, which implies usage context. But it gives no explicit when-to-use/when-not guidance and never points to an alternative tool for firm-level rather than aggregate data, leaving the sibling boundary implicit.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds real context beyond that: the return shape (rank, CRD, city, state, value, plus starting value for growth rankings), the cap of 100 with a default of 25, and the fallback behavior for an unknown metric. Only pagination/ordering nuances are absent.

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

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

Three dense sentences that are front-loaded with the core purpose, and every clause carries information. There is mild redundancy: the include_bd_affiliated explanation largely restates the schema description, which costs it the top mark.

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

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

With no output schema, the description correctly compensates by enumerating returned fields and the limit default/cap, and it explains the metric-discovery fallback. This is nearly complete for a 4-parameter read tool; only ordering of results and error cases beyond 'unknown metric' are left unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by illustrating what the opaque 'metric' slug means ('largest by assets', 'fastest growing') and clarifying what include_bd_affiliated covers (wirehouses, broker-dealers, banks). This adds genuine semantic value over the schema text it partly echoes.

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 exact resource (rankings of independent wealth management RIAs) and its scope (national or single-state), and explains the provenance (computed from Form ADV). It is clearly distinct from search_ria_firms or ria_market_stats, though no sibling is named explicitly, which keeps it just 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?

Usage is implied rather than stated: the agent can infer this is the tool for leaderboard-style lists. The 'unknown metric returns the list of rankings' note usefully doubles as a discovery path, and the include_bd_affiliated guidance tells when to broaden scope, but there is no explicit when-to-use-this-vs-alternatives statement.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the agent knows this is a safe, repeatable read. The description adds the useful behavioral detail of result ordering (newest first) and which fields are matched, but says nothing about pagination, result caps, or empty-query handling. With annotations carrying the safety profile, a 3 fits.

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

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

Two short sentences, front-loaded with the core purpose and scoping, followed by the follow-up action. No filler and nothing redundant with the schema or annotations.

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

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

For a single-parameter search tool with full annotation coverage, the description covers purpose, match fields, ordering, and the next step. No output schema exists, so the brief note that results are articles that feed into get_article is a reasonable substitute, though it could say more about the shape/count of results.

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

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

Only one parameter (q), and schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema's terse 'Words to search for' by specifying that matching applies to title, summary, or text, which tells the agent how the query will be interpreted. No syntax or matching-mode detail (e.g., AND vs OR) is given, so it is not a 5.

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 (search) and resource (published AdvisorIQ research articles), plus the match scope (title, summary, or text) and result ordering (newest first). This distinguishes it from sibling search tools like search_ria_firms and from get_article, which is explicitly named for reading.

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 second sentence gives a clear workflow: use this to find articles, then call get_article with a slug to read one. That names the alternative for the read step. It stops short of an explicit when-not (e.g., when to prefer search_ria_firms or other search siblings), so it is clear context rather than full exclusion guidance.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description layers on genuinely non-derivable behavior: a hard cap of 25 results, the ranking order (best name match, then assets), the fields returned per firm, and the guarantee that individual advisers are never returned. This is exactly the extra context annotations cannot supply.

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

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

Front-loaded with the action and primary lookup keys, and each subsequent sentence (return shape, exclusion list, sibling handoff) carries distinct information. It is dense but slightly long for a single paragraph; no sentence is pure filler, though the result-field list borders on redundant with what a consumer can discover.

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

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

With no output schema, the description must, and does, explain the return payload (cap, ordering, per-firm fields and page link), plus scope limitations and the CRD handoff path. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented (query key types, state, include_bd_affiliated default). The description largely restates those keys, adding only examples like 'wirehouses' and the 'within one state' phrasing, which the schema already implies.

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 (find) plus resource (independent wealth-management RIAs in AdvisorIQ's directory) and enumerates the accepted lookup keys. It also explicitly demarcates itself from get_ria_firm (lookup by CRD) and from sibling search tools, so an agent can route without opening schemas.

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

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

Gives explicit when-to-use ('Use it to get the CRD for get_ria_firm'), a conditional toggle for when to include broker-dealer affiliated firms, and negative scope ('Asset managers, private fund managers and pension consultants are not in the directory'). Nothing about selection is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive and a closed world, so the safety profile is covered. The description adds genuinely non-structured behavior: results are sorted soonest-first, times are rendered in Eastern, and 'Credit marked pending is not yet approved by the body' explains the approval-status semantics that govern filtering and output.

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

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

Two sentences, front-loaded with what the tool is and how it orders data, then filters. Dense but every clause carries payload or filtering information; only the final sentence about pending credit is slightly redundant with the earlier 'approval status' mention.

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?

No output schema exists, so the description carries the return-shape burden and does so by naming the fields returned (time in Eastern, presenters, sponsor, CE credit + approval status). Combined with the two filter semantics, an agent has everything needed to call it correctly without guessing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond raw field docs by explaining the filtering semantics — approvals-only matching for credit and the meaning of 'pending' — which changes how an agent should interpret and use the 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?

States a specific verb+resource ('Live AdvisorIQ webinars scheduled from now') plus ordering and the exact payload fields (Eastern time, presenters, sponsor, CE credit with approval status). The 'live/upcoming' framing implicitly separates it from the 'replays' sibling, so an agent can route without opening the schema.

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

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

Gives filter conditions ('Filter by topic and by credit') and clarifies that only approved credit matches return, which implies when to pass the credit filter. It never names an alternative tool (e.g. replays for past sessions) or states when not to use this tool, so usage is implied rather than explicit.

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