Server Quality Checklist

Tool Scores

• compare_symbolsB
  3.4/5.0
  Behavior2/5

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

  No annotations provided; description does not mention read-only nature, data freshness, or error behavior. Only plan limits are mentioned, which is minimal behavioral context.

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

  Conciseness5/5

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

  Two sentences, efficient, no wasted words.

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

  Completeness4/5

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

  With output schema present, the description adequately covers purpose and parameter constraints. Could mention example or typical use case but is sufficient.

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

  Parameters3/5

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

  Schema covers both parameters fully. Description repeats plan limits already in schema but adds no new parameter meaning.

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

  Purpose5/5

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

  Clearly states the tool compares multiple Saudi-listed companies using normalized financial ratios. Mentions plan limitations, distinguishing it from single-company tools like get_ratios.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use vs alternatives. Does not compare with siblings like get_ratios or get_quotes.

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

• get_financialsB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions the symbol requirement and implicitly that the tool is a read operation, but does not describe error handling, rate limits, or the nature of the response. The lack of detail on optional parameters' behavior (e.g., what happens if type or metrics are omitted) is a significant gap.

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

  Conciseness4/5

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

  The description is three sentences long and front-loaded with the core purpose. It is concise with no wasted words, but could benefit from additional structure (e.g., bullet points) to improve scanability.

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

  Completeness3/5

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

  While an output schema exists (reducing the need to describe return values), the tool has 8 parameters with many optional combinations. The description provides only high-level purpose, leaving the agent to infer when to use specific parameters. Given the tool's complexity, the description is marginally adequate but not fully complete.

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

  Parameters3/5

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

  The input schema has 100% description coverage, so the baseline is 3. The description adds minimal value beyond the schema, merely reinforcing that the symbol must be exact. It does not explain how the optional parameters (type, period, result, etc.) affect the output or provide context beyond their schema descriptions.

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

  Purpose4/5

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

  The description clearly states the tool retrieves financial statements (income, balance sheet, cash flow) and key financial data. It distinguishes itself from sibling tools like get_ratios and get_dividends by focusing on core statements, but does not explicitly contrast them, which prevents a perfect score.

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

  Usage Guidelines4/5

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

  The description specifies when to use this tool ('for income statement, balance sheet, and cash flow requests') and includes a key prerequisite ('Requires exact exchange symbol'). It also hints at fallback behavior (use companies_list for company names), but lacks explicit when-not-to-use guidance or alternatives.

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

• get_dividendsA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits. It only mentions the requirement for an exact exchange symbol, but omits other important aspects like data freshness, error handling, or output behavior.

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

  Conciseness5/5

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

  The description is two sentences with essential information, no wasted words. It is front-loaded with the purpose and usage guidance.

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

  Completeness3/5

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

  For a dividend history tool with an output schema present, the description is minimally adequate. It lacks details on return format, pagination, or date scope, but the presence of the output schema mitigates the need for some of that.

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

  Parameters3/5

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

  The input schema has 100% coverage with a detailed description for the 'symbol' parameter. The tool description adds no additional parameter semantics, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states 'Get company dividend history and yield data', specifying the verb and resource. It distinguishes from sibling tools like get_quote and get_financials, which focus on other data.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use this when the user asks for dividends or payout history', providing a clear when-to-use context. However, it does not mention when not to use or suggest alternatives.

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

• get_quotesA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It only mentions 'real-time' and 'in one call', but lacks details on data freshness limits, error handling, or that it supports up to 50 identifiers. The description is insufficient given the absence of annotations.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with the main purpose. Every word adds value, and there is no extraneous information.

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

  Completeness3/5

  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. However, the description omits key practical details like the maximum number of symbols (50) and potential differences between the two parameter options. It is adequate but not thorough.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents both parameters. The description adds no extra meaning beyond what the schema provides; it does not explain the distinction between 'identifiers' and 'symbols' or the accepted formats.

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

  Purpose5/5

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

  The description clearly states the tool gets real-time quotes for multiple Saudi stocks, with a specific verb and resource. It implicitly distinguishes from 'get_quote' (single) and other sibling tools by emphasizing batch retrieval.

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

  Usage Guidelines4/5

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

  The second sentence explicitly tells when to use it: 'when the user wants to compare several stocks or asks for prices of more than one symbol.' It provides clear context, though it doesn't mention explicit alternatives or when not to use.

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

