Server Quality Checklist

Tool Scores

• market_summaryC
  2.8/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 behavioral transparency burden. It communicates the output concept but says nothing about call behavior, the default exchange, time window, data source, or side effects. There is no contradiction, but the disclosure is minimal.

  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 a single sentence with no filler and a clear, front-loaded concept. Every word contributes meaning, making it extremely concise.

  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 its simplicity, the description leaves a clear gap by not explaining the exchange parameter and not guiding selection among the sibling tools. The output schema may cover return values, but the call parameter and usage context remain under-specified.

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

  Parameters1/5

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

  The schema exposes one optional exchange parameter with a default of 'dse' and has 0% schema description coverage. The description never mentions the exchange parameter, so an agent cannot learn what values are valid or how the parameter affects the summary.

  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 identifies the tool's output as market breadth counts of rose/fell/flat/never-traded shares. It is specific enough to distinguish from sibling tools like get_stock or sector_performance, though it lacks an explicit action verb and does not directly contrast with siblings.

  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?

  There is no guidance about when to use market_summary versus the ten sibling tools, nor any mention of prerequisites or exclusions. The intended use is only implied by the output definition.

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

• search_stockC
  2.8/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 the full burden of behavioral disclosure. It only says 'Find' and gives examples, without revealing details such as case sensitivity, exact matching behavior, pagination/limits, or whether the exchange parameter changes the search scope. Some behavioral expectations are implied but not explicitly disclosed.

  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 a single sentence with no filler. It front-loads the action ('Find trading codes') and uses examples to convey the substring behavior efficiently, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Although the tool is simple and has an output schema, the description omits essential context about the 'exchange' parameter and does not provide usage guidance. Given no annotations, the missing parameter explanation and lack of guidance leave the description incomplete for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain the parameters directly. It implies that 'query' is a substring, but it does not explain the 'exchange' parameter or its default value 'dse'. Since the schema provides no descriptions, the text needed to clarify both parameters, and it only partially addresses 'query'.

  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's function: 'Find trading codes containing a substring', with concrete examples such as 'BANK' or 'PHARMA'. This distinguishes it from siblings like get_stock, which likely retrieves a specific stock rather than searching by substring, though it does not explicitly name the sibling it differs from.

  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 guidance is provided on when to use this tool versus alternatives such as get_stock or top_movers. The description implies a search use case, but it does not state when to choose this tool, what limitations exist, or when another sibling 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.

• compare_exchangesB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It communicates that the tool compares prices across two exchanges and explains why that matters, but it does not disclose edge cases like companies listed on only one exchange, data freshness, or how failures are handled.

  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 core instruction is front-loaded in the first sentence. The two following sentences add useful context about dual listing and price divergence without redundancy, making the description appropriately sized and well structured.

  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?

  The description provides helpful context about the two Bangladeshi exchanges, but it leaves the single required parameter ambiguous and does not address companies listed on only one exchange. Since there is an output schema, return-value documentation is not the issue; the missing input semantics are.

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

  Parameters2/5

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

  The schema only defines a required 'code' string with 0% description coverage. The description's phrase 'same share' implies that code identifies a company/share, but it never specifies whether this is a DSE code, CSE code, or normalized ticker, nor what format the agent should pass.

  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 action: price the same share on both Dhaka and Chittagong exchanges. It is specific about the resource and scope, though it does not explicitly distinguish itself from sibling tools like get_stock or market_summary.

  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 context that most Bangladeshi companies are listed on both exchanges and that prices can differ implies when this tool is useful. However, it lacks explicit guidance about when not to use it or when to prefer a sibling tool such as get_stock for a single-exchange quote.

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

• exchange_rateA
  3.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses that rates are mid-market reference rates, that banks add spreads, and that the tool defaults to remittance-relevant currencies—useful behavioral context beyond the bare 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?

  Three concise sentences, each adding meaningful information: purpose, default behavior, and rate caveat. No filler or redundancy.

  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?

  For a tool with one optional parameter and an output schema, the description covers the key contextual points: what the rate represents, which currencies are defaulted, and a practical caveat. The main gap is the lack of parameter value format, but this is minor for such a simple tool.

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

  Parameters2/5

  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 mentions the default behavior of the 'currencies' parameter but does not explain what values are accepted (e.g., currency codes, case sensitivity, format), leaving an ambiguous parameter.

  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's function: converting one unit of a foreign currency into taka. It names the resource ('exchange rate') and the scope, though it doesn't explicitly differentiate from the sibling 'compare_exchanges'.

  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 implies usage context by mentioning defaults for Bangladeshi remittances and warning that actual received rates are lower. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

