Server Quality Checklist

Tool Scores

• library_get_familyA
  4.2/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It states the output format (markdown) and content (written overview plus complete concept roster), which conveys the nature of this get operation. It doesn't address edge cases or errors, but for a simple retrieval tool this is sufficient 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 two concise sentences. The first defines the return value and content, the second gives usage context. There is no wasted words or redundant information, making it well-structured and direct.

  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 (one enum parameter, no output schema), the description sufficiently covers what it returns and when to use it. It could mention potential error cases or the exact markdown structure, but it's adequate 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.

  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 and enum for the 'key' parameter. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

  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 defines what the tool returns: a family's hub page as markdown, containing a written overview and complete concept roster. It also distinguishes this from siblings by indicating it's for whole analysis areas like 'SMC' or 'Wyckoff', not individual indicators or concepts.

  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 explicit usage guidance: 'Use after library_list_families, or when the user asks about a whole area like SMC or Wyckoff.' This gives clear when-to-use context and implies not for individual concepts, though it doesn't explicitly name alternative tools for those cases.

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

• library_list_familiesA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses the content returned (17 families with counts and hub links) but does not mention potential behavioral aspects like read-only status, pagination, or any side effects. For a simple list tool this is adequate but not rich.

  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 concise sentences. The first sentence front-loads the core purpose and content, and the second adds practical usage guidance. Every word 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 the simplicity (no params, no output schema), the description is largely complete: it names the resource, provides the count, example categories, and what is included. The term 'hub links' is slightly vague but acceptable for an orientation tool.

  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?

  This tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed since the input schema is empty.

  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: it lists the Library's top-level taxonomy of 17 families, with concept counts and hub links. This distinguishes it from siblings like library_list_concepts and library_list_indicators by emphasizing 'top-level' and 'families'.

  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 says 'The natural first call for orientation,' which clearly indicates when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of full exclusion guidance.

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

• library_searchA
  4.2/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 traits like alias-aware searching and that results include slugs and canonical URLs, but it doesn't explicitly state that this is a read-only operation or discuss rate limits, result limits, or behavior when no results are found. These are meaningful gaps for a search 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?

  The description is extremely concise, consisting of two sentences. It front-loads the core purpose and then packs additional useful context (800+ concepts, alias-aware, slugs/URLs) without any fluff 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 search tool with 4 parameters and no output schema, the description is reasonably complete. It explains what the tool covers, the result payload (slugs, URLs), and its role relative to sibling tools. However, it could have mentioned the default type 'all' or the limit behavior, though these are covered in the schema. Slightly more detail about edge cases would make it a 5.

  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 100% coverage for all 4 parameters, so the baseline is 3. The description adds value by explaining that the query is alias-aware (e.g., 'stochastics' finds Stochastic Oscillator) and covers both concepts and indicators, which goes beyond the schema's parameter 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?

  The description clearly states the tool's purpose: to search the LuxAlgo Library, covering both concepts and indicators. It distinguishes itself from sibling get/list tools by explicitly positioning it as the starting point and noting that results carry slugs for the get tools.

  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 to 'start here whenever you have a name, informal term, or topic,' giving clear guidance on when to use it. It also implies that after getting slugs, you should use the get tools. However, it doesn't explicitly contrast with list tools like library_list_concepts, so it's not a perfect 5.

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

• library_get_indicatorA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full transparency burden. It discloses the tool returns details about what the indicator does, how to read it, family, concept links, preview image, and source code availability. This is a good behavioral outline, though it doesn't mention error handling or not-found 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, front-loaded with the core purpose, followed by concise detail and usage guidance. Every word earns its place with no redundancy or filler.

  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 single-parameter get tool with no output schema, the description provides adequate context by enumerating typical return content and a usage directive. It could be more explicit about edge cases, but completeness is strong for the tool's simplicity.

  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 the single 'slug' parameter already well-described via its own schema description and example. The tool description adds minimal parameter semantics beyond the schema, so the 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 opens with 'Details for one indicator', a specific verb+resource combo that clearly states the tool's function. It distinguishes itself from siblings by focusing on a single indicator and explicitly names library_get_source_code for code retrieval, making the purpose unambiguous.

  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 provides explicit usage guidance: 'Use when the user asks about a specific indicator.' It also points to an alternative tool (library_get_source_code) for fetching source code, effectively differentiating when not to use this tool.

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

