Server Quality Checklist

Tool Scores

• find-option-expirationsC
  2.9/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. It does not disclose behavioral traits such as authentication requirements, rate limits, or whether it returns only future dates. The term 'valid' is ambiguous.

  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?

  Single sentence, front-loaded with purpose. Efficient but lacks additional structuring. Appropriate for a simple tool.

  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 no output schema, the description should explain return format or constraints. It is incomplete—does not clarify what 'valid' means or if dates are formatted in a specific way.

  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 schema already documents the single parameter. The description adds no new semantic meaning beyond restating the parameter's role.

  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 'list' and the resource 'valid option expiration dates' for a given symbol. It distinguishes from sibling tools like historical-prices or get-quote, but 'valid' could be more specific.

  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 on when to use this tool versus siblings. The description does not provide context on when it is appropriate or when to consider alternatives.

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

• historical-pricesB
  3.3/5.0
  Behavior2/5

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

  No annotations provided. Description does not disclose behavioral details like output format (list of bars), data frequency, or potential adjustments. The parameter descriptions cover some behavior (interval, session_filter) but lack overall transparency.

  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?

  Single sentence, efficient, and front-loaded with key action (historical bars). No wasted words, though could be slightly expanded for clarity.

  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?

  No output schema and no annotations. Description omits what the output looks like (e.g., array of bars with OHLCV fields), which is critical for an agent to use the tool correctly.

  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 baseline is 3. Description adds no additional semantics beyond what schema provides; it repeats the concept of stock/option and time range.

  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 specifies it provides historical OHLCV bars for stock symbols or OCC option contracts over a time range, distinguishing it from sibling tools (e.g., get-quote for real-time quotes, find-options-chain for chains).

  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?

  No explicit guidance on when to use or avoid this tool. While context implies it's for historical data, it does not mention alternatives (e.g., for real-time quotes use get-quote).

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

• get-quoteA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries disclosure burden. Mentions that for option symbols, response includes Greeks and IV when supported, which is useful. However, does not clarify if tool is read-only, rate limits, or response structure beyond that.

  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 short sentences deliver core information efficiently. Front-loaded with main action, no redundant 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?

  Adequate for a simple one-parameter tool without output schema. Covers basic purpose and a key behavioral nuance. Could be more complete by describing standard response fields (e.g., price, volume) but that is often assumed.

  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 already describes the symbol parameter with examples (100% coverage). The description adds meaning by clarifying that option symbol inputs yield additional data (Greeks/IV), which helps the agent understand parameter-dependent 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?

  Verb 'Get' with resource 'latest quote' clearly states the action. Distinguishes from siblings (historical-prices, find-option-expirations, find-options-chain) by focusing on current data for stocks or single option contracts.

  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 usage for obtaining latest quotes but does not explicitly state when not to use or mention alternatives like historical-prices for past data. No direct guidance on tool selection.

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

• find-options-chainA
  4.2/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 and discloses key behaviors: data provider query, filtering by volume/bid/ask >0.10, strike percentage, and behavior when nothing found. This is good transparency for a query 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?

  Two sentences efficiently convey purpose, filtering criteria, and an edge case. No extraneous information; 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?

  Given 5 parameters and no output schema, the description covers purpose, filters, and result emptiness. It lacks mention of return format but is sufficiently complete for a query tool. Minor gap: does not describe pagination or limits.

  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%, but the description adds value by explaining filtering logic (volume/bid/ask thresholds, strike percentage) that is not in parameter descriptions. This helps the agent understand how parameters influence results.

  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 explicitly states the tool queries for options chain of a symbol on a specific expiration date, and lists key filtering criteria. It clearly distinguishes from siblings like historical-prices and get-quote which are for different data.

  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 for retrieving filtered options data but does not explicitly compare to siblings or provide when-to-use/when-not-to-use guidance. It does mention an edge case (empty result) and suggests checking validity, which is helpful but not full guidance.

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