• top_moversA
  3.6/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 full burden of behavioral disclosure and does so reasonably well. It explains that gainers and losers rank by percent change, notes that untraded shares are excluded rather than shown as losses, and defines the meaning of the direction parameter. It does not mention rate limits, authentication, or exact output contents, but the output schema covers the return structure.

  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, followed by two sentences that add meaningful ranking and exclusion behavior. Every sentence earns its place, and there is no redundant filler or repetition of the tool name.

  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?

  For a simple query tool with an output schema, the description covers the key invocation details: the supported direction values, the ranking basis, and the handling of untraded shares. It does not document possible exchange identifiers or limit constraints, but the defaults in the schema and the self-explanatory parameter names reduce the practical gap. The main missing element is usage routing relative to sibling tools, which is already penalized under usage guidelines.

  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 0%, so the description must compensate for missing parameter documentation. It thoroughly explains the 'direction' parameter, including its valid values and ranking semantics, but it does not explain 'limit' or acceptable 'exchange' values beyond the default in the schema. The parameter names are self-explanatory, but the description only partially bridges the schema's lack of documentation.

  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 identifies the resource as the session's biggest movers on one exchange, which is specific enough to distinguish the tool's subject matter from siblings like market_summary or compare_exchanges. However, it lacks an explicit verb such as 'List' or 'Get,' and it does not directly differentiate itself from sibling tools by name.

  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?

  The description explains what the tool returns and clarifies the 'direction' values, but it provides no guidance on when to use this tool versus alternatives. There are no explicit when-to-use or when-not-to-use conditions, nor any mention of sibling tools like market_summary for broader market context or compare_exchanges for multi-exchange comparisons.

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

• company_profileA
  3.9/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the behavioral disclosure burden. It is transparent about the kind of data returned and the market scope, but it does not mention whether the data is point-in-time, how missing or invalid codes are handled, or whether the operation is strictly read-only. These are not severe gaps for a profile-lookup tool, but they prevent a higher score.

  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 first sentence is front-loaded and gives the essential information immediately. The second sentence adds value by explaining what the fundamentals mean in practical terms, and the third reinforces the DSE-only restriction. There is minor redundancy, but the description remains compact and readable.

  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?

  For a tool with one required string parameter and an existing output schema, the description provides sufficient context: it defines the domain, the kind of data returned, and the restriction to DSE-listed companies. It omits an example code or explicit statements about lookup behavior, but those are minor given the tool's simplicity and the presence of an output schema.

  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 one parameter, 'code', with no description and 0% schema coverage. The description indirectly identifies it as the identifier for a DSE-listed company, which provides some semantic grounding. However, it does not explicitly state that 'code' is the DSE trading code or give an example, so the agent must infer the expected format.

  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 provides fundamentals for one DSE-listed company and lists the specific fields: sector, market cap, P/E, and capital. It also distinguishes itself from price-focused tools by saying it supplies 'the context a price alone cannot give you,' and the phrase 'DSE-listed companies only' defines the target resource. Despite lacking an explicit verb, the intent is unambiguous.

  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 gives clear contextual guidance: use this when you need fundamental context beyond price, and only for DSE-listed companies. It implicitly contrasts with price-only tools and includes an exclusion ('DSE-listed companies only'). However, it does not explicitly name sibling alternatives like get_stock or search_stock, nor does it state when not to use this tool for price data.

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

• list_news_sourcesA
  3.9/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 transparency burden. It discloses a useful behavioral nuance: the tool not only reports covered feeds but also identifies what is not covered. The list-style operation is implied by the name and no side effects are suggested.

  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 a single concise sentence that conveys the essential scope without redundancy. Every word adds value, and it is appropriately brief for a tool with no parameters.

  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 no parameters and an output schema exists, the description is largely complete. It explains what the tool reports including the negative case, though a brief mention of how it relates to sibling tools would improve context.

  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?

  The tool has zero parameters and 100% schema coverage, so there are no parameter semantics to explain. The description appropriately focuses on the query's purpose rather than parameter details, meeting the baseline for a no-parameter tool.

  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 states the tool's purpose: to show which news feeds are covered and which financial papers are not. It clearly identifies the resource (news sources) and the specific scope of coverage, though it lacks a direct verb like 'list' or 'returns'.

  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 implies the tool is for checking coverage of news sources and financial papers, but it does not explicitly say when to use this tool instead of siblings like finance_news or market_summary. Usage context is strongly implied by 'coverage' but no alternatives or exclusions are mentioned.

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

