ElkassabgiData

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

Annotations provide readOnlyHint=true; description adds value by noting the key is masked and never echoed, and explains how to configure the key.

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 with no wasted words, front-loaded with the key purpose.

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 auth status check, the description is sufficient despite lacking output schema 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?

No parameters exist (schema coverage 100%), baseline 4 applies. Description adds meaning by explaining the tool's purpose and output.

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 checks whether an API key is configured and provides instructions for adding one, distinguishing it from sibling tools that handle data retrieval.

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 verifying connection setup, but does not explicitly state when to use or not use this tool, nor mention alternatives.

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

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

The description adds value beyond the readOnlyHint annotation by explicitly stating that dates are never fabricated and that silent upstream outages show as stale. This provides honest behavioral insight into data quality and failure 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 two sentences long, front-loads the core concept ('Live per-source update status'), and wastes no words. Every phrase adds 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 that there is no output schema, the description adequately summarizes what the tool returns (last successful update, data frontier, stale/failure flags). It provides behavioral context and usage guidance, though a more detailed enumeration of return fields would make it fully complete.

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

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

The input schema already describes the parameter as 'One source id; omit for the full board' (100% coverage). The tool description repeats this in slightly different words ('per-source... omit for the full board'), adding no new semantic meaning beyond a casual tone.

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 it provides 'live per-source update status' with specific outputs: 'last successful update, data frontier, and honest stale/failure flags'. This verb+resource combination is distinct from all sibling tools, which focus on auth, economics, or family status.

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

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

The description specifies usage with 'per-source' and 'omit for the full board', giving clear context. It does not explicitly state when not to use or list alternatives, but the sibling tools are sufficiently different that no confusion arises.

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?

Reads as read-only via annotations, and the description adds real behavior beyond them: unresolved ids are 'reported, never dropped', the served URLs reflect CURRENT data rather than a frozen vintage, and the manifest is keyless while downloading the URLs requires a key. These are exactly the traits an agent could not infer from readOnlyHint.

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

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

Front-loads the core definition, then the return shape, then the freshness caveat and auth note. Dense but every clause carries information; the middle enumeration is long but earns its place by explaining the return payload in the absence of an output 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?

No output schema exists, and the description compensates by describing the return payload (per-series URLs grouped by source, attribution, licence, unresolved ids) plus freshness and auth. Nothing needed to call it 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 coverage is 100%, so baseline is 3, but the description adds meaning: it ties 'ids' to exact catalog ids from search_econ_series and clarifies that 'source' expands to every series only when the source has at most 1,000. That extra constraint goes beyond the schema string.

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 ('citable bundle manifest ... for several econ series') and pins down scope precisely: up to 50 explicit ids or every series of one small source. An agent can distinguish this from get_econ_series or list_econ_sources purely from the text.

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 clear conditions for each input mode (50 ids versus a whole small source capped at 1,000 series) and states the key requirement for the download step. It does not name a sibling alternative or an explicit when-not-to-use case, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context about API key requirement and output format (long format rows with citation/license). This goes beyond the annotation, though rate limits or error handling are 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 two sentences, front-loads the core purpose, and includes key usage guidance without any unnecessary words.

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

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

Given no output schema and 25% schema coverage, the description provides essential purpose, usage, and output format. It lacks details on default max_rows behavior and error handling, but is fairly complete for a data download 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 only 25% (only series_id described). The description adds meaning for date_from/date_to (window long series) but does not explain max_rows or date_to beyond the schema. It partially compensates for low coverage.

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 downloads an economic time series in long format with date, value, citation, and license. It distinguishes from siblings like search_econ_series and get_econ_series_metadata by focusing on data retrieval.

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 mentions the required API key and guides windowing with date_from/date_to. However, it does not provide explicit when-not-to-use or alternative tool references.

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, so the description adds value by noting 'Free, no key needed' and listing metadata fields. However, it doesn't disclose rate limits, pagination, or edge cases like non-existent series. The description is adequate given the simple read-only nature.

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 that is front-loaded with purpose and lists key fields. Every word is essential, and it avoids 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?

For a simple tool with one parameter and no output schema, the description lists metadata fields but does not specify the return format (e.g., object vs array, JSON structure). It is fairly complete for its simplicity but could still clarify the series_id format and provide usage examples.

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

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

