Server Quality Checklist

Tool Scores

• etrade_lookup_productC
  2.9/5.0
  Behavior2/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 states the tool returns a list of matching products but doesn't mention critical aspects like authentication requirements (implied by sibling tools), rate limits, error handling, or whether this is a read-only operation. The description is minimal and lacks 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.

  Conciseness4/5

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

  The description is well-structured with a clear purpose statement followed by Args and Returns sections. It's concise with no wasted sentences, though the lack of usage guidelines or behavioral details means it could be more informative without sacrificing brevity.

  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?

  Given the tool has an output schema (which covers return values), the description doesn't need to detail returns. However, with 3 parameters, 0% schema coverage, and no annotations, the description only partially compensates. It explains parameters but misses authentication needs, error cases, and sibling differentiation, making it incomplete for safe and effective use.

  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 some parameter semantics beyond the schema, which has 0% coverage. It explains that 'search' is for symbol names, 'company' for company names, and 'type' for security types with examples (EQ, MF, OPTN). However, it doesn't clarify if searches are case-sensitive, the format of returns, or how partial matches work, leaving gaps in understanding.

  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 purpose as 'Look up products by symbol or company name,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate this from sibling tools like etrade_get_quote, which might also retrieve product information, leaving room for potential confusion about when to use each.

  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 provides no guidance on when to use this tool versus alternatives like etrade_get_quote or other siblings. It mentions optional parameters but doesn't explain scenarios where searching by symbol vs. company name is preferred or how this tool complements others in the server.

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

• etrade_get_quoteB
  3.1/5.0
  Behavior2/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 mentions what data is returned but doesn't cover critical aspects like rate limits, authentication requirements (implied by sibling tools but not stated), error handling, or whether this is a read-only operation. The return statement adds some value but is insufficient for a mutation-free tool with zero annotation coverage.

  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 well-structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place by explaining parameters or outputs. It could be slightly more front-loaded by integrating the return info into the opening, but it's efficiently sized without waste.

  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?

  Given 3 parameters with 0% schema coverage and an output schema (implied by 'Has output schema: true'), the description does a decent job. It explains all parameters and outlines return data, but lacks context on authentication (suggested by sibling tools), error cases, or usage limits. The output schema reduces the need for detailed return explanations, but behavioral gaps remain.

  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 provides clear semantics for all three parameters: symbols (format and examples), require_earnings_date (effect on return data), and skip_mini_options_check (behavioral effect). This adds significant value beyond the bare schema, though it doesn't detail all possible return fields exhaustively.

  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 purpose: 'Get stock quote for one or more symbols.' It specifies the verb ('Get') and resource ('stock quote'), and distinguishes it from siblings like option chains or product lookup. However, it doesn't explicitly differentiate from similar quote tools that might exist elsewhere, keeping it at 4 rather than 5.

  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. While siblings include authentication and option-related tools, the description doesn't mention when to choose this over etrade_lookup_product or other potential quote tools. It only states what it does, not when it's appropriate.

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

• etrade_authenticateB
  3.2/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 mentions the tool completes OAuth authentication, implying it's a write/mutation operation that likely stores tokens or establishes a session. However, it doesn't disclose critical behavioral traits such as whether this is a one-time setup, if it requires prior steps (like calling 'etrade_get_auth_url'), error handling, or rate limits. For a tool with no annotations and significant behavioral implications, this is inadequate.

  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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured 'Args' and 'Returns' sections. There's no wasted text, and the structure aids readability. It could be slightly more concise by integrating the 'Args' explanation into the main description, but it's efficient overall.

  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?

  Given the tool's complexity (OAuth authentication with no annotations and an output schema), the description is minimally complete. It explains the parameter and return value ('Success message'), and the output schema likely provides more detail on returns. However, it lacks context on prerequisites (e.g., dependency on 'etrade_get_auth_url'), error cases, or behavioral nuances, leaving gaps for an AI agent to infer usage 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?

  The schema description coverage is 0%, but the description includes an 'Args' section that explains 'verifier' as 'The verification code received after authorizing the application.' This adds meaningful semantics beyond the bare schema, clarifying the parameter's purpose and source. However, it doesn't provide format details (e.g., length, character set) or examples. With 0% schema coverage, the description compensates partially but not fully.

  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 purpose: 'Complete E*TRADE OAuth authentication with verification code.' It specifies the verb ('Complete authentication') and resource ('E*TRADE OAuth'), though it doesn't explicitly differentiate from sibling tools like 'etrade_get_auth_url' which likely provides the initial authorization URL. The purpose is clear but lacks sibling distinction.

  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 'verification code received after authorizing the application,' suggesting this tool is used after obtaining an auth URL (likely from 'etrade_get_auth_url'). However, it doesn't explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is implied but not explicit.

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