• get_companyA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose behavioral traits like read-only nature, authentication requirements, or rate limits. The tool likely performs a safe read, but the description does not confirm this, leaving gaps.

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

  Conciseness5/5

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

  Two sentences with no unnecessary words: first describes output, second provides usage guidance. It is front-loaded and efficiently uses space.

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

  Completeness4/5

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

  An output schema exists (not shown), so return value documentation is covered. The description lists key data categories (sector, fundamentals, etc.), giving good context. Could optionally mention that it returns aggregate data, but overall complete.

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

  Parameters3/5

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

  The input schema has 100% coverage with a clear description for 'identifier' (symbol, name, alias). The tool description does not add extra parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool retrieves a company profile for a Saudi stock, listing included data types (sector, industry, fundamentals, etc.). It distinguishes itself from sibling tools like get_historical (historical data) or get_dividends (dividends only) by being comprehensive.

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

  Usage Guidelines4/5

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

  Explicitly directs when to use: 'when the user asks about a company's profile, key metrics, or detailed information.' While it doesn't list alternatives for specific queries (e.g., dividends), the sibling list helps agents infer.

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

• get_quoteA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full responsibility. It indicates a non-destructive read operation ('Get a real-time quote'), which is adequate, but it does not elaborate on any specific behavioral aspects such as data freshness or limitations.

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

  Conciseness5/5

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

  Two sentences with no unnecessary words. The description is front-loaded and efficient.

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

  Completeness4/5

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

  The description, combined with the existing output schema and sibling context, provides sufficient completeness for a simple one-stock quote tool. It could mention market hour restrictions, but it is not essential.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters having detailed descriptions. The tool description adds little beyond the schema, which is acceptable. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool gets a real-time quote for a Saudi stock and specifies the kind of information it returns (price, change, bid/ask, trading activity). It is sufficiently distinguishable from siblings like get_quotes (plural) and get_historical (time series).

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

  Usage Guidelines4/5

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

  Explicitly advises when to use: when user asks for current price, change, bid/ask, or trading activity of one stock. This provides clear context for selection among siblings, though it does not explicitly state when not to use.

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

• companies_listA
  3.9/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It only states 'Discover listed companies and symbols' without mentioning pagination, filtering behavior, or response format, which is insufficient for a list tool with 4 optional parameters.

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

  Conciseness5/5

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

  Two sentences delivering purpose and usage guidance without redundancy. Front-loaded with key action and context.

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

  Completeness3/5

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

  Despite an output schema existing, the description lacks details on pagination and result structure. It provides minimal context for a tool with 4 optional parameters, but is not critically incomplete.

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

  Parameters3/5

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

  Schema coverage is 100% with parameter descriptions already present. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses specific verb 'Discover' and resource 'listed companies and symbols', clearly distinguishing from siblings like get_company (single company) and get_quote (price data).

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

  Usage Guidelines5/5

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

  Explicitly instructs to 'Use this first to find/validate symbols before quote/company calls', providing clear when-to-use context and implicit exclusion of other tools.

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

• get_depthA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool is 'Plan/entitlement-gated by the API' and that the symbol must be exact, but it does not explicitly confirm the operation is read-only or describe error behavior. The entitlement gating adds some value beyond the schema, which only mentions level reduction, not overall access.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core purpose. Each sentence adds value: purpose, use case, prerequisite, and gating. No wasted words.

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

  Completeness4/5

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

  Given the output schema exists and both parameters are fully documented, the description covers the essential aspects: what it does, when to use it, and access restrictions. It does not address edge cases like symbol not found, but the schema's suggestion to use companies_list partially fills that gap. Overall, it is nearly complete for a 2-parameter read tool.

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

  Parameters3/5

  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 repeats 'Requires exact exchange symbol' which is already in the schema, and does not add new meaning to either parameter. The levels parameter is adequately documented in the schema.

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

  Purpose5/5

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

  The description clearly states 'Get market depth (order book) for a Saudi stock', providing a specific verb and resource. It distinguishes itself from siblings like get_quote (price) and get_trades (trades) by focusing on the order book.

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

  Usage Guidelines4/5

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

  It explicitly says 'Use this for bid/ask ladder, spread, imbalance, and liquidity at the top of book' and mentions the prerequisite 'Requires exact exchange symbol'. It does not mention when not to use or name alternatives, but the guidance is clear and actionable.

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

