Server Quality Checklist

Tool Scores

• line_plotC
  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 the full burden. It mentions the tool returns 'an image of the plot,' which is useful, but lacks critical behavioral details: it doesn't specify error handling, performance characteristics, data size limits, or authentication needs. For a tool that runs queries and generates plots, this is a significant gap 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.

  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 core purpose, followed by technical details. However, the second sentence about DuckDB syntax could be more integrated, and there's minor redundancy (e.g., repeating 'SQL query' concepts). Overall, it's efficient with little 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 the complexity (query execution + visualization), no annotations, and no output schema, the description is moderately complete. It covers the basic workflow and output format but lacks details on error cases, performance, or integration with siblings. For a tool with 5 parameters and no structured safety hints, it should do more to guide usage.

  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 all parameters thoroughly. The description adds minimal value beyond the schema: it implies 'source_id' refers to CSV/parquet sources and specifies table naming conventions, but doesn't elaborate on parameter interactions or usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.

  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: 'Run query against specified source and make a line plot using result.' It specifies the verb ('run query' and 'make a line plot') and resource ('specified source'), but doesn't explicitly differentiate from siblings like 'run_query' (which only runs queries) or other plot types (e.g., 'scatter_plot').

  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 mentions DuckDB SQL syntax and table naming conventions for CSV/parquet sources, but doesn't explain when to choose a line plot over other visualization siblings (e.g., 'bar_plot', 'scatter_plot') or when to use 'run_query' instead. No exclusions or prerequisites are stated.

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

• scatter_plotC
  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 full burden for behavioral disclosure. It states the tool returns an image of the plot, which is useful, but lacks critical details: it doesn't mention whether this is a read-only operation (though implied by plotting), error handling for invalid queries or columns, performance characteristics, or any authentication/rate limit considerations. The description adds some context about SQL syntax but misses key behavioral traits.

  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 with four sentences. It's front-loaded with the core purpose, followed by implementation details and output information. While efficient, the second and third sentences about DuckDB syntax and table names could be more integrated or simplified, slightly affecting flow.

  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 complexity (a 5-parameter tool that queries and visualizes data), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose, SQL syntax details, and output type, but lacks context on error cases, performance, or how it differs from siblings. For a tool with no structured safety or output info, it should provide more behavioral guidance to be fully helpful.

  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 all 5 parameters thoroughly. The description adds minimal value beyond the schema: it implies the query runs against a data source and results are used for plotting, but doesn't clarify parameter interactions (e.g., how 'color' relates to 'x' and 'y') or provide examples. This meets the baseline for high schema coverage.

  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 runs a query and creates a scatter plot from the results, specifying the verb ('run query' and 'make a scatter plot') and resource ('specified source'). However, it doesn't explicitly differentiate from sibling tools like 'run_query' (which doesn't create plots) or other plot types (e.g., 'line_plot'), leaving some ambiguity about when to choose this specific visualization.

  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 mentions using DuckDB SQL syntax and table naming conventions for CSV/parquet sources, but these are implementation details rather than usage context. There's no mention of when a scatter plot is appropriate compared to other plot types like 'bar_plot' or 'histogram' from the sibling list.

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

