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

With no annotations, the description carries the full behavioral burden. It discloses the diagnostic nature and what it reports (live backend plus connection details), which is useful, but says nothing about permissions, latency, or whether it touches the live connection, and does not explicitly confirm it is a safe non-mutating read.

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 with the core purpose front-loaded and the call condition immediately after. Zero filler; every clause adds either the what or the when.

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

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

An output schema exists, so return values need not be explained, and for a zero-parameter diagnostic tool the purpose plus call conditions are essentially complete. Only the absence of any safety/read-only framing keeps it off the top score.

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 no parameter surface for the description to document; the 100% coverage figure is trivially met. The baseline for a parameterless tool applies and nothing is misleading.

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 ('Report') and resource ('which backend is live ... and its connection details'), with parenthetical detail distinguishing real BLPAPI from mock. This is unmistakably distinct from the sibling data-retrieval tools like get_reference_data and get_historical_data.

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 clear triggering condition ('Call this first when data looks wrong') plus a second use case (confirming the server talks to a real Terminal/SAPI/B-PIPE endpoint). It stops short of naming an explicit alternative or when-not-to-use, so it falls just short of the top band.

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?

With no annotations, the description carries the full behavioral burden. It does disclose useful traits: periodicity defaults to DAILY, currency conversion is optional, and max_data_points truncates while keeping the most recent points. However, it says nothing about authentication/entitlement requirements, error behavior on invalid tickers or fields, or rate limits — significant gaps for an external data API call.

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 purpose sentence followed by a compact args list; every line adds information and nothing is repeated from the schema titles. The docstring format is conventional and 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?

An output schema exists, so return-value explanation is rightly omitted, and the parameter documentation is thorough enough to call the tool correctly. The remaining gap is environmental context — entitlement/auth needs and what happens on invalid tickers or unsupported field/periodicity combinations — for a tool with no annotations.

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 — and it does. It documents all seven parameters: example ticker and field formats, YYYY-MM-DD for both dates, the full accepted periodicity enum (WEEKLY/QUARTERLY/SEMI_ANNUALLY/YEARLY — not encoded in the schema), ISO currency conversion, and the truncation direction for max_data_points.

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 ('End-of-period historical time series') and anchors it to the underlying BLPAPI HistoricalDataRequest / BDH() call, so the agent can distinguish it from get_intraday_bars, get_intraday_ticks, and get_reference_data. It does not explicitly name those siblings or route the agent between them, which keeps it 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 only implied by the phrase 'End-of-period historical' — the agent can infer it beats the intraday siblings for daily-and-coarser time series, but no when-to-use, when-not-to-use, or alternative-routing guidance is given. There are also no stated prerequisites (e.g. resolving tickers via search_instruments, validating fields via search_fields).

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the ~140-day intraday history limit, which is a real constraint an agent cannot derive from the schema, but it omits permissions/auth requirements, rate limits, and what happens when the requested window exceeds retention.

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 front-loaded with the one-line summary followed by a compact Args block, and each line earns its place. The BLPAPI parenthetical is mildly superfluous but the overall structure is tight and scannable.

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

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

An output schema exists, so return values need not be described, and the description covers domain, retention window, and every parameter's format. It stops short of explaining multi-bar return behavior or how out-of-retention windows are handled, minor gaps for an otherwise complete definition.

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

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

Schema description coverage is 0%, so the description must compensate entirely, and it does: it gives an example ticker format for security, ISO-8601/UTC plus a concrete example for the datetimes, an explicit enum list for event_type, and a numeric range (1-1440) for interval_minutes. Every one of the five parameters is made semantically actionable in prose.

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 verb+resource ('Intraday OHLCV bars for a single security') and cites the underlying API (BLPAPI IntradayBarRequest), so the domain is unambiguous. However, it never contrasts itself with the closest sibling, get_intraday_ticks, leaving the agent to infer bars vs. ticks on its own.

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

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

Usage is only implied: the 140-day retention note and the 'single security' framing implicitly tell the agent when this tool is applicable and when a broader query is needed. There is no explicit when-to-use/when-not statement and no pointer to alternatives such as get_intraday_ticks or get_historical_data.

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?

No annotations exist, so the description carries the full burden. It discloses that output is high-volume and that the window should be constrained, which is useful behavioral context, but says nothing about permissions, rate limits, or whether the call is expensive/quota-limited beyond the volume warning.

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?

Purpose and the volume warning are front-loaded and the Args block is compact. The Args restate parameter names already present in the schema, but the added semantics (formats, enum values, defaults) earn their space.

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 explanation is unnecessary, and the description covers all parameters plus the key operational constraint. It leaves gaps on sibling selection (bars vs ticks) and auth/quota behavior, but is otherwise sufficient 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: it documents all four parameters, specifies ISO-8601 UTC for the datetimes, and enumerates valid event_types values plus the TRADE default. Only 'security' stays thin ('A single Bloomberg ticker') without noting format conventions.

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 ('Tick-by-tick data for a single security') and names the underlying BLPAPI request, which is informative. It does not explicitly distinguish itself from the sibling get_intraday_bars, an agent must infer the granularity difference.

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 a real usage caveat ('Keep the window short - ticks are voluminous'), which is genuinely actionable. However it never says when to prefer this over get_intraday_bars or what a 'short' window practically means, so the guidance 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.

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

