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

With no annotations, the description carries the full burden. It does disclose useful behavior beyond the schema: results are ordered newest first and each item contains a date, title, and optional PDF link. It omits permission requirements, pagination/limit behavior, and how far back 'recent' extends.

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 followed by the return shape. No wasted words, though the line breaks make it slightly less clean than a single sentence would be.

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

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

The low-complexity surface (2 params, no output schema) means output field disclosure is helpful and mostly sufficient. However, with zero schema coverage on the parameters, the description leaves the required-call contract incomplete.

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

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

Schema description coverage is 0%, so the description must compensate, but it says nothing about the required `symbol` parameter or the `limit` control. An agent cannot tell from the description that a ticker symbol scopes the announcements or that limit caps result count.

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: retrieving recent corporate announcements for a symbol. It is clearly distinguishable from sibling tools like get_dividends or get_company_info, though it never explicitly says how it differs or which sibling to use for related 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?

No when-to-use guidance, no mention of when this is preferable to get_company_info or get_dividends, and no prerequisites. The agent must infer that this tool exists for announcement/regulatory disclosures only.

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 full behavioral burden. It discloses returned fields and a deliberate scope limitation (omits live quote), but does not state read-only safety, permission needs, or rate limits. The read-only nature is strongly implied by the 'get' verb and profile data, but not made explicit.

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 short sentences, front-loaded with purpose and return fields, then the sibling routing. Every sentence earns its place 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?

Lists return fields in lieu of an output schema, but leaves the required symbol parameter undocumented and does not compensate for the absence of annotations regarding safety or authentication. Adequate for a simple read tool, but with clear gaps.

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

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

Schema description coverage for the single required 'symbol' parameter is 0%, and the description never mentions the parameter, its format, or accepted symbol style. It therefore adds no meaning beyond what the bare input schema already provides.

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

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

States the resource ('Company profile and fundamentals') and then enumerates the specific fields returned, with 'Returns' supplying the action. It also explicitly distinguishes itself from the sibling get_quote by directing price requests elsewhere.

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 an explicit alternative for current price ('use get_quote') and explains that this tool omits the live quote to stay focused. It does not cover when to choose it over other market-data siblings like get_market_snapshot, but the primary exclusion is clear.

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

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

No annotations are provided, so the description carries the burden. It does disclose useful domain context (PSX notation, book-closure window, percentages of face value), which is genuinely helpful, but it doesn't state whether the call is read-only or what the return shape is.

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?

Compact, front-loaded with the resource and ordering, then details. No filler sentences.

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

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

The notation key is valuable for interpreting the output, but with no annotations, no output schema, and no parameter documentation, the description is only minimally adequate for an agent to call it confidently.

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 0%, so the description must compensate for both parameters. It mentions none — not even the required 'symbol' or the 'limit' default. The domain notation is helpful but doesn't explain parameter formats.

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 clear resource (dividend / payout history) and specifies ordering ('newest first'). It does not differentiate from sibling history tools like get_eod_history or get_announcements beyond the resource itself, so it lands just short of 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?

No when-to-use or when-not-to-use guidance, and no mention of alternatives. The agent must infer that this is the tool for dividend lookups.

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 burden, and it does substantial work: result ordering (newest first), retention horizon (~5 years), the fields returned (open, close, volume), the notable absence of high/low, and that indices are supported. It omits error behavior, auth/rate limits, and how limit interacts with the date clipping.

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 result shape in the first two lines, followed by the sibling escape hatch and the date/row-size practicalities. Every sentence adds information; 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 and no annotations, the description correctly fills the gap by describing returned fields, ordering, coverage horizon and date format. What remains thin is failure modes (invalid symbol, out-of-range dates) and the precise semantics of limit combined with date filtering.

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 0%, so the description must compensate and largely does: it gives the date format (YYYY-MM-DD) for start_date/end_date, an example symbol value, explains clipping semantics, and ties the limit default of 260 to roughly one trading year. The limit parameter's interaction with start/end clipping is still unstated.

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 (daily end-of-day history) with verb, scope (~5 years) and ordering (newest first). It explicitly distinguishes itself from the sibling get_ohlc_history by declaring this feed has no high/low, so an agent can route without opening either 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?