• etrade_get_option_chainsB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical details: it doesn't mention authentication requirements (though sibling tools suggest it's needed), rate limits, error handling, or whether this is a read-only operation. The 'Returns' section hints at output but doesn't fully describe behavior.

  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 well-structured with a clear purpose statement followed by organized parameter and return sections. It's appropriately sized for an 11-parameter tool, though the 'Returns' section could be more detailed given the complexity. Every sentence earns its place, but minor verbosity in listing all parameters slightly reduces efficiency.

  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 complex tool with 11 parameters, no annotations, and an output schema, the description is moderately complete. It covers parameter semantics well but lacks behavioral context (e.g., authentication, errors) and doesn't leverage the output schema to explain return values in detail. It's adequate but has clear gaps given the tool's complexity.

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

  Parameters5/5

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

  Given 0% schema description coverage, the description compensates excellently by providing clear semantics for all 11 parameters. Each parameter is explained with examples (e.g., 'AAPL' for symbol) and valid ranges/enums (e.g., 'STANDARD, ALL, or MINI' for option_category), adding significant value beyond the bare schema.

  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 verb 'Get' and the resource 'option chains for a symbol', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'etrade_get_option_expire_dates' or 'etrade_get_quote', 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of sibling tools like 'etrade_get_option_expire_dates' for expiration dates or 'etrade_get_quote' for stock quotes, nor any context about prerequisites such as authentication.

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

• etrade_get_option_expire_datesB
  3.3/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 states the tool 'Get[s]' data, implying a read-only operation, but doesn't address other behavioral aspects like authentication requirements, rate limits, error handling, or whether it's idempotent. For a tool with no annotation coverage, this 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.

  Conciseness5/5

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

  The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured sections for 'Args' and 'Returns'. Every sentence adds value without redundancy, making it efficient and easy to parse.

  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 low complexity (2 parameters, no nested objects) and the presence of an output schema (which covers return values), the description is mostly complete. It explains parameters well, but lacks context on usage guidelines and behavioral traits, which slightly reduces completeness for agent 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 description adds meaningful context beyond the input schema. The schema has 0% description coverage, but the description explains 'symbol' as 'Underlying stock symbol (e.g., "AAPL")' and 'expiry_type' with allowed values ('WEEKLY, MONTHLY, QUARTERLY, or ALL') and notes it's optional. This compensates well for 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 states the tool's purpose: 'Get option expiration dates for a symbol.' It specifies the verb ('Get') and resource ('option expiration dates'), and the scope ('for a symbol') is clear. However, it doesn't explicitly differentiate from sibling tools like 'etrade_get_option_chains' or 'etrade_lookup_product', 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'etrade_get_option_chains' or 'etrade_lookup_product', nor does it specify prerequisites such as authentication. This leaves the agent with minimal context for tool selection.

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

• etrade_get_auth_urlA
  4.2/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 discloses that the tool returns a URL for user interaction and is part of an OAuth flow, which is useful behavioral context. However, it lacks details on error handling, rate limits, or authentication prerequisites, leaving gaps in 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?

  The description is front-loaded with the core purpose in the first sentence, followed by additional context and return details. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.

  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 low complexity (0 parameters, output schema exists), the description is largely complete, covering purpose, usage, and return value. However, with no annotations, it could benefit from more behavioral details like error cases or integration steps with etrade_authenticate, slightly reducing completeness.

  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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a high baseline score. It could slightly improve by noting the absence of parameters, but this is minor.

  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 specific action ('Get E*TRADE OAuth authorization URL') and resource ('URL'), distinguishing it from sibling tools like etrade_authenticate (which likely uses the URL) and other data retrieval tools. It precisely communicates the tool's function as the first authentication step.

  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 states when to use this tool ('first step in authentication'), providing clear context. However, it does not specify when not to use it or name alternatives, such as whether to use etrade_authenticate directly in some scenarios, which prevents a perfect score.

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