With no annotations provided, the description carries the burden, and it partially delivers: naming BLPAPI ReferenceDataRequest and the BDP() equivalent tells an agent this is a read-only lookup with familiar semantics, and the overrides example hints at request customization. However, it says nothing about rate limits, entitlement/permission failures, or behavior when a ticker or field is invalid — meaningful gaps for a networked data tool.

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 one-line purpose before the argument list, and the Args section is tight with no filler. The wrapper prose around 'Args:' is slightly boilerplate but costs almost nothing.

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-shape explanation is correctly omitted, and the parameter documentation plus the API/BDP anchoring give an agent enough to call this correctly. Missing only edge-case behavior (invalid tickers, field entitlements, request size limits) for full completeness.

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, and it does: each of the three parameters is documented with concrete examples — ticker format ('IBM US Equity', 'SPX Index'), field mnemonics ('PX_LAST', 'NAME', 'CUR_MKT_CAP'), and an override key/value ('BEST_FPERIOD_OVERRIDE': '1FY'). It does not explain whether securities/fields are capped in count or how missing fields are reported, which holds it below 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 and resource ('Current/static data for one or more securities') and scopes it by naming the underlying API (BLPAPI ReferenceDataRequest) and the Excel equivalent BDP(). An agent can immediately distinguish this from get_historical_data, get_intraday_bars, and get_intraday_ticks by the 'current/static' qualifier.

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

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

Usage is only implied: the 'current/static' framing suggests this is for point-in-time snapshots rather than time series, which gestures toward the historical/intraday siblings. There is no explicit statement of when to use this tool versus search_fields, search_instruments, or get_historical_data, and no prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden. It names the underlying BLPAPI request, but does not state whether the call is read-only, that it requires Bloomberg entitlements/permissions, how unsaved or misspelled screen names behave, or any cost/latency profile of executing a screen.

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 one-sentence purpose followed by a short Args block for the two parameters; nothing is padded or repeated.

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

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

With an output schema present, return values need not be explained, and both parameters are documented. What is missing is operational context an agent would want before invoking a terminal-backed screen: entitlement requirements and failure behavior for an unknown screen name.

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 and largely does: screen_name is defined as the exact name as saved in the terminal, and screen_type is given allowed values (GLOBAL for Bloomberg-published, PRIVATE for your own). It omits the default (GLOBAL) explicitly, which the schema supplies.

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: 'Run a saved Bloomberg EQS equity screen', and even names the underlying API request (BLPAPI BeqsRequest). This is unmistakably distinct from the sibling data-retrieval tools like get_reference_data or get_intraday_bars.

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 phrase 'saved screen' (the screen must already exist in the terminal), but there is no explicit when-to-use/when-not guidance or routing to alternative tools. The GLOBAL/PRIVATE note is parameter semantics rather than usage 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?

No annotations are provided, so the description carries the disclosure burden. It reveals the backing API request and the resolution behavior (keyword in, mnemonic out), but says nothing about read-only nature, auth requirements, rate limits, or how many results come back by default.

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, purpose front-loaded, followed immediately by the canonical usage pattern. No filler whatsoever.

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

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

An output schema exists, so return values need no explanation, and the description covers purpose plus the key workflow handoff to get_reference_data. The only real gap is parameter-level detail, notably max_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?

Schema description coverage is 0% and there are two parameters. The phrase 'by keyword' loosely maps to query, but max_results (default 25) is entirely undocumented in both schema and description, so the description does not compensate for the coverage 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?

States a specific verb and resource: find Bloomberg field mnemonics by keyword, with the underlying service (//blp/apiflds FieldSearchRequest) named. It also distinguishes itself from the sibling search_instruments via the concrete 'market cap' -> CUR_MKT_CAP example.

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

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

Explicitly says to use this before calling get_reference_data, and the example shows the sequencing (keyword now, mnemonic later). It does not, however, state when NOT to use it or name alternative lookup paths.

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?

No annotations are supplied, so the description bears the full behavioral burden. It does disclose the backing service and the argument contract, but says nothing about authentication, rate limits, ambiguity handling for fuzzy name matches, or truncation when max_results is hit. The existence of an output schema covers return-value disclosure, which keeps this at a minimum-viable 3 rather than lower.

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?

Purpose is front-loaded in a single sentence, followed by a compact Args block with one line per parameter. There is no filler and no repetition of schema boilerplate.

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 three-parameter lookup tool with an output schema already defining the return shape, the description covers purpose, inputs, and the asset-class filter adequately. The only meaningful gap is how the returned tickers relate to the other Bloomberg tools in the same family.

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, and it does: it gives concrete query examples ('apple', 'US0378331005', 'vodafone'), enumerates the full yellow_key asset-class list that the schema leaves as a bare string, and states the valid max_results range of 1-100.

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 precise verb and resource — 'Resolve a company name, ticker fragment or ISIN to Bloomberg tickers' — plus the underlying service (//blp/instruments), and enumerates accepted input types. It stops short of distinguishing itself from the similarly named sibling search_fields, which an agent could plausibly confuse with this 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?

The use case is implied clearly (turn a free-text name or identifier into a Bloomberg ticker), and the query examples show the expected input shape. However, there is no explicit guidance on when to prefer this over search_fields or get_reference_data, nor any note about follow-up steps after obtaining a ticker.

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