With 0% schema description coverage, the description must provide parameter semantics. The only parameter 'series_id' is not explained at all (e.g., format, examples, how to obtain it). The description adds no meaning beyond the schema, which just lists it as a string.

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 it provides 'Full metadata for one econ series' and lists specific fields like title, frequency, geography, etc. It distinguishes from siblings like 'get_econ_series' (which likely returns data values) and 'search_econ_series' (searching).

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 mentions it's 'Free, no key needed,' which is helpful for usage context. It implies this tool is for metadata rather than data values, but does not explicitly state when to use vs alternatives like 'get_econ_series'.

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?

readOnlyHint=true already establishes the safe-read profile, so the bar is lower. The description adds 'read live' (freshness expectation) and 'Free' (cost context), which is genuinely useful behavioral context, but it says nothing about latency, 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?

A single front-loaded sentence with no wasted words; the scope (HF, Econ, IP) and content (headline stats, currency) come first. The dash notation and abbreviations ('HF', 'IP') are slightly terse but efficient.

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

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

With no output schema, the description must convey the return shape, and it does: 'each library's headline stats and data currency'. For a simple read-only status endpoint with no parameters, that is close to enough, though it doesn't hint at structure or granularity of the returned stats.

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; the baseline for a 0-param tool is 4. The description correctly implies the call is unparameterized by describing a whole-family snapshot.

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

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

States a concrete verb+resource ('Live status of the whole ElkassabgiData family') and enumerates the scope covered (HF, Econ and IP), which sets it apart from the per-library siblings. It doesn't explicitly name the siblings it replaces (e.g., get_data_freshness, get_auth_status), so differentiation is implied rather than spelled out.

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 by 'the whole family' - a roll-up overview across all three libraries - but there is no explicit when-to-use or when-to-prefer-a-narrower-sibling guidance. Given overlapping siblings like get_data_freshness and get_auth_status, the absence of routing guidance is a real 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 only declare readOnlyHint=true, so the description carries most of the burden and delivers real value: it discloses that authentication is required and which key (ElkassabgiData), that the payload is a link rather than data, and that the academic-research notice must be relayed to the user. It stops short of covering link expiry, rate limits, or per-dataset behavior, keeping it at a strong 4 rather than 5.

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

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

Three dense sentences, each earning its place: scope and output type first, the not-returned-inline clarification second, then auth and the research notice. Information-heavy but well front-loaded, with no filler.

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

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

With no output schema, the description correctly takes on the return semantics (a download link plus instructions, fetched by the caller) and covers auth and licensing obligations. It is nearly sufficient for a 4-parameter tool, with the remaining gap being the undocumented 'quality' dataset and clean/raw version options.

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 50%: format and ticker are documented in the schema, while dataset and version are not. The description partially compensates by naming the bars-vs-variables split (mapping to dataset), but never mentions the 'quality' dataset value or the clean/raw version distinction. Satisfies the baseline but leaves two undocumented parameters 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?

States a specific verb and resource: it returns authenticated download instructions/links for HF Data Library 1-minute OHLCV bars or the 25 pre-computed academic variables. It also scopes the coverage precisely (per-ticker US stocks/ETFs from IEX HIST, 2022-03-07 onward) and implicitly separates itself from the IP-bundle sibling. An agent can tell what this returns 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?

Usage is implied rather than stated: the description explains that the file must be fetched by the caller's code rather than returned inline, which tells the agent the workflow shape. However, there is no explicit when-not-to-use guidance and no named alternative (e.g. get_ip_download_link for IP bundles), so routing still requires 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. The description adds context about the content (verbatim dictionary definitions) but no additional behavioral details beyond that.

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 wasted words. Efficiently conveys the tool's purpose and 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?

For a no-parameter tool, the description is sufficient: it specifies what is returned (definitions/formulas) and that it's free. Could be slightly more complete by noting it's static and read-only.

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?

No parameters in schema (0 params) so baseline is 4. Description doesn't need to add parameter meaning.

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

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

The description clearly states the tool provides exact definitions/formulas of 25 pre-computed academic variables, listing specific families. It is well-differentiated from sibling tools like get_hf_download_link or search_econ_series.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions it's 'Free' but lacks context for selection.

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 the description consistently builds on this by disclosing auth requirements ('Authenticated'), file delivery ('Parquet, full-history files fetched by YOUR code, not returned inline'), giving agents valuable behavioral expectations. No contradiction with annotations, and adds detail beyond them.

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

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

