Server Quality Checklist

Tool Scores

• get_news_coverageB
  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 of behavioral disclosure. It usefully states that the tool is deterministic and does not expose raw payloads, headers, or secrets, which gives agents a meaningful safety boundary. However, it does not explicitly state whether this is read-only, whether it has side effects, or what other operational constraints apply.

  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 a single, dense sentence with no filler. The primary action, target resource, and a key constraint are all present. It is concise and front-loaded, though it could be slightly clearer about parameter usage and sibling differentiation.

  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-value details are not required from the description. The description states the core purpose and a key security boundary, but for a tool with no annotations and ambiguous sibling overlap, it lacks usage conditions and explicit alternative routing. It is adequate but leaves meaningful gaps.

  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 does tie the parameter to a 'target trading date' and gives A-share context, which is helpful. But it does not explain the expected date format, how null is handled, or how the parameter influences the deterministic coverage diagnosis. The parameter meaning is only partially conveyed.

  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 uses a specific verb ('diagnose') with a clear resource ('domestic A-share morning-news coverage') and a target trading date. It also adds a distinguishing security constraint ('without exposing raw payloads, headers or secrets'). However, it does not explicitly differentiate from sibling tools such as get_morning_news, so differentiation is implicit rather than direct.

  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 this tool versus get_morning_news, generate_morning_brief, or get_previous_close_context. The phrase 'diagnose deterministic coverage' implies an investigative or audit-like use case, but no explicit conditions, exclusions, or alternative selection criteria are provided.

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

• get_morning_newsA
  3.5/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 the behavioral disclosure burden. It adds useful non-obvious traits: deterministic, clustered/ranked, and not raw upstream feeds or investment advice. However, it does not mention behavior around missing dates, default category handling, or what happens when no news exists, leaving those to be inferred.

  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 the key distinguishing traits (deterministic, clustered, ranked, A-share, not raw) are front-loaded. Every phrase earns its place.

  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?

  Given zero annotations and zero schema descriptions, the description should compensate with parameter and usage guidance, but it only covers the tool's purpose and processing nature. The output schema may describe return values, but invocation context and sibling differentiation remain incomplete for an agent.

  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, but it only hints at target_date via 'target trading date'. Categories and limit_per_category receive no explanation, leaving their formats and semantics unclear beyond the parameter names and defaults.

  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 has a specific verb ('Get'), a specific resource ('deterministic clustered and ranked A-share morning news events'), and a clear scope ('for a target trading date'). It also distinguishes itself from raw upstream feeds, which helps separate it from the sibling get_news_coverage.

  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 when to use the tool (when deterministic A-share morning news events are needed for a target date), but it does not explicitly name alternatives or state conditions for choosing this tool over siblings like generate_morning_brief or get_news_coverage. The exclusion of raw feeds/advice is about output boundaries, not about when to use the tool.

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

• get_previous_close_contextA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by calling the result 'deterministic' and scoping the data source/region, but it does not describe side effects, input validation behavior, or what happens when target_date is null or non-trading.

  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?

  A single front-loaded sentence that names the action, scope, and source without excess. The trailing 'not investment advice' is compliance boilerplate but does not make the description bloated.

  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 one-parameter read-style tool with an output schema, this is minimally adequate for selection, but it leaves important gaps: parameter format/null behavior and when to prefer sibling tools. More explicit usage guidance would make it fully complete.

  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 coverage is 0%, so the description must compensate, but it only echoes 'target trading date' without specifying the expected date format or the meaning of null/default. An agent cannot confidently construct the target_date parameter from the description alone.

  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 verb ('Get') and a narrowly scoped resource: 'HiThink previous-close A-share market context' for a 'confirmed target trading date.' This clearly differentiates it from the sibling news/brief tools, so an agent can select it without opening the schema.

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

  Usage Guidelines3/5

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

  Implies when to use it: when previous-close A-share context for a confirmed target trading date is needed. However, it does not explicitly state when not to use it or name alternatives among the sibling tools, leaving some selection judgment to the agent.

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

• generate_morning_briefA
  3.9/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 meaningful traits: determinism, evidence-only sourcing, and non-advisory status. It does not cover edge behaviors or failure modes, but for a non-destructive briefing generator the key expectations are clearly set.

  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?

  A single front-loaded sentence with no filler; every qualifier ('deterministic', 'confirmed target trading date', 'source evidence only, not investment advice') adds valuable scoping.

  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 tool is simple with two optional parameters and an output schema present, so the description is largely sufficient for invoking it. The main gap is what happens when target_date is null/defaulted, but this is inferable from the schema default and context.

  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 only gestures at target_date via 'confirmed target trading date', adding no format or explicit meaning for output_format beyond what the enum/default already provide. This is insufficient compensation for the absence of schema-level descriptions.

  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 verb and resource ('Generate a deterministic A-share morning brief') and identifies the target date as a confirmed trading date. This clearly distinguishes the tool from the raw-data siblings like get_morning_news and get_news_coverage.

  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 producing a morning brief on a confirmed trading date, but it does not explicitly say when to prefer this over the sibling tools or exclude other use cases. The usage context is present but not fully articulated.

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