Names the alternative feed (get_ohlc_history) and the exact condition that selects it (need for daily high/low), and notes it also works for indices with a concrete symbol example. It does not address when to prefer get_quote or get_market_snapshot, so context is clear but not exhaustive.

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 burden. It discloses the returned fields (current value, day high/low, change, change %) but says nothing about whether the data is real-time or delayed, refresh/caching behavior, or rate limits, which matters for a market-data 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 sentences with zero filler; the resource and its contents are front-loaded and the alternative-tool pointer follows. Every clause earns its place.

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

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

With no output schema and no annotations, the description usefully compensates by listing the returned fields. It is missing only the data-freshness semantics an agent would want when deciding between this and live-quote siblings.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The only parameter-like detail given (passing the index name as the symbol to get_eod_history) applies to the sibling tool, not this one.

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?

It names the exact resource (all PSX indices, with examples KSE100, KSE30, KMI30, ALLSHR) and enumerates the returned fields (value, day high/low, change, change %). It explicitly separates itself from get_eod_history for historical data, so an agent can distinguish it from siblings without opening a 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?

It gives a clear routing rule with an alternative named: use get_eod_history with the index name as symbol for historical values. It does not address overlap with other siblings like get_market_snapshot or get_quote, nor when this is the wrong choice, so it stops short of full when/when-not 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?

With no annotations, the description carries the full burden and delivers real behavioral context: local tick-to-OHLCV aggregation, that 'raw' returns individual ticks potentially numbering in the thousands, the PKT timezone for timestamps, and that the newest limit bars are returned. Missing only auth/rate-limit or failure 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?

Purpose is front-loaded in the first sentence, followed by only the details an agent needs (aggregation, raw caveat, timezone, newest-N). Tight overall, with the raw-tick warning parenthetical the only slightly awkward element.

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 and no annotations, yet the description explains the return shape (OHLCV bars, newest limit, PKT HH:MM timestamps) and the data-volume risk. Sufficient for correct invocation; only symbol format and error/rate-limit behavior are 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 description coverage is 0%, so the description must compensate, and it largely does: it explains the aggregating interval values vs 'raw', clarifies limit by stating the newest limit bars come back, and implies small limits for raw. Symbol format is left to the schema/sibling search_symbols.

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 (intraday price bars) with clear scope: the current or most recent trading session. That scope implicitly separates it from get_eod_history and get_ohlc_history, though it does not name those siblings 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 implied by the 'current/most recent session' framing, and there is a practical hint to keep limit small when interval='raw'. However, it never states when to prefer this over get_ohlc_history or get_quote, nor any prerequisites, so routing remains inferential.

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 burden. It usefully discloses a result-cardinality cap ('Never returns all ~500 securities') and a hard limit ceiling (max 100), which are real behavioral constraints. It omits read-only/auth expectations, pagination, and what the breadth summary contains.

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

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

Very compact — one lead sentence plus a tight parameter gloss — and the cardinality warning is placed where it matters. The line-broken layout is slightly fragmented but there is 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 3-parameter tool with no annotations and no output schema, it covers parameter behavior well but leaves the return shape ('breadth summary') and sector-name validation unspecified. Adequate but with visible gaps for an agent deciding how to consume the result.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it defines each category value's ranking basis (top change %, bottom change %, most traded), clarifies sector is filtered by name, and reveals the max of 100 on `limit`, none of which appear in the schema. Only the default of 15 for limit is left to 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 and deliverable ('Market-wide snapshot with top movers and a breadth summary'), which is clearly distinct from single-symbol siblings like get_quote or get_indices. It does not explicitly name a sibling to route against, so it stops 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?