Three tight sentences front-load the purpose and structure surpluses well. The second sentence is slightly dense ('Parquet, full-history files fetched by YOUR code, not returned inline'), but it earns its place by disclosing fetch semantics without waste.

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 2-parameter tool with an enum and a vintage, the description covers purpose, file types, fetch behavior, and authentication in minimal space. It doesn't explain the exact contents of each file in depth, but it gives a complete enough mental model for an agent to decide which file it wants.

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 50% (vintage documented). The description compensates for the cryptic file enum by explaining what the two bundles contain ('patent-level innovation measures (citations, originality/generality...) or the assignee-year panel'), which is useful. Yet it doesn't add detail on the 'vintage' format beyond the schema's own 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?

Clear and specific: 'Authenticated download instructions for an IP Data Library bundle' names the verb, resource, and the two library variants ('patent-level innovation measures' or 'the assignee-year panel'). Distinguishes from sibling download tools via the Parquet/ElkassabgiData context.

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 through context like 'omit for the newest' and 'vintage from list_ip_bundles', and 'same ElkassabgiData key as every family library' hints at shared auth. However, it never explicitly says when to use this versus sibling downloaders like get_hf_download_link or list_ip_bundles, nor 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?

The readOnlyHint annotation already establishes this is a safe read. The description adds real behavioral context beyond the annotation: counts are computed live (not cached) and licenses are included in the output. It does not mention pagination, result size, or ordering, which is a minor gap for a list endpoint.

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

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

A single front-loaded sentence that lists the resource, the payload contents, the freshness characteristic, and the cost in one pass. No filler.

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

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

For a zero-required-param list tool with no output schema and safety covered by annotations, the description tells the agent what it will receive (sources with licenses and live counts). Only the return shape and volume details are absent, which is acceptable at this complexity.

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 'contains' parameter is documented in the schema with a case-insensitive substring example. The description adds nothing about the filter, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('List the Econ Data Library's sources') and enriches it with the content of each entry (licenses, live counts) plus the kinds of sources covered. It doesn't explicitly differentiate from siblings like search_econ_series, but no sibling overlaps this resource, so the risk of confusion is low.

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?

'Free' hints at when this is preferable to paid alternatives, and the resource-orientation implies using it to survey available sources before drilling into series. There is no explicit when-to-use statement, no prerequisites, and no named alternative.

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 the description adds value beyond that by disclosing the access profile ('free, no key needed') and the shape of the returned metadata (sizes, vintages, download paths). With no output schema, this return-content disclosure is genuinely useful. 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?

A single dense sentence that front-loads the verb and resource, then the metadata and access note. Every clause earns its place, though it is a bit packed rather than crisply segmented.

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 parameterless read-only list tool with no output schema, the description covers what is listed, the bundle contents, the metadata returned, and the access requirement. Only the relation to sibling download/link tools is left implicit.

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

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

The tool takes zero parameters, so the schema-side burden is nil and the baseline is 4. No parameter semantics are needed or missing.

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 (List) and a specific resource (IP Data Library's snapshot-pinned patent/innovation bundles), and even enumerates the bundle content (patent-level measures, assignee-year panels) plus the metadata returned (sizes, vintages, download paths). This clearly separates it from siblings like list_econ_sources and get_ip_download_link.

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 access condition 'Free, no key needed' gives useful context for whether it can be called, but there is no explicit when-to-use guidance, no stated prerequisite (e.g., call this before get_ip_download_link), and no named alternatives. Usage is only implied.

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

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

Annotations only declare readOnlyHint=true, so the description usefully adds that it is free with no key required, that it returns IDs rather than data, and that the API caps paging depth and reports when exceeded. That is meaningful behavioral context beyond the safety hint, though rate limits and result cardinality behavior are not covered.

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 paragraph that is front-loaded with what the tool searches and follows with the practical details (free, ID output, paging, language). Every clause carries information, though the parenthetical domain list is slightly ornamental.

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 stating that it returns series IDs usable with get_econ_series. Combined with paging and language notes, an agent has enough to call it correctly, though the shape of a result item is only implied.

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

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

Schema coverage is already 80%, and the description largely restates what the schema says for offset (paging) and lang (source-official translations, English fallback). It adds no new syntax or value guidance for query, source, or limit, so the baseline 3 is appropriate.

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

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

States a specific verb (Search) and resource (Econ Data Library catalog), quantifies scope (billions of series, hundreds of sources), and enumerates the domains covered. An agent can immediately tell this is a discovery/search tool distinct from the sibling get_econ_series, which it explicitly names as the consumer of its output.

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?

Makes the usage context clear (free, no key needed; results feed get_econ_series, so search here then fetch there), and explains paging via offset. It lacks explicit exclusions or a direct comparison to list_econ_sources, which an agent might reasonably consider for catalog browsing, so it stops short of a full when/when-not statement.

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