• library_list_conceptsA
  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 discloses pagination, optional family filtering, and the availability of slugs for downstream use. It does not mention output shape or rate limits, but for a read-only listing tool this is sufficient and adds meaningful behavior 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?

  One concise sentence front-loads the purpose and integrates guidance without waste. Every phrase adds value.

  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 no output schema, the description still communicates the tool's role, filter options, and how results are consumed (slugs for library_get_concept). It also points to library_search as an alternative, making it sufficiently 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?

  Schema already covers page/page_size with defaults; description adds that family is optional ('optionally one family') and confirms pagination. With 67% schema coverage, the description helps but family is still only explained via enum values.

  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 lists all Library concepts, with pagination and an optional family filter. It explicitly distinguishes from library_get_concept and library_search, making its purpose unambiguous.

  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?

  Provides explicit when-to-use guidance: 'Use to enumerate a topic area or find slugs for library_get_concept; for keyword lookup prefer library_search.' This names exact alternatives and gives clear context.

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

• library_list_indicatorsA
  4.4/5.0
  Behavior4/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 does so well by noting 'server-side sorting (newest first by default)' and the nature of structured browsing. It does not mention pagination behavior or output format, but the schema provides defaults and limits, so the description adds meaningful behavioral context 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?

  The description is two sentences long and front-loaded with the core action. Every clause earns its place: the browsing behavior, the default ordering, the structured use case with examples, and the pointer to the alternative tool. 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?

  Given the tool's moderate complexity (6 optional parameters, no output schema, no annotations), the description covers the key context: what the tool does, how to use it, and when to prefer an alternative. It doesn't describe the return shape, which would be useful for an agent, but the title and sibling context partially compensate. The missing pagination/return details keep it from a 5.

  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 67%, so the description does not need to fully compensate, but it also doesn't add much detail beyond the schema. It clarifies that sorting is server-side and that 'newest first' is the default, which adds semantic value, but individual parameters like family and direction are left to the schema's enums. Overall, it adds some meaning but not enough to raise the score above 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 purpose: 'Browse the indicator catalog with filters and server-side sorting.' It uses a specific verb ('Browse'), names the resource ('indicator catalog'), and distinguishes itself from sibling tools like library_search by explicitly contrasting structured browsing with keyword discovery.

  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 provides explicit guidance on when to use this tool: 'Use for structured browsing' with concrete examples ('latest indicators', 'everything in the volatility family') and explicitly names the alternative for keyword discovery: 'for keyword discovery prefer library_search.' This clearly separates usage from siblings.

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

• library_get_source_codeA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the burden. It explains that sources are long and that the tool returns working TradingView code, which gives useful context. It doesn't disclose side effects (none expected) or return format details, but for a simple read-only retrieval it is reasonably 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 concise sentences that immediately state the purpose, the platform compatibility, and the usage condition. No filler or redundant information.

  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 simple one-parameter retrieval tool, the description completely covers purpose, usage context, and the nature of the returned data ('full, working source code'). No output schema exists, but the return value is clearly implied. No crucial missing information.

  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 fully describes the only parameter 'slug' as 'Indicator slug', so schema coverage is 100%. The description adds no additional meaning about how to find or format the slug, so it relies on the schema. 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 states exactly what the tool returns: 'The full, working source code of a Library indicator'. It explicitly distinguishes itself from the sibling library_get_indicator by explaining it's kept separate because sources are long, which clears up potential ambiguity.

  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?

  Provides explicit guidance: 'call it only when the user wants the code itself.' This tells the agent when to choose this tool and implicitly contrasts it with library_get_indicator for when the user wants indicator metadata instead.

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

• library_get_conceptA
  4.7/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 the tool returns 'the Library's full write-up as markdown' with specific sections, and that an exact slug is required. This goes beyond the name and schema, though it does not mention error handling or what happens for duplicate or invalid slugs.

  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: the first states the tool's purpose and output format, the second gives usage context and a prerequisite. Every sentence earns its keep, with no filler or repetition of schema data.

  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 single-parameter tool with no output schema, the description is highly complete: it explains the content and format of the response, specifies when to use it, and states the required input and how to obtain it. The sibling references also enrich the context for an agent navigating the toolset.

  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 schema already provides strong coverage (100%) with a detailed slug description and examples. The description adds value by reinforcing the need for an exact slug and pointing to search/list tools for retrieval, which helps the agent understand the parameter's provenance and criticalness.

  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: 'Explain a trading concept' with a detailed account of what the write-up contains (definition, formula, how traders read it, indicator implementations). It distinguishes itself from siblings by focusing on the full concept write-up rather than indicator-specific or listing functionality.

  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?

  Explicit usage guidance is provided: 'Use for any "what is X / how does X work" question.' It also gives a clear prerequisite and direction to sibling tools: 'Needs the exact slug — find it with library_search or library_list_concepts.' This effectively tells the agent when and how 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.