• get_market_summaryA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses that the tool returns summary data but does not explicitly state it is a read-only operation or address any side effects. The behavior is implied but not fully transparent.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core purpose and components, followed by a usage guide. No waste; every sentence earns its place.

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

  Completeness4/5

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

  The description is complete for a simple summary tool, covering input and output components. An output schema exists, so return values are documented elsewhere. Could mention data freshness (e.g., real-time) but is adequate.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema already describes the optional 'index' parameter with valid values. The description adds no additional meaning beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states the verb 'Get' and the resource 'current Saudi market summary' with specific included components (TASI index level, change, direction, advancing/declining counts). It distinguishes from sibling tools like get_quote or get_company which focus on individual stocks.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use this for questions about the overall market today', providing clear context. It does not mention when not to use or explicitly name alternatives, but the use case is clearly defined.

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

• get_ratiosA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It reveals tier-based limitations (Starter vs Pro), which parameters (history, period, metrics) are affected, and the scope of data (latest vs history, core vs extended). This is useful beyond 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.

  Conciseness5/5

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

  Two sentences with no wasted words. The first sentence states the primary purpose, and the second adds tier differentiation. Front-loaded and efficient.

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

  Completeness4/5

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

  Given the presence of an output schema (not shown) which likely details the return structure, the description adequately covers the tool's purpose, scope, and tier constraints. Could mention that specific ratio types are not listed, but the schema handles that.

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

  Parameters3/5

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

  Schema coverage is 100% with enums and descriptions for all four parameters. The description adds tier context but does not repeat or enhance param details. Baseline 3 is appropriate as the schema already does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool gets calculated financial ratios for one Saudi-listed company, specifying the region and constraint to a single company. It distinguishes between Starter and Pro tiers, indicating the scope of data available.

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

  Usage Guidelines3/5

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

  The description provides context about Starter vs Pro capabilities but does not explicitly guide when to use this tool over siblings like get_financials or get_historical. Usage is implied but not differentiated from alternatives.

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

• get_historicalA
  4.1/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It describes the operation as data retrieval, implying read-only, but does not mention any behavioral aspects like authentication, rate limits, or error handling. This is adequate for a simple fetch operation, but lacks detail for full transparency.

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

  Conciseness5/5

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

  Two sentences, no fluff, front-loaded with the core function and use case. Every sentence adds value.

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

  Completeness5/5

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

  With output schema present and good schema parameter descriptions, the tool description is complete. It explains what the tool does and when to use it effectively for a data retrieval tool.

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

  Parameters3/5

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

  All four parameters have descriptions in the input schema (100% coverage). The tool-level description does not add additional meaning beyond the schema, meeting the baseline. The schema descriptions are sufficiently detailed (format, defaults, example).

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

  Purpose5/5

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

  Description clearly states it gets historical OHLCV price data for a Saudi stock over a date range, and explicitly points to use cases like past prices, trends, or chart data. This distinguishes it from related tools like get_quote or get_financials.

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

  Usage Guidelines4/5

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

  Description explicitly says to use when user asks for past prices or chart data. It doesn't specify when not to use or name alternatives, but the context is clear given sibling tools like get_quote for current prices.

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

• get_market_moversA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavioral traits. It notes the output schema is stable and lists fields, but does not mention read-only nature, authentication needs, or rate limits. Adequate but not exhaustive.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences. The first sentence states the tool's purpose, the second provides usage guidance and output schema. No wasted words.

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

  Completeness4/5

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

  Given the presence of an output schema and 100% parameter coverage, the description is largely complete. It could optionally mention the default limit or index behavior, but the core information is present.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description adds no parameter information beyond what the schema already provides (e.g., types, index values). No extra semantics.

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

  Purpose5/5

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

  The description clearly states the tool retrieves market movers, a specific resource, and lists explicit use cases (top gainers, losers, volume, value leaders). It distinguishes itself from sibling tools which focus on individual symbols, sectors, or quotes.

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

  Usage Guidelines5/5

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

  The description explicitly says 'Use this for top gainers, top losers, highest volume leaders, or highest value leaders,' providing clear guidance on when to employ this tool versus siblings.

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