Gives practical usage detail on the category enum and sector filter, and warns that not all ~500 securities are returned so `limit` should be raised. However, it never states when to prefer this over get_indices, get_quote, or search_symbols — usage context is implied rather than compared.

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 at all, the description carries the full behavioral burden. It usefully discloses cost status ('only free source'), currency units (PKR), and the one-call-per-month granularity, but says nothing about rate limits, what happens for an invalid symbol/month with no data, or the shape of the returned series.

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 short sentences, front-loaded with what the tool returns, then the unique-value justification, then the alternative. No filler and nothing restsated from the schema title.

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?

There is no output schema and no annotations, so the description is the only documentation, and it does cover purpose, routing, month format, and units. However, the return format for the OHLCV series and the symbol/year parameter conventions remain undocumented, leaving real gaps for a 3-required-param data tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the month domain ('`month` is 1-12') and the price unit (PKR), but leaves `symbol` format/validation and the acceptable `year` range entirely unspecified.

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

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

The description names a specific resource and scope: 'Full daily OHLCV for a single calendar month (has daily high/low)'. It also distinguishes itself from the sibling get_eod_history, so an agent can tell the two apart without opening either 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?

It gives explicit when-to-use guidance ('Call once per month needed'), an explicit alternative for the opposite case ('for a long close-only series prefer get_eod_history'), and a unique capability statement ('the only free source of daily high/low') that explains why an agent would accept the per-month cost.

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 present, so the description carries the full burden, and it does substantial work: currency (PKR), market-hours window with timezone, and staleness semantics outside hours ('reflects the last session'). It omits auth requirements, invalid-symbol error behavior, and rate limits, but the freshness/currency disclosure is genuinely valuable context.

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, then return fields, then timing behavior, then the sibling pointer. Every sentence earns its place, though the field enumeration is dense; it is justified since no output schema exists.

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 and no annotations, the description fills both gaps by enumerating returned fields and explaining freshness behavior. What remains missing (parameter format, error handling) is minor for a single-argument read tool.

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

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

The single symbol parameter has 0% schema description coverage, so the description must compensate. It narrows valid values by domain ('PSX equity or ETF,' implicitly excluding indices) but gives no format hint, ticker examples, or case sensitivity. Partial compensation only.

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 ('Get the latest quote') and narrows the asset scope to 'a PSX equity or ETF,' then explicitly names get_indices as the tool for the adjacent case. An agent can distinguish this from sibling tools like get_intraday or get_market_snapshot from the description alone.

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

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

Gives an explicit alternative ('For an index use get_indices') and the timing condition that determines freshness (live in market hours, last session otherwise). It does not address the more likely confusion with get_intraday or get_eod_history, so routing guidance is clear but not exhaustive.

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 burden, but it does disclose useful behavior: matches are ranked with exact-symbol hits first, and sector filtering is exact-match only. It omits auth/permission needs, result count behavior, and pagination, so the disclosure is partial.

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 short, front-loaded sentences with zero filler; the priority instruction ('Use this FIRST') leads and the return-ordering note closes. 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?

No output schema exists, and the description covers the shape of results (ranked matches) and two of three parameters, which is nearly enough for a simple lookup tool. The undocumented 'limit' parameter and absent detail on result size/truncation leave a gap.

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

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

Schema coverage is 0%, so the description must compensate. It adds real meaning for 'query' (symbol or company name, with an example) and 'sector' (must be an exact sector name), but completely ignores the 'limit' parameter and its default/behavior.

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 ('Search PSX ticker symbols') and the two lookup keys (symbol or company name). It doesn't explicitly name sibling tools, but the ticker-resolution role is unambiguous against get_quote/get_company_info.

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?

Explicit 'Use this FIRST whenever you are unsure of the exact ticker' with a concrete input/output example ('Habib Bank' -> HBL) and the optional sector filter condition. No when-not guidance or named alternatives, but the primary usage moment is clearly pinned down.

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