• list_sectorsA
  3.9/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the burden. For a zero-parameter list operation, 'List the DSE sectors...' transparently signals a non-mutating enumeration, and the examples clarify what kind of values will be returned; no hidden side effects are plausible for this tool.

  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?

  One short sentence with the key operation front-loaded and examples as supporting detail. There is no redundant text or repetition of the title beyond the essential verb.

  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?

  For a tool with no parameters and an existing output schema, the description covers the core purpose and domain with examples. It could be more complete by pointing to downstream consumers such as sector_performance or noting ordering behavior, but those are not necessary for correct invocation.

  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?

  The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter documentation (there are none), but the examples of sector names give useful operational value by showing the domain of returned values.

  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 names the action ('List') and the exact resource ('DSE sectors you can ask about'), with concrete examples (Bank, Textile, Pharmaceuticals) that make the domain unambiguous. It is clear, though it does not explicitly differentiate itself from sector_performance or other siblings.

  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 phrase 'you can ask about' implies the tool is for discovering which sector names are valid inputs to other DSE queries, but no explicit when-to-use or alternative is given. An agent can infer the usage context but receives no direct routing guidance.

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

• get_stockA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description itself must carry safety and behavior. It clearly frames a read-only price lookup, but gives no details on invalid codes, data delay, limits, or error behavior. This is acceptable for a simple lookup but leaves some edge cases undisclosed.

  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, each earning its place: the first states the core function, the second gives an example and an alternative. No filler or redundant restatement.

  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 low-complexity tool with an output schema, the main gap is exchange values: an agent cannot know valid options beyond the default 'dse' from this description. Otherwise, the description and schema together are enough to call get_stock for the default case.

  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 description adds concrete meaning to codes with the example ['GP', 'BRACBANK'], which the bare schema lacks. However, the exchange parameter is only implied by 'one exchange' and its accepted values or relationship to the default 'dse' are not explained.

  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?

  States a specific action: fetching current prices for given trading codes on a single exchange. The 'one exchange' scope and explicit 'Codes are short symbols' example distinguish it from compare_exchanges.

  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 routes agents to compare_exchanges when a share price on both markets is needed, which defines when not to use this tool. 'Specific trading codes on one exchange' also implies it is for targeted quotes rather than market-wide tools like top_movers or market_summary.

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

• sector_performanceA
  4.4/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 full burden of behavioral disclosure. It transparently explains the aggregation behavior, the types of statistics returned, and the partial-name matching feature, including a concrete example. It does not explicitly state that the operation is read-only, but the phrasing and focus on historical trading data make that reasonably 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?

  The description is concise and well-structured: an attention-grabbing example first, followed by the aggregation details, then the matching behavior. Every sentence adds value, and there is no redundant or filler content. The structure front-loads the core purpose before giving supporting detail.

  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 tool's purpose, output statistics, and input matching behavior in a way that is sufficient for most calls. The presence of an output schema reduces the need to document return values in detail. It might have mentioned using list_sectors to discover valid sector names, but the partial-match behavior makes this less critical.

  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?

  The input schema provides only a bare string parameter with no description, so the description must compensate. It adds meaningful semantics by explaining that the parameter is a sector name and that partial matches are accepted, with an example. It could be even more explicit about acceptable formats, such as case sensitivity or exact name requirements, but the example provides enough guidance for correct invocation.

  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 identifies the tool as aggregating sector-level trading statistics for a single DSE sector, listing specific outputs: advance/decline/never-traded counts, average move, and best/worst performers. The opening example ('did banks rise while textiles fell?') makes the purpose intuitive and distinguishes it from sibling tools like top_movers or get_stock, which focus on individual securities or market-wide moves.

  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 provides clear context for when to use the tool: when the user wants to know how one sector traded today. It implies the contrast with market-wide or stock-specific tools, though it does not explicitly name alternatives or state when not to use it. The partial-name matching note also guides callers on what input format is acceptable.

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

• finance_newsA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden, and it does so well. It reveals the sort order, how keyword filtering narrows results, the inclusive-source rule, and the non-obvious business_only/Dhaka Tribune behavior. There is no contradiction with the schema, and all important behavioral nuances are surfaced.

  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 well-structured: the core purpose comes first, then usage context, then parameter-level details, then the most specialized caveat. Every sentence earns its place, and none of the prose is redundant with the schema or output schema.

  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?

  For a tool with four optional parameters and no annotations, the description covers all non-obvious invocation decisions, including an intentional data-source quirk. Since an output schema exists, return-value documentation is not required. The only unmentioned parameter, limit, is straightforward from the schema, so nothing material is missing.

  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 description coverage is 0%, so the description must compensate. It adds real meaning to keyword, sources, and business_only, including valid source values, paywall status, and the Dhaka Tribune feed behavior. The only parameter left entirely to the schema is limit, though its name, integer type, and default value make it self-explanatory.

  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 opening line 'Latest business and financial news, newest first' names both the resource and the ordering, and the next sentence gives the practical job: explain what the market is doing. This distinguishes it from sibling price/market tools like top_movers and get_stock by framing the tool as the news-side explanation rather than another market number source.

  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 tells the agent when to use it: when prices show that something moved and the agent needs the reason, use the news. It also gives detailed source-selection guidance and a meaningful caveat about Dhaka Tribune. It does not explicitly name a sibling alternative or state a 'do not use when' case, so it stops short of a 5.

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