• get_sectorsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry full behavioral transparency. It mentions 'Returns a stable schema: index, count, items' and explains the normalization of 'NOMUC' alias, adding some context. However, it does not disclose whether the operation is read-only, what happens on errors, or describe the return structure in detail.

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

  Conciseness5/5

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

  The description is three sentences long, front-loading the purpose and usage. Every sentence adds value: the first states purpose, the second gives usage guidance, the third describes the return schema. No wasted words.

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

  Completeness4/5

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

  Given the tool has only one optional parameter and an output schema (mentioned but not detailed), the description provides adequate context. However, it could briefly explain what 'index, count, items' represent to improve completeness for an agent.

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

  Parameters4/5

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

  All parameters are documented in the schema (100% coverage). The description adds extra context beyond the schema, such as the normalization of 'NOMUC' to 'NOMU' and the stable return schema structure. This enhances understanding of parameter behavior.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Get sector performance for the Saudi market.' It identifies the specific resource (sector performance) and action (get), distinguishing it from sibling tools like get_market_summary or get_market_movers which deal with broader market data.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use this when the user asks for sector-level market moves or a sector snapshot,' providing clear context for when to invoke this tool. While it does not list exclusions or alternatives, the guidance is sufficient for a straightforward tool.

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

• get_tradesA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavioral traits. It discloses an access restriction ('Pro+ plan'), the real-time nature ('live'), and a critical input constraint ('exact exchange symbol'). While it doesn't address rate limits or error handling, these are less critical for a read-only trade tape tool, and the description offers meaningful context beyond 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.

  Conciseness5/5

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

  The description is three direct sentences, front-loaded with the primary purpose and immediately followed by use-case and constraint. Every sentence earns its place, with no filler or repetition.

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

  Completeness4/5

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

  The description covers the essential context: purpose, target audience (Saudi stocks), plan requirement, output composition (individual executions and summary), and a key usage prerequisite. An output schema exists, so detailed return fields are documented elsewhere. Minor gaps include no mention of rate limits or potential errors, but overall the description is sufficient for tool selection.

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

  Parameters3/5

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

  The input schema descriptions already provide full coverage for both parameters, including the exact-symbol requirement and an example ('2222'). The main description repeats 'Requires exact exchange symbol' but does not add new semantic meaning beyond the schema. Therefore, it does not elevate above the baseline.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('Get') and resource ('recent live trade prints for a Saudi stock'), and elaborates with 'trade tape: individual executions with price, quantity, value'. This distinguishes it from sibling tools like get_quote, which provides a single price snapshot, and get_depth, which might show order book depth.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use this for the trade tape', providing clear context for when to invoke this tool. It also highlights a key prerequisite ('Requires exact exchange symbol'), guiding the agent to resolve user-provided company names first. However, it does not mention alternatives or exclude cases where other tools would be more appropriate.

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

• get_eventsA
  4.4/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the burden for disclosure. It adds useful context: events are AI-generated, require Pro+ plan, and can be filtered by exchange symbol. This goes beyond a bare 'get events' but could still mention pagination or defaults; however, the essential behaviors are clear.

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

  Conciseness5/5

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

  Three concise sentences, front-loaded with the primary purpose. Each sentence earns its place: what it does, when to use, and how to filter. No redundancy or fluff.

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

  Completeness4/5

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

  Given the tool's simplicity (2 optional params, output schema present) and the sibling set, the description is nearly complete. It covers purpose, use case, and optional filtering. It could add an explicit alternative or exclusion, but the provided information is sufficient for an agent to select and invoke the tool correctly.

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

  Parameters4/5

  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 adds meaningful context for the symbol parameter by specifying 'exact exchange symbol' and explains that omitting it gives market-wide events. The limit parameter is left to the schema, but the description adequately supports the most common usage.

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

  Purpose5/5

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

  The description clearly states the tool retrieves 'AI-generated stock event summaries' with specific attributes (type, importance, sentiment). It distinguishes itself from sibling quote and market data tools by focusing on corporate/news events.

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

  Usage Guidelines4/5

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

  The description explicitly says to use it 'for recent corporate/news-style events' and notes the Pro+ plan requirement. It does not explicitly list excluded use cases or alternatives, but the context and sibling tool names make it evident when this tool is appropriate.

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