• describe_tableB
  3.1/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. It states it 'Lists columns and their types', implying a read-only operation, but doesn't disclose behavioral traits like whether it requires specific permissions, how it handles errors, or if it has rate limits. This is a significant gap for a tool with no 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse.

  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 that there is an output schema (which handles return values), the description's minimal coverage of purpose is somewhat acceptable. However, with no annotations and incomplete behavioral transparency, it leaves gaps in understanding the tool's full context and usage.

  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 both parameters ('source_id' and 'table_name') adequately. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, resulting in the baseline score.

  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 ('Lists') and resource ('columns and their types in the specified table of specified data source'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_data_sources' or 'run_query', 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 prerequisites, context, or exclusions, leaving the agent to infer usage from the purpose alone.

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

• histogramB
  3.2/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 mentions the return format ('image of the plot') but doesn't describe error conditions, performance characteristics, data size limitations, or what happens with invalid queries. For a data visualization tool with complex parameters, this leaves significant behavioral gaps.

  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 concise with 4 sentences that each serve a purpose: stating the core function, providing SQL syntax guidance, specifying table naming conventions, and describing the return value. It's front-loaded with the main purpose and avoids unnecessary repetition.

  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 5 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers the basic operation and return format, but for a data visualization tool with sibling alternatives, it should better explain when this specific visualization type is appropriate and what behavioral constraints exist.

  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 all 5 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions using 'CSV'/'PARQUET' as table names which relates to source_id usage, but doesn't explain parameter interactions or provide additional context about how column, color, and nbins work together.

  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: 'Run query against specified source and make a histogram using result' and 'This will return an image of the plot'. It specifies the verb (run query, make histogram) and resource (data source), but doesn't explicitly differentiate from siblings like bar_plot or density_heatmap beyond the histogram focus.

  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 provides some usage context with SQL syntax details for csv/parquet sources and table naming conventions, which implies when to use this tool for histogram generation. However, it doesn't explicitly state when to choose histogram over alternatives like density_heatmap or bar_plot, nor does it mention prerequisites or exclusions.

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

• strip_plotB
  3.2/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 reveals that the tool returns an image and mentions SQL syntax requirements, but doesn't disclose important behavioral aspects: whether this is a read-only operation, potential performance implications of running queries, error handling for invalid queries or columns, or any rate limits. For a tool that executes queries and generates visualizations, this leaves significant behavioral gaps.

  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 with 4 sentences that each serve a purpose: stating the core functionality, specifying SQL syntax requirements, detailing table naming conventions, and describing the return type. It's front-loaded with the main purpose. However, the second and third sentences could potentially be combined for better flow, and some information feels slightly repetitive (mentioning both csv and parquet sources twice).

  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 complexity (query execution + visualization generation), no annotations, and no output schema, the description is moderately complete. It covers the basic workflow and return type (image), but lacks important context: what format the image is in (PNG, JPEG?), typical size/resolution, how errors are handled, whether queries can modify data, or what happens with empty/no result queries. For a tool with this functionality level, more behavioral context would be helpful.

  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 all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain parameter relationships, provide examples of valid queries, or clarify how x/y/color parameters interact with query results. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

  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: 'Run query against specified source and make a strip plot using result' - this specifies both the action (run query, make strip plot) and resource (specified source). It distinguishes from siblings like 'run_query' (which doesn't create plots) and 'scatter_plot' (which creates a different visualization type). However, it doesn't explicitly contrast with all sibling plot types like 'bar_plot' or 'box_plot' beyond the strip plot specificity.

  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 provides implied usage context: it mentions using DuckDB SQL syntax and specific table names for different source types, which suggests when this tool is appropriate (for querying csv/parquet sources). However, it doesn't explicitly state when to choose this tool versus alternatives like 'run_query' (for just querying) or other plot types like 'scatter_plot' or 'histogram'. No explicit exclusions or alternatives are named.

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

• polar_scatterB
  3.4/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 key behavioral traits: the tool executes a query, creates a polar scatter plot, and returns an image. However, it doesn't mention performance characteristics, error handling, authentication requirements, or what happens with invalid queries/parameters. The statement about DuckDB SQL syntax and table naming conventions adds useful context beyond basic functionality.

  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 (4 sentences) and front-loaded with the core purpose. Each sentence adds value: the first states the purpose, the second specifies SQL syntax requirements, the third clarifies table naming conventions, and the fourth describes the return type. There's minimal waste, though the structure could be slightly more organized.

  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 (query execution + visualization), no annotations, and no output schema, the description is moderately complete. It covers the main workflow and return type but lacks details about error conditions, performance limits, or what the image output contains (format, dimensions, etc.). For a visualization tool with query execution, more context about failure modes would be helpful.

  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 all 5 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions using result columns for coordinates and coloring, but this is already covered in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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: 'Run query against specified source and make a polar scatter plot using result' - this specifies both the action (run query, make plot) and the resource (data source, query result). It distinguishes from siblings like 'scatter_plot' by specifying 'polar' scatter plot, but doesn't fully differentiate from 'polar_line' beyond plot type.

  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 provides some usage context: it specifies when to use 'CSV' vs 'PARQUET' as table names based on source type, and mentions this is for both csv and parquet sources. However, it doesn't explicitly state when to choose this tool over alternatives like 'scatter_plot', 'polar_line', or 'run_query' - the guidance is implied rather than explicit.

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

• run_queryA
  3.5/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 dataframe and specifies SQL syntax requirements, but lacks details on permissions, error handling, rate limits, or data modification behavior (e.g., whether queries can mutate data). The description adds basic behavioral context but misses important operational details.

  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 with four concise sentences. It's front-loaded with the core purpose, followed by syntax details and output information. There's no wasted text, though it could be slightly more structured for clarity.

  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 (SQL queries on data sources), the description covers the essential purpose, syntax, and output. With an output schema present, it doesn't need to detail return values. However, it lacks information on error cases, data source prerequisites, or integration with sibling tools, leaving some gaps in completeness.

  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 both parameters well. The description adds minimal value beyond the schema: it implies 'source_id' refers to csv/parquet sources and 'query' uses DuckDB SQL, but doesn't provide additional syntax examples or constraints. This meets the baseline for high schema coverage.

  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: 'Run query against specified source' and 'This will return a dataframe with the results.' It specifies the action (run query) and resource (data source), but doesn't explicitly differentiate from siblings like 'describe_table' or 'list_data_sources' beyond the query focus.

  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 provides some usage context: 'For both csv and parquet sources, use DuckDB SQL syntax' and specifies table naming conventions. However, it doesn't explicitly state when to use this tool versus alternatives like 'describe_table' for metadata or the various plotting tools for visualization, leaving usage somewhat implied rather than clearly defined.

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

• bar_plotA
  3.6/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 key behavioral traits: it runs a query, creates a bar plot, uses DuckDB SQL syntax with specific table names, and returns an image. However, it lacks details on error handling, performance, or data size limitations that would be useful for an agent.

  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 with four sentences, front-loaded with the core purpose, followed by technical details and output. It avoids redundancy, though the orientation parameter guidance could be more integrated, and every sentence contributes useful information.

  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 complexity of a 6-parameter tool with no annotations and no output schema, the description is moderately complete. It covers the main functionality and technical constraints, but lacks details on error cases, performance expectations, or how the image output is formatted, which would help an agent use it more effectively.

  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 all parameters thoroughly. The description adds minimal value beyond the schema by mentioning SQL syntax and table names, but does not provide additional meaning for parameters like x, y, or color beyond what's in their schema 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 with specific verbs ('run query', 'make a bar plot') and resources ('specified source', 'result'), and distinguishes it from siblings by focusing on bar plots specifically, unlike other visualization tools like scatter_plot or histogram.

  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 by specifying SQL syntax and table names for different source types, but does not explicitly state when to use this tool versus alternatives like line_plot or histogram, nor does it provide exclusions or prerequisites beyond the technical details.

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

• density_heatmapA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses that the tool returns an image and specifies SQL syntax requirements, but doesn't mention potential behavioral aspects like performance characteristics, error handling, data size limitations, or whether the operation is read-only versus mutating. It adds some context but leaves significant gaps.

  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 with 4 sentences. It's front-loaded with the core purpose, followed by technical details and output information. There's some redundancy ('aka. Density Heatmap') but overall it's efficient with zero wasted sentences.

  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 6 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It explains the core functionality and SQL requirements but lacks information about the returned image format, error conditions, performance considerations, or how this differs from similar visualization tools. For a complex data visualization tool, more completeness would be helpful.

  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 parameters are well-documented in the schema. The description adds minimal parameter semantics beyond the schema - it clarifies that 'query' uses DuckDB SQL syntax with specific table names, but doesn't explain relationships between parameters or provide additional context for the 6 parameters. 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 clearly states the tool's purpose: 'Run query against specified source and make a 2d-histogram aka. Density Heatmap using result'. It specifies the verb ('make'), resource ('2d-histogram/Density Heatmap'), and distinguishes from siblings like 'histogram' (1D) and 'scatter_plot' (non-binned).

  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 SQL syntax requirements and table naming conventions for CSV/parquet sources, but doesn't explicitly state when to use this tool versus alternatives like 'scatter_plot' or 'histogram'. It provides technical prerequisites but no comparative guidance.

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

• list_data_sourcesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses that the tool returns source_ids with type information embedded, which is useful behavioral context. However, it doesn't mention potential limitations like pagination, rate limits, authentication requirements, or whether the list is static vs. dynamic. The description adds value but leaves gaps in behavioral disclosure.

  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 concise with three sentences that each serve distinct purposes: stating the action, explaining the output format, and providing usage context. It's front-loaded with the core purpose. The SQL syntax mention could be slightly more integrated, but overall it's efficient with minimal waste.

  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 0 parameters, 100% schema coverage, and an output schema exists, the description provides good contextual completeness. It explains the purpose, output format, and practical usage for query preparation. For a simple listing tool with structured output schema, the description covers the essential context without needing to detail return values that the output schema will define.

  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 0 parameters with 100% schema description coverage (empty schema). The description appropriately doesn't discuss parameters since none exist. It instead focuses on output semantics: 'Returns a list of unique source_ids' and 'Source type is included in the source_id string.' This provides good context about what the tool returns despite no input parameters.

  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: 'List all available data sources' with the specific verb 'List' and resource 'data sources'. It distinguishes from siblings by focusing on metadata listing rather than data visualization or query execution. However, it doesn't explicitly contrast with specific sibling tools like 'describe_table' which might also provide metadata.

  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 provides implied usage guidance: 'Returns a list of unique source_ids to be used for other queries' suggests this tool should be used before querying data. 'While drafting SQL queries use appropriate syntax as per source type' implies it helps with query preparation. However, it lacks explicit when-to-use vs. when-not-to-use instructions or named alternatives among siblings.

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

• box_plotA
  3.9/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 full burden. It discloses key behavioral traits: it returns an image of the plot, uses DuckDB SQL syntax, and specifies table naming conventions for different source types. However, it doesn't mention important aspects like error handling, performance characteristics, size limitations, or what happens with invalid queries/columns. For a visualization tool with no annotations, this leaves significant gaps.

  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 efficiently structured with four sentences that each add value: purpose statement, SQL syntax guidance, table naming rules, and output specification. It's front-loaded with the core purpose and contains zero redundant information. Every sentence earns its place by providing essential operational guidance.

  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 this is a visualization tool with 5 parameters, no annotations, and no output schema, the description provides adequate but incomplete coverage. It explains the core functionality and SQL context well, but lacks information about the returned image format, error conditions, performance implications, or how it differs from similar visualization tools. For a tool that both queries data and creates visualizations, more behavioral context would be helpful.

  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 all 5 parameters thoroughly. The description adds some context about how parameters relate to the visualization (x/y axes, color for additional dimension) and mentions the SQL syntax context, but doesn't provide additional semantic meaning beyond what's in the schema descriptions. This meets the baseline of 3 when schema coverage is high.

  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: 'Run query against specified source and make a box plot using result' - this is a specific verb ('make a box plot') + resource ('result from query') combination. It distinguishes itself from siblings like 'bar_plot', 'scatter_plot', and 'run_query' by specifying it creates a box plot visualization rather than other plot types or just running queries.

  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 about when to use this tool: for creating box plots from query results, with specific syntax guidance for different source types (CSV vs parquet). However, it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools (e.g., use 'run_query' if you just need data without visualization, or 'histogram' for distribution plots).

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

• polar_lineA
  4/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 full burden. It discloses key behavioral traits: it runs a query, makes a plot, uses DuckDB SQL syntax with specific table names for CSV/parquet sources, and returns an image. However, it lacks details on permissions, error handling, or performance limits. The description does not contradict any annotations.

  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 core purpose, followed by specific syntax guidelines and output information. Every sentence earns its place by providing essential usage details without 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?

  Given the complexity (a visualization tool with 5 parameters) and no annotations or output schema, the description is fairly complete: it covers the tool's purpose, syntax rules, and output type. However, it could benefit from more behavioral context (e.g., error cases or limitations) to fully compensate for the lack of structured data.

  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 all parameters. The description adds some context: it mentions 'CSV' and 'PARQUET' as table names in queries, which relates to the 'source_id' and 'query' parameters, but does not provide additional meaning beyond what the schema descriptions offer for parameters like 'r', 'theta', or 'color'.

  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: 'Run query against specified source and make a polar line plot using result'. It specifies the verb ('run query' and 'make a polar line plot'), the resource ('specified source'), and distinguishes it from siblings like 'polar_scatter' (which makes scatter plots) and 'run_query' (which only runs queries without visualization).

  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 on when to use this tool: for creating polar line plots from query results. It implicitly distinguishes it from siblings by specifying the plot type (polar line), but does not explicitly state when not to use it or name alternatives (e.g., 'use polar_scatter for scatter plots instead').

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