Teradata MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
There is significant overlap and ambiguity among tools, particularly within categories like base_* (e.g., base_tableAffinity and base_tableUsage both analyze table usage but with unclear distinctions) and dba_* (e.g., dba_tableUsageImpact and dba_tableSqlList both relate to table usage analysis). The plot_* tools are clearly distinct for chart types, but many others have overlapping purposes that could confuse an agent about which to select for a given task.
Naming Consistency3/5
The naming follows a prefix-based pattern (base_, dba_, qlty_, sec_, sql_, plot_, rag_) which provides some consistency, but within these prefixes, conventions vary (e.g., snake_case is used, but names like sql_Execute_Full_Pipeline mix verb styles). The prefixes help group tools by domain, but the naming is not fully predictable or uniform across all tools.
Tool Count2/5
With 39 tools, the count is excessive for a single server, making it heavy and potentially overwhelming for an agent to navigate. While the server covers multiple domains (e.g., database operations, DBA tasks, quality checks, SQL analysis, plotting, RAG), the high number suggests poor scoping, as many tools could be consolidated or split into more focused servers.
Completeness4/5
The tool set covers a broad range of Teradata database operations, including metadata exploration, performance monitoring, data quality, security, SQL analysis, and visualization. There are no obvious major gaps for the inferred domain of database management and analysis, though some minor overlaps might indicate redundancy rather than incompleteness.
Average 3/5 across 39 of 39 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details such as whether it's read-only, destructive, requires authentication, or has rate limits. It fails to disclose any traits beyond the placeholder text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with placeholders but is under-specified, not concise. It includes unnecessary boilerplate (e.g., 'Arguments:', 'Returns:') without substantive content, wasting space rather than being efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, 0% schema coverage, no output schema, and a placeholder description, the tool is completely inadequate for understanding. It fails to provide necessary context for a tool with one required parameter among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'argument' parameter's purpose, format, or constraints. It merely repeats the parameter name without adding meaningful semantics, leaving it undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a placeholder ('<description of what the tool is for>') that does not state what the tool does, making it tautological and indistinguishable from siblings. It provides no specific verb or resource, failing to clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 among the many sibling tools listed. The description lacks any context, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the tool 'generates' a plot but doesn't disclose whether this creates a file, displays output, requires specific permissions, or has any side effects. The RETURN statement mentions 'dict' but doesn't explain what the dictionary contains or the format of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with clear sections (function, parameters, returns). However, the parameter descriptions contain contradictory information (mixing radar, donut, and line plot references) that creates confusion rather than clarity. The structure is organized but the content within sections is problematic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain the data source relationship (how table_name connects to labels/columns), the visualization output format, or any error conditions. The confusion between chart types in parameter descriptions makes the tool's behavior unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does so poorly. Parameter descriptions are confusing (referring to 'donut plot' and 'line plot' instead of radar plot) and don't clarify the relationship between labels and columns. The description doesn't explain how multiple columns (when provided as array) are handled or what data transformations occur.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates a radar plot for labels and columns, but it's vague about the specific action and resource. It mentions 'donut plot' and 'line plot' in parameter descriptions, creating confusion about the actual chart type. The purpose is not clearly distinguished from sibling tools like plot_line_chart or plot_pie_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description doesn't mention any context, prerequisites, or comparisons with sibling plotting tools like plot_line_chart or plot_pie_chart. There's no indication of appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'generate[s] a line plot' and returns a dict, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, what the dict contains (e.g., plot data, image path, error info), or any side effects like file creation or data modification. For a tool with no annotations, this leaves significant gaps in understanding its 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 structured with clear sections (function overview, parameters, returns) and is relatively concise at about 50 words. However, it includes a minor error (referencing 'donut plot' instead of 'line plot' in the table_name parameter description), which slightly detracts from clarity, but overall it's efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameter semantics, behavioral traits (e.g., output format, side effects), and usage context compared to siblings. For a data visualization tool, this leaves too many unknowns for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters with basic types but adds minimal semantics: it states 'table_name' specifies the table for the plot and 'labels' and 'columns' are used for axes, but doesn't explain what 'labels' represents (e.g., column names, categories) or how 'columns' interacts with 'labels' beyond axis assignment. This fails to adequately clarify parameter meanings beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'generate[s] a line plot for labels and columns' and specifies axis mapping, which clarifies the basic purpose. However, it's vague about what constitutes 'labels' and 'columns' in practice, and it doesn't distinguish this tool from sibling plotting tools like 'plot_pie_chart' or 'plot_radar_chart' beyond the chart type.
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 explicit guidance is provided on when to use this tool versus alternatives. While the description implies it's for line plots, it doesn't mention when a line chart is appropriate compared to other chart types available (e.g., pie, polar, radar), nor does it reference prerequisites like data structure requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions generating a plot but doesn't disclose behavioral traits such as whether it creates a file, displays the chart, returns an image or data, error handling, or performance considerations. The description is minimal and lacks details on what the tool actually does beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections for function, parameters, and returns, which is organized. However, it's somewhat inefficient: the first sentence is redundant with the tool name, and parameter descriptions are brief but could be more front-loaded. It's concise but under-specified, not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on what the tool returns (only says 'dict' without explanation), how it behaves, or error cases. For a data visualization tool with multiple parameters, this is inadequate to guide an AI agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters in a PARAMETERS section but provides minimal semantics: table_name specifies the table, labels are used as labels, and column is used to plot. This adds some meaning but is vague (e.g., what format for labels? How does column relate to labels?). It doesn't fully explain the 3 parameters' roles or interactions, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates a pie chart plot for labels and columns, which gives a basic purpose. However, it's vague about what 'labels and columns' refer to (data fields?), doesn't specify the exact resource (data visualization from a table), and doesn't clearly distinguish from sibling tools like plot_line_chart or plot_polar_chart beyond mentioning 'pie chart' vs 'line plot' in parameter descriptions.
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 explicit guidance on when to use this tool versus alternatives like plot_line_chart or other charting tools. The description implies usage for generating pie charts but doesn't specify scenarios (e.g., for categorical data comparison) or exclusions. It's missing context on prerequisites or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool 'generate[s] a polar area plot' and returns a dict, but lacks critical details: what the dict contains, whether this creates a file or displays a plot, error conditions, performance characteristics, or any side effects. The description is insufficient for a mutation/creation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a purpose statement followed by parameter and return sections. However, the structure is somewhat awkward with inconsistent terminology ('donut plot' vs 'line plot' vs 'polar area plot'), and some sentences could be more efficiently worded. It's not wasteful but could be more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the returned dict contains, how the plot is generated or displayed, error handling, or important constraints. Given the complexity of a chart generation tool and the lack of structured documentation, the description leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. While it lists three parameters with brief explanations, these are minimal and don't clarify semantics beyond what the schema titles provide. For example, it doesn't explain how 'labels' and 'column' interact, what format they should be in, or what 'table_name' refers to (database table? file?). The description adds some value but doesn't adequately compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'generate[s] a polar area plot for labels and columns', which is a clear verb+resource combination. However, it doesn't distinguish this polar chart tool from its sibling visualization tools like plot_line_chart, plot_pie_chart, and plot_radar_chart, leaving ambiguity about when to choose this specific chart type.
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 about when to use this tool versus alternatives. With multiple sibling plotting tools available, the description offers no context about appropriate use cases for polar charts versus line, pie, or radar charts, 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.
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 returns 'formatted response with query results + metadata,' which hints at output structure but lacks details on performance (e.g., execution time for large datasets), side effects (e.g., read-only vs. write operations), or error handling. For a tool with no annotation coverage, this is insufficient to inform safe and effective use.
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 brief and structured with clear sections for arguments and returns, making it easy to scan. However, it includes a spelling error ('destinct') and could be more front-loaded by emphasizing the core purpose earlier. Overall, it is efficient but not perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (data analysis with 3 parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It does not explain the return format in detail, potential limitations (e.g., handling of null values), or how it differs from similar tools. This leaves significant gaps for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for the three parameters. The description lists the parameters (database_name, table_name, column_name) but does not add meaningful semantics beyond their names, such as expected formats, constraints, or examples. This fails to compensate for the lack of schema documentation, leaving parameters poorly understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get[s] the destinct categories from column in a table,' which clearly indicates its purpose as a data analysis operation. However, it contains a spelling error ('destinct' instead of 'distinct'), and while it differentiates from some siblings (e.g., qlty_columnSummary, qlty_univariateStatistics), it does not explicitly distinguish from others like base_columnDescription or base_tablePreview, which might involve similar column-level operations.
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 does not mention any prerequisites, such as needing the database to be accessible, or compare it to sibling tools like qlty_columnSummary or base_columnDescription that might offer overlapping functionality. This leaves the agent without 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format ('formatted response with query results + metadata'), which adds some behavioral context. However, it lacks details on permissions, rate limits, or whether it's read-only (implied but not explicit), leaving significant gaps 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but includes redundant sections ('Arguments:', 'Returns:') that repeat information without adding value. It is concise in length but could be more streamlined by integrating parameter and return details into a single coherent sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic purpose and return format but misses parameter semantics, usage context, and detailed behavioral traits. For a tool with such sparse structured data, more comprehensive guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists 'database_name' as an argument but provides no semantic details (e.g., format, examples, or that it's optional with a default of null). This minimal information is insufficient to bridge the coverage gap, warranting a low 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 tool's purpose: 'Lists all tables in a database.' It specifies the verb ('Lists') and resource ('tables in a database'), making the function unambiguous. However, it does not differentiate from sibling tools like 'base_databaseList' or 'dba_tableSqlList', which prevents a score of 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'base_databaseList' (lists databases) and 'dba_tableSqlList' (likely lists SQL for tables), there is no indication of when this specific table-listing tool is preferred, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 SQLAlchemy, bind parameters, and returning rendered SQL in metadata, which adds useful context about implementation details. However, it lacks critical behavioral traits: whether this is a read-only operation, if it requires specific permissions, performance implications (e.g., heavy query), or what 'measure' entails (e.g., counts, timestamps, frequency). The disclosure is incomplete for a tool that likely queries system tables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with two sentences, but the structure could be improved. The first sentence is long and combines purpose with implementation details (SQLAlchemy, bind parameters). The second sentence about returns is somewhat redundant given the 'Returns:' section below. It's front-loaded with the core purpose, but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and 1 parameter, the description is incomplete. It lacks: clarification on database_name vs. schema scope, what 'measure' outputs (metrics type), permissions needed, performance impact, and how it differs from similar tools like dba_tableUsageImpact. For a tool that likely queries system usage data, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'database_name' in the Arguments section without explaining its role or semantics. The description text says 'in a given schema', but the parameter is named database_name (not schema_name), creating potential confusion. No details on format, allowed values, or what happens if null (default). The description adds minimal value beyond the 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 tool's purpose: 'Measure the usage of a table and views by users in a given schema' with the specific verb 'measure' and resources 'table and views'. It distinguishes from siblings like base_tableList (lists tables) or base_tablePreview (shows data) by focusing on usage metrics. However, it doesn't explicitly differentiate from dba_tableUsageImpact which might be a closer sibling.
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 minimal usage guidance. It states this is 'helpful to infer what database objects are most actively used or drive most value', which gives some context, but offers no explicit when-to-use vs. when-not-to-use guidance or mentions of alternative tools like dba_tableUsageImpact or dba_featureUsage. The agent must 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'Get permissions' and returns a 'formatted response with query results + metadata,' but lacks details on permissions needed, rate limits, error handling, or what 'metadata' entails. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with clear sections for arguments and returns, avoiding unnecessary details. However, the 'Returns' section could be more informative, and the overall text is somewhat sparse, though not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavioral traits, error cases, and the format of the 'formatted response,' making it inadequate for a tool that likely involves security or permissions 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 0%, but the description adds minimal value by specifying 'role_name - role name to analyze.' This clarifies the parameter's purpose slightly beyond the schema's title 'Role Name.' However, with only one parameter and low coverage, the description does not fully compensate, aligning with the baseline for minimal parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose as 'Get permissions for a role,' which is a clear verb+resource combination. However, it does not differentiate from sibling tools like 'sec_userDbPermissions' or 'sec_userRoles,' leaving ambiguity about scope and specificity. The purpose is understandable but lacks distinction from related tools.
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 such as 'sec_userDbPermissions' or 'sec_userRoles.' The description only states what it does without context, prerequisites, or exclusions, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool 'bind parameters if provided (prepared SQL), and return the fully rendered SQL (with literals) in metadata', which adds some context about output behavior. However, it lacks details on permissions, rate limits, side effects, or what 'commonly used together' means operationally, leaving significant gaps for a tool that likely queries database metadata.
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: purpose statement, parameter binding note, and return information. It's front-loaded with the core purpose. However, the parameter list uses 'object_name' while the schema uses 'obj_name', causing minor confusion that slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and 2 parameters, the description is incomplete. It mentions SQL binding and metadata returns but doesn't explain the response structure, error handling, or what 'formatted response' entails. For a tool that infers table relationships, more context on methodology or output interpretation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It lists 'database_name' and 'object_name' in the Arguments section, but the input schema uses 'obj_name' (not 'object_name'), creating a mismatch. The description adds minimal semantics (e.g., 'table or view name' for object_name), but doesn't clarify format, constraints, or examples, failing to fully address the coverage gap.
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 tables commonly used together by database users' and mentions it helps 'infer relationships between tables via SQLAlchemy'. It specifies the verb ('Get') and resource ('tables commonly used together'), but doesn't explicitly differentiate from siblings like base_tableUsage or base_tableList, which likely serve different purposes.
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 minimal guidance on when to use this tool, stating it's 'helpful to infer relationships between tables', but doesn't specify when to choose it over alternatives like base_tableUsage or base_tableDDL. No explicit when/when-not instructions or prerequisite context are provided, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning 'data sample and inferred structure' and 'fully rendered SQL (with literals) in metadata', which gives some behavioral insight. However, it lacks details on sample size, structure inference method, error handling, permissions required, or performance implications, leaving significant gaps for a tool that interacts with databases.
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, with the core purpose stated first. The 'Arguments' and 'Returns' sections add structure, though 'ResponseType' is vague. No redundant sentences are present, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It hints at outputs ('data sample', 'inferred structure', 'metadata') but lacks specifics on format or content. For a database tool with two parameters and complex behavior, this leaves too much undefined for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters 'table_name' and 'database_name' with brief notes ('table or view name', 'Database name'), but adds minimal semantic value beyond the schema's titles. It doesn't explain format expectations, constraints, or how null database_name is handled, failing to adequately cover the 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: 'returns data sample and inferred structure from a database table or view via SQLAlchemy'. It specifies the verb ('returns'), resource ('database table or view'), and mechanism ('via SQLAlchemy'), though it doesn't explicitly differentiate from siblings like base_tableList or base_readQuery.
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. With siblings like base_tableList (likely lists tables), base_readQuery (likely executes queries), and base_tableDDL (likely shows schema), the description offers no context for choosing this tool for previewing table data and structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 'formatted response with query results + metadata,' which hints at output format but lacks details on permissions, rate limits, or side effects (e.g., whether it's read-only or has performance impacts). For a tool with no annotations, this is insufficient to fully inform usage.
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 front-loaded with the core purpose in the first sentence, followed by structured sections for arguments and returns. It's efficient with minimal waste, though the 'Arguments' and 'Returns' sections could be integrated more seamlessly. Overall, it's appropriately sized and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, parameter usage, and output specifics beyond a vague mention of 'formatted response.' For a data analysis tool with siblings, more context is needed to ensure proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for the three parameters. The description lists the parameters ('database_name', 'table_name', 'column_name') but doesn't add meaningful semantics beyond their names, such as format examples, constraints, or how they interact. This fails to compensate for the low schema coverage, leaving parameters poorly documented.
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 the rows with missing values in a table.' This specifies the verb ('Get') and resource ('rows with missing values'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'qlty_missingValues' or 'qlty_columnSummary', which might offer similar functionality, so it doesn't reach 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 'qlty_missingValues' (which might summarize missing values) or 'qlty_columnSummary' (which could include missing value stats), nor does it specify prerequisites or exclusions. This lack of context makes it harder for an AI agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool 'displays' DDL and returns 'fully rendered SQL (with literals) in metadata,' implying a read-only operation. However, it lacks details on permissions, rate limits, error handling, or what 'metadata' includes. For a tool with zero annotation coverage, this is insufficient, scoring a 2 due to missing 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 front-loaded with the core purpose, followed by arguments and returns sections. It uses three sentences efficiently, with no wasted words. However, the 'Arguments' and 'Returns' labels could be integrated more smoothly, and some redundancy exists (e.g., 'via SQLAlchemy' and 'prepared SQL'), slightly reducing conciseness, hence a 4.
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 2 parameters, no annotations, and no output schema, the description is moderately complete. It covers the tool's purpose and parameters but lacks details on behavioral traits, error cases, or output structure. For a read-only tool with low complexity, this is adequate but has clear gaps, scoring a 3 as minimum viable.
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 0%, so the description must compensate. It lists the parameters (database_name and table_name) and their roles, adding meaning beyond the schema's generic titles. However, it doesn't explain format constraints (e.g., case sensitivity) or provide examples. With two parameters partially documented, this meets the baseline of 3 for marginal value over the 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 tool's purpose: 'Displays the DDL definition of a table via SQLAlchemy' and 'return the fully rendered SQL (with literals) in metadata.' It specifies the verb ('displays'), resource ('DDL definition of a table'), and method ('via SQLAlchemy'), distinguishing it from siblings like base_tableList or base_tablePreview. However, it doesn't explicitly differentiate from base_tableAffinity or base_tableUsage, which might also involve table metadata, keeping it at a 4 rather than a 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'bind parameters if provided' but doesn't specify scenarios or prerequisites, such as when DDL is needed versus other table-related tools like base_tablePreview for data viewing. Without explicit when/when-not instructions or named alternatives, this scores a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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's a read operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, response format, pagination, or whether it aggregates data. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 front-loads the core purpose. Every word earns its place with no redundancy or wasted text, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'user feature usage metrics' includes, how results are structured, or any limitations. For a tool with 2 parameters and potential complexity in metrics, more context is needed for 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?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds value by specifying that parameters define a 'date range', but doesn't explain the format (e.g., YYYY-MM-DD), timezone handling, or whether dates are inclusive. It compensates partially but not fully for the schema gap.
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 'user feature usage metrics', specifying the scope with 'for a specified date range'. It distinguishes from many sibling tools that focus on tables, databases, or other metrics, but doesn't explicitly differentiate from potential similar usage tools like 'dba_tableUsage' or 'dba_userSqlList'.
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, exclusions, or compare with sibling tools like 'dba_tableUsage' or 'dba_userSqlList' that might overlap in usage scenarios. The date range requirement is implied but not framed as a usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates a read operation ('Get') but lacks details on permissions, rate limits, output format, or any side effects. 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 front-loads the key information (action, resource, scope) with zero wasted words. It's 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'flow control metrics' entail, how results are returned, or any behavioral traits, making it inadequate for a tool with no structured support.
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 meaning by specifying that parameters define a 'date range', which clarifies the purpose of 'start_date' and 'end_date' beyond their schema titles. However, with 0% schema description coverage, it doesn't fully compensate by detailing format (e.g., YYYY-MM-DD) or constraints, so it meets the baseline for partial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('Teradata flow control metrics') with scope ('for a specified date range'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'dba_resusageSummary' or 'dba_sessionInfo', which might also retrieve metrics, so it's not fully specific to sibling context.
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, such as other dba_* tools for different metrics or date-based queries. It mentions a date range but doesn't specify prerequisites, exclusions, or comparative contexts with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a 'Get' operation, implying it's likely read-only, but doesn't confirm if it requires specific permissions, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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 unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. There's no wasted verbiage, and it fits well within the context of a concise tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a database session information tool with no annotations, no output schema, and a parameter with 0% schema coverage, the description is insufficient. It doesn't explain what 'session information' includes (e.g., connection details, queries, status), how results are structured, or any behavioral aspects like error handling. This leaves too many unknowns for effective tool invocation.
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 mentions 'for user', which aligns with the single parameter 'user_name', but adds no further semantic context beyond what the schema's title 'User Name' implies. With 0% schema description coverage, the parameter is undocumented in the schema, but the description only partially compensates by hinting at its purpose without detailing format or examples. This meets the baseline for minimal compensation.
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 'Teradata session information for user', making the purpose unambiguous. It specifies the target resource (session information) and the scope (for a specific user). However, it doesn't explicitly differentiate from sibling tools like 'dba_userSqlList' or 'dba_userDelay', which might also relate to user-specific database information.
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 for usage, or compare it to sibling tools like 'dba_userSqlList' (which might list SQL queries) or 'dba_userDelay' (which might show user delays). Without such guidance, an agent might struggle to choose between these user-focused dba tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 'formatted response with query results + metadata,' which gives some output context, but lacks details on permissions, rate limits, pagination, error handling, or whether it's read-only/destructive. For a tool with no annotation coverage, this is insufficient.
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 and well-structured: a clear purpose statement followed by bullet points for arguments and returns. Every sentence adds value without redundancy. However, the 'Returns' section could be more specific about the 'formatted response' structure.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameters but lacks usage guidelines, detailed behavioral context, and output specifics. For a tool that retrieves SQL history, more context on permissions, data scope, and result format would improve 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 0%, so the schema provides no parameter descriptions. The description adds basic semantics: 'table_name - table name' and 'no_days - number of days,' explaining what each parameter represents. However, it doesn't clarify format constraints (e.g., table name syntax), default behavior (no_days defaults to 7 per schema), or valid ranges, leaving gaps in parameter 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: 'Get a list of SQL run against a table in the last number of days.' This specifies the verb ('Get'), resource ('SQL run against a table'), and temporal scope ('last number of days'). However, it doesn't explicitly differentiate from sibling tools like 'dba_userSqlList' or 'sql_Retrieve_Cluster_Queries', which may have overlapping functionality.
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 'dba_userSqlList' (for user-specific SQL) or 'base_tableUsage' (for general table usage), nor does it specify prerequisites, exclusions, or appropriate contexts for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 measuring usage and understanding resource drivers, but fails to disclose critical behavioral traits: whether this is a read-only operation, if it requires specific permissions, potential performance impact, rate limits, or output format. For a tool with 'dba' prefix suggesting administrative functions, this omission is significant.
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 two sentences: one stating the purpose and benefit, followed by a structured 'Arguments' list. It's front-loaded with the core function. While efficient, the second sentence could be more direct, and the structure is clear but not perfectly polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (administrative usage analysis), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It covers basic purpose and parameters but misses behavioral context, output details, and sibling differentiation. For a tool likely involving system metrics, more guidance on permissions, impact, and result interpretation is needed.
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 0%, but the description includes an 'Arguments' section that lists and briefly describes both parameters ('database_name - database name to analyze', 'user_name - user name to analyze'). This adds meaningful semantics beyond the schema's titles, clarifying their purpose. However, it doesn't detail format, constraints, or interaction effects, leaving gaps.
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: 'Measure the usage of a table and views by users' with the goal of 'understanding what user and tables are driving most resource usage.' This specifies the verb (measure), resource (table and views usage), and context (resource usage analysis). However, it doesn't explicitly differentiate from sibling tools like 'base_tableUsage' or 'dba_featureUsage,' which likely have overlapping purposes.
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 minimal guidance: 'this is helpful to understand what user and tables are driving most resource usage at any point in time.' It implies usage for resource analysis but offers no explicit when-to-use instructions, alternatives (e.g., vs. 'base_tableUsage'), prerequisites, or exclusions. Without clear differentiation from siblings, the agent lacks 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.
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 implies a read-only operation ('Get') but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or the format of returned metrics. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the key information (action and resource) without any wasted words. It's appropriately sized for a simple tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain what 'user delay metrics' entail, how results are structured, or any behavioral traits, making it inadequate for an agent to fully understand the tool's operation.
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 mentions 'date range' which aligns with the two parameters (start_date and end_date), adding some context beyond the schema. However, with 0% schema description coverage, it doesn't specify date formats, time zones, or validation rules, so it only partially compensates for the schema's lack of detail.
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 resource ('Teradata user delay metrics') with scope ('for a specified date range'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'dba_sessionInfo' or 'dba_resusageSummary', which might also provide user-related metrics, so it falls short of 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, such as other 'dba_' tools that might offer related metrics. It mentions a date range but doesn't specify prerequisites, exclusions, or typical use cases, leaving the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 return type ('formatted response with query results + metadata'), which adds some context, but fails to describe critical behaviors such as whether this is a read-only operation, performance implications, error handling, or data access permissions required.
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 sections for arguments and returns. There's minimal waste, though the 'Arguments' and 'Returns' sections could be integrated more fluidly into the narrative.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the basic purpose and parameters but lacks behavioral context (e.g., safety, performance) and usage guidelines. Without annotations or output schema, more detail on return values and operational constraints would improve 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 0%, so the description must compensate. It lists the two parameters ('database_name' and 'table_name') and briefly explains their purpose ('name of the database', 'table name to analyze'), adding basic semantics beyond the schema's titles. However, it doesn't provide details like format constraints, examples, or default behaviors for null values (e.g., 'database_name' can be null).
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 the column summary statistics for a table.' This specifies the verb ('Get'), resource ('column summary statistics'), and target ('for a table'). However, it doesn't explicitly differentiate from sibling tools like 'qlty_univariateStatistics' or 'qlty_distinctCategories', which likely provide related statistical analyses.
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 'qlty_univariateStatistics' or 'base_tablePreview' that might serve similar or complementary purposes, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 'formatted response with query results + metadata', which hints at output format but lacks details on permissions, rate limits, error handling, or whether it's read-only/destructive. For a tool with zero annotation coverage, this is insufficient to inform safe and effective use.
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 purpose is stated first, followed by arguments and returns sections. Each sentence adds value without redundancy. However, the structure could be improved by integrating usage context or behavioral details more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers purpose and basic parameters but lacks behavioral transparency, usage guidelines, and detailed output explanation. For a data quality tool in a complex sibling set, more context is needed to ensure correct agent invocation.
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 0%, so the schema provides no parameter details. The description lists arguments ('database_name - name of the database', 'table_name - table name to analyze'), adding basic semantics beyond the schema's titles. However, it doesn't explain format constraints, examples, or optionality (e.g., 'database_name' can be null per schema), 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: 'Get the column names that having missing values in a table.' It specifies the verb ('Get') and resource ('column names'), and distinguishes it from siblings like 'qlty_rowsWithMissingValues' (which likely returns rows rather than columns). However, it doesn't explicitly differentiate from all siblings, such as 'qlty_columnSummary' which might include missing value info among other statistics.
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 (e.g., database connection), exclusions (e.g., when to use 'qlty_rowsWithMissingValues' instead), or context for selection among sibling tools like 'qlty_columnSummary' or 'base_columnDescription'. Usage is implied only by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 'formatted response with query results + metadata,' but doesn't specify what 'metadata' includes, performance implications, error handling, or data sensitivity. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 sections for arguments and returns. There's minimal waste, though the 'Returns' section could be more concise by integrating with the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing table data for negative values), lack of annotations, and no output schema, the description is incomplete. It doesn't cover output format details (e.g., structure of results, metadata fields), error cases, or performance considerations, which are crucial for effective use in a data quality context.
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 0%, so the description must compensate. It lists the two parameters (database_name and table_name) and their roles, adding meaning beyond the schema's basic titles. However, it doesn't explain parameter constraints (e.g., valid database/table names, null handling for database_name) or provide examples, leaving some semantic gaps.
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 the column names that having negative values in a table.' It specifies the verb ('Get') and resource ('column names'), and distinguishes itself from siblings like qlty_missingValues or qlty_columnSummary by focusing on negative values. However, it doesn't explicitly differentiate from all siblings, such as qlty_univariateStatistics, which might also reveal negative values indirectly.
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 (e.g., needing a database connection), exclusions (e.g., not for non-numeric columns), or suggest sibling tools like qlty_columnSummary for broader analysis. Usage is implied only by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns 'formatted response with query results + metadata' but doesn't specify what that metadata includes, whether the operation is read-only or has side effects, performance characteristics, or error conditions. For a statistical calculation tool with zero annotation coverage, 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 clear sections (purpose, arguments, returns). The purpose statement is front-loaded. However, the 'Arguments' and 'Returns' sections could be integrated more naturally rather than as separate bullet points, and some phrasing could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a statistical calculation tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what type of data the column should contain (numeric vs categorical), how missing values are handled, precision of results, or provide examples. The return format description is vague ('formatted response with query results + metadata').
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 0%, so the schema provides only titles without descriptions. The description lists the three parameters with brief explanations ('name of the database', 'table name to analyze', 'column name to analyze'), adding basic semantic meaning beyond the schema. However, it doesn't clarify what happens if database_name is null (as allowed by schema), provide format examples, or explain constraints.
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 with a specific verb ('Get') and resource ('standard deviation from column in a table'). It distinguishes itself from siblings like 'qlty_columnSummary' or 'qlty_univariateStatistics' by focusing specifically on standard deviation, but doesn't explicitly contrast with them. The purpose is clear but sibling differentiation could be more explicit.
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. With many sibling tools for data quality analysis (e.g., qlty_columnSummary, qlty_univariateStatistics, qlty_missingValues), there's no indication of when standard deviation calculation is preferred over other statistical measures or combined analyses. No prerequisites or context for usage is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 'formatted response with query results + metadata', which gives some insight into output behavior. However, it lacks details on permissions, rate limits, error handling, or whether it's a read-only operation (implied by 'Get' but not explicit). For a tool with no annotations, 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 well-structured, with a clear purpose statement followed by bullet points for arguments and returns. Every sentence earns its place, and it's front-loaded with the main functionality. It could be slightly more concise by integrating the bullet points into a single paragraph, 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 (statistical analysis with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose and parameters but lacks behavioral details and usage guidelines. The mention of return type ('formatted response with query results + metadata') helps, but without an output schema, it's insufficient for full contextual understanding.
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 lists the three parameters (database_name, table_name, column_name) and their roles, adding meaning beyond the input schema, which has 0% description coverage. This compensates partially for the schema gap by clarifying what each parameter represents. However, it doesn't provide details on allowed values, formats, or constraints, leaving some semantic gaps.
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 the univariate statistics for a table.' It specifies the verb ('Get') and resource ('univariate statistics for a table'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'qlty_columnSummary' or 'qlty_standardDeviation', which might offer overlapping or related functionality.
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. With sibling tools like 'qlty_columnSummary' and 'qlty_standardDeviation' available, there's no indication of how this tool differs or when it's preferred. The lack of context or exclusions leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 permissions for a user' and mentions a return type, but doesn't describe what permissions are retrieved (e.g., database, table, or system-level), whether it requires admin privileges, if it's read-only or has side effects, or any rate limits. For a security-related tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The arguments and returns sections are structured but could be more integrated. There's no wasted text, though it could be slightly more polished (e.g., combining sections).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a security tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on what permissions are returned, how they're formatted, error conditions, or authentication requirements. The mention of 'ResponseType: formatted response with query results + metadata' is vague and doesn't substitute for proper output documentation.
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 minimal semantics for the single parameter 'user_name' by stating it's 'user name to analyze', which slightly clarifies beyond the schema's 'User Name' title. However, with 0% schema description coverage, the description doesn't fully compensate—it doesn't specify format constraints (e.g., case sensitivity, domain inclusion) or provide examples. The baseline is 3 due to the single parameter, but value added is limited.
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 with 'Get permissions for a user', which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'sec_rolePermissions' or 'sec_userRoles', which likely handle related but different security aspects. The purpose is clear but lacks sibling differentiation.
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 prerequisites, context, or comparisons to sibling tools like 'sec_rolePermissions' or 'sec_userRoles', which might handle overlapping or complementary functionality. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 return type as 'formatted response with query results + metadata,' which adds some context beyond the basic purpose. However, it fails to describe critical traits such as whether this is a read-only operation, authentication requirements, rate limits, or error handling, leaving significant gaps for a security-related tool.
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 and front-loaded, starting with the core purpose followed by arguments and returns in a clear format. It uses minimal sentences without redundancy, making it efficient. However, the 'Returns' section could be more concise by integrating with the purpose statement, slightly reducing its score.
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 moderate complexity (security-related user role retrieval), no annotations, no output schema, and low schema coverage, the description is partially complete. It covers the purpose and parameter but lacks behavioral details, usage guidelines, and output specifics. This is adequate for basic understanding but has clear gaps for effective agent 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 includes an 'Arguments' section that documents the 'user_name' parameter, adding meaning beyond the input schema, which has 0% description coverage. However, it only covers the single parameter without details on format, constraints, or examples. With one parameter and partial documentation, this meets the baseline for adequate but incomplete 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 with 'Get roles assigned to a user,' specifying the verb 'Get' and resource 'roles assigned to a user.' It distinguishes from siblings like 'sec_rolePermissions' and 'sec_userDbPermissions' by focusing on user roles rather than role permissions or database permissions. However, it doesn't explicitly differentiate from all siblings, such as general user analysis tools, keeping it at 4 instead of 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?
The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, exclusions, or comparisons with sibling tools like 'sec_rolePermissions' or 'sec_userDbPermissions,' which handle related security aspects. Without explicit usage instructions, the agent must infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the tool's behavior (conditional fetching based on input) and output format ('formatted response with query results + metadata'), but lacks details on permissions, rate limits, error handling, or whether it's read-only/destructive. For a tool with no annotation coverage, this is a significant gap 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 sized and front-loaded: the first sentence clearly states the tool's purpose and logic. The additional 'Arguments' and 'Returns' sections are concise but redundant with the schema and output description. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and conditional logic but lacks completeness. It doesn't cover parameter details, behavioral traits like safety or performance, or output specifics beyond a vague 'formatted response'. For a tool with two parameters and no structured support, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds minimal semantics: it explains that 'database_name' and 'table_name' are used conditionally to fetch space for all tables or a specific table. However, it doesn't specify format requirements, constraints, or interactions between parameters (e.g., what happens if both are provided), leaving key aspects undocumented.
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 table space used for a table if table name is provided or get table space for all tables in a database if a database name is provided.' It specifies the verb ('get') and resource ('table space'), and distinguishes between two modes based on input. However, it doesn't explicitly differentiate from sibling tools like 'dba_databaseSpace' or 'dba_systemSpace', which likely handle different space metrics.
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 guidelines by stating the conditional logic: use table_name for a specific table's space, or database_name for all tables in a database. However, it doesn't provide explicit when-to-use vs. alternatives (e.g., compared to 'dba_databaseSpace' for database-level space or 'base_tableUsage' for other table metrics), 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.
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 return type ('formatted response with query results + metadata'), which adds some behavioral context beyond the basic listing action. However, it lacks details on permissions, rate limits, or any destructive implications, leaving significant gaps for a 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 front-loaded with the core purpose in the first sentence, followed by a brief note on the return type. It is appropriately sized with no wasted words, though the return note could be slightly more integrated for optimal structure.
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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and hints at the return format, but for a read operation in a system with many siblings, it lacks sufficient context on usage and behavioral traits to be considered complete.
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, and the schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information and focuses on the tool's purpose and output.
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 ('all databases in the Teradata System'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'base_tableList' or 'dba_databaseSpace', which might have overlapping or related functionality, preventing 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, such as 'base_tableList' for tables or 'dba_databaseSpace' for space details. It lacks explicit context, prerequisites, 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.
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 describes the basic conditional behavior but lacks details on permissions required, rate limits, whether it's read-only or has side effects, error handling, or the format of the 'formatted response with query results + metadata'. For a tool with no annotation coverage, 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 with three sentences: a clear purpose statement, a parameter explanation, and a return value note. It's front-loaded with the core functionality. There's no wasted text, though it could be slightly more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a database query tool with conditional behavior), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return format in detail (e.g., what metadata is included), error conditions, or how it interacts with sibling tools. For a tool with these gaps, it should provide more context 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?
The description adds minimal semantics: it explains that 'database_name' is the database name and clarifies the conditional behavior (null for all databases). However, with 0% schema description coverage and only 1 parameter, it doesn't fully compensate by detailing format constraints, examples, or implications beyond what's implied. The baseline is 3 since the schema lacks descriptions, but the description provides some value.
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 database space if database name is provided, otherwise get all databases space allocations.' This specifies the verb ('Get') and resource ('database space') with conditional logic. However, it doesn't explicitly differentiate from sibling tools like 'dba_systemSpace' or 'dba_tableSpace', which likely handle different scopes of space information.
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 through the conditional logic: use with a database_name for specific space, or without (null) for all databases. However, it doesn't explicitly state when to choose this tool over alternatives like 'dba_systemSpace' (for system-level space) or 'dba_tableSpace' (for table-level space), 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.
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 retrieves SQL lists based on user and time filters, but lacks details on permissions required, rate limits, pagination, error handling, or what 'formatted response with query results + metadata' entails. For a tool with no annotation coverage, 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 clearly states the purpose, followed by bullet points for arguments and returns. There is minimal waste, though the bullet points could be integrated more seamlessly. Overall, it is efficient and structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (filtering SQL by user/time), lack of annotations, and no output schema, the description is incomplete. It does not explain the return format beyond 'formatted response with query results + metadata', nor does it cover behavioral aspects like authentication needs or limitations. For a tool with 2 parameters and no structured support, more context is needed to ensure proper 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 0%, so the description must compensate. It adds meaning by explaining that 'user_name' filters results by user (or if omitted, returns all SQL) and 'no_days' specifies the time window. However, it does not detail data types, constraints (e.g., valid ranges for 'no_days'), or default behavior beyond the schema's default of 7 days. This provides basic semantics but leaves gaps in parameter 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: 'Get a list of SQL run by a user in the last number of days if a user name is provided, otherwise get list of all SQL in the last number of days.' This specifies the verb ('Get a list'), resource ('SQL'), and scope ('by a user' or 'all'). However, it does not explicitly differentiate from sibling tools like 'dba_tableSqlList' or 'sql_Retrieve_Cluster_Queries', which may have overlapping functionality, so it falls short of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining the conditional logic: use with a user_name to filter by user, or without to get all SQL. However, it does not provide explicit guidance on when to choose this tool over alternatives like 'dba_tableSqlList' or 'sql_Retrieve_Cluster_Queries', nor does it mention prerequisites or exclusions. This leaves room for ambiguity in tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 uses SQLAlchemy, supports bind parameters for prepared SQL, and returns fully rendered SQL with literals in metadata. However, it doesn't mention permissions needed, rate limits, error handling, or what 'detailed column information' specifically includes (e.g., data types, constraints).
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 additional details about arguments and returns. There's minimal waste, though the 'Arguments' and 'Returns' sections could be integrated more smoothly into the narrative 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 2 parameters with 0% schema coverage and no output schema, the description provides basic context but lacks depth. It explains what the tool does and its parameters but doesn't detail the response format beyond 'formatted response with query results + metadata', which is vague. For a tool with no annotations, more behavioral and output specifics would improve 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 0%, so the schema provides no parameter descriptions. The description lists the two parameters (database_name and obj_name) with brief explanations, adding meaning beyond the bare schema. However, it doesn't clarify what 'obj_name' encompasses (e.g., table vs. view specifics) or provide examples, leaving some ambiguity.
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: 'Shows detailed column information about a database table via SQLAlchemy'. It specifies the verb ('shows'), resource ('detailed column information'), and technology ('SQLAlchemy'). However, it doesn't explicitly differentiate from sibling tools like qlty_columnSummary or base_tableDDL, which may also provide column-related information.
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. With many sibling tools (e.g., qlty_columnSummary, base_tableDDL, base_tableList) that might overlap in functionality, there's no indication of when this specific tool is appropriate or what distinguishes it from other column or table analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: execution via SQLAlchemy, parameter binding for prepared SQL, and metadata inclusion of rendered SQL. However, it lacks details on permissions, error handling, rate limits, or what 'formatted response' entails. For a tool that executes arbitrary SQL queries, this is a moderate gap in safety and operational 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 appropriately sized and front-loaded, with the core purpose in the first sentence and parameter details in a structured 'Arguments' section. Every sentence adds value, though the 'Returns' section could be more specific. It avoids redundancy and is efficiently organized for quick comprehension.
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 (executing arbitrary SQL queries), lack of annotations, no output schema, and 0% schema coverage, the description is moderately complete. It covers the basic action and parameter intent but omits critical context like security implications, result formatting, error cases, or how it differs from sibling tools. This is adequate but has clear gaps 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'sql' is 'SQL text, with optional bind-parameter placeholders', which clarifies the parameter's purpose beyond the schema's generic 'string/null' type. However, it doesn't detail placeholder syntax, SQL dialect, or constraints, leaving some ambiguity for a critical parameter.
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: 'Execute a SQL query via SQLAlchemy, bind parameters if provided (prepared SQL), and return the fully rendered SQL (with literals) in metadata.' This specifies the action (execute SQL query), technology (SQLAlchemy), and key behavior (return rendered SQL in metadata). However, it doesn't explicitly differentiate from sibling tools like 'sql_Execute_Full_Pipeline' or 'rag_Execute_Workflow' that might also execute queries.
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. With many sibling tools (e.g., 'sql_Execute_Full_Pipeline', 'base_tablePreview'), there's no indication of whether this is for raw SQL execution, specific query types, or particular contexts. Usage is implied only by the action described, with no explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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]' information, implying a read-only operation, but does not specify whether it requires authentication, has rate limits, returns structured or raw data, or any error conditions. This leaves significant gaps for an agent to understand how to invoke it safely and effectively.
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, clear sentence with no wasted words. It is front-loaded with the core purpose ('Get Teradata database version information'), making it easy to parse. Every part of the sentence contributes directly to understanding the tool's function.
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 0 parameters, no annotations, and no output schema, the description is minimally adequate by stating what it does. However, it lacks details on return format (e.g., version string or structured data), which is critical for an agent to process results. For a simple read tool, this omission reduces completeness, though the low complexity keeps it from being severely inadequate.
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, meaning no parameters are documented in the schema. The description does not add parameter details, which is appropriate since there are none to describe. It implicitly confirms the lack of inputs by not mentioning any, aligning with the 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 action ('Get') and resource ('Teradata database version information'), making the purpose immediately understandable. It distinguishes from siblings like 'dba_databaseSpace' or 'dba_sessionInfo' by focusing specifically on version data rather than space or session details. However, it lacks explicit sibling differentiation beyond the inherent scope difference.
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 does not mention prerequisites, context (e.g., for system monitoring or compatibility checks), or exclusions. Given siblings like 'dba_databaseList' or 'dba_featureUsage', there is no explicit comparison to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('Get'), but doesn't specify if it requires special permissions, has rate limits, returns aggregated or real-time data, or details the output format. For a tool with zero annotation coverage, 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.
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 front-loaded and appropriately sized for a simple tool, making it highly concise and well-structured.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral details and usage guidelines, which are important for a tool that likely returns system-level data. The absence of an output schema means the description should ideally hint at the return format, but it doesn't.
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, and the schema description coverage is 100%, so no parameter information is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('Teradata total system database space usage'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'dba_databaseSpace' or 'dba_tableSpace', which likely provide more granular space usage data, so it doesn't fully distinguish from alternatives.
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 such as 'dba_databaseSpace' or 'dba_tableSpace'. It lacks any context about prerequisites, timing, or exclusions, leaving the agent without usage instructions beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 retrieves summary metrics but doesn't specify whether this is a read-only operation, if it requires special permissions, what the output format looks like, or if there are rate limits. For a tool with 8 parameters and no annotation coverage, 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 well-structured with a clear purpose statement followed by detailed parameter documentation. Every sentence earns its place by providing essential information. It could be slightly more concise by integrating the parameter explanations more tightly, but overall it's efficiently organized and front-loaded.
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 (8 parameters, no annotations, no output schema), the description does a good job explaining parameters but falls short on behavioral context. It adequately covers what the tool does and how to use parameters, but doesn't address output format, error conditions, or system requirements. For a data retrieval tool with many filtering options, more contextual guidance would be helpful.
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?
The description provides excellent parameter semantics beyond the schema. With 0% schema description coverage, the description fully compensates by listing all 8 parameters with clear explanations, examples for workloadType, workloadComplexity, and AppId, and a comprehensive list of possible values for the dimensions parameter. This adds substantial value over the bare schema.
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'), resource ('Teradata system usage summary metrics'), and scope ('by weekday and hour for each workload type and query complexity bucket'). It distinguishes this tool from siblings like dba_databaseSpace or dba_featureUsage by focusing on aggregated usage metrics across temporal and workload dimensions.
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 the purpose is clear, there's no mention of prerequisites, typical use cases, or comparison to sibling tools like dba_userDelay or dba_tableUsageImpact that might offer related insights. The description lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 does an excellent job describing the multi-step workflow, performance metrics, configuration details, and prerequisites. However, it doesn't explicitly state whether this is a read-only or destructive operation, nor does it mention execution time, resource requirements, or error handling. For a complex pipeline tool, these omissions prevent a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While well-structured with clear sections, the description is quite lengthy with multiple detailed subsections. Some information (like specific metric explanations and configuration details) could potentially be streamlined. The core purpose and workflow are front-loaded, but subsequent sections add substantial bulk that may not all be essential for tool selection.
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 complex 2-parameter tool with no annotations and no output schema, the description provides extensive context about the workflow, metrics, configuration, prerequisites, and follow-up steps. However, it doesn't describe what the tool returns (output format/results) or potential limitations/errors. Given the complexity, a complete description would include information about outputs and failure modes.
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?
With 0% schema description coverage for the 2 parameters, the description must compensate. It mentions 'optimal_k parameter' and 'top {default_max_queries} queries by CPU time (configurable)' which provides context for what the parameters control. However, it doesn't explicitly name the parameters or provide value ranges/constraints, leaving some ambiguity about how they affect the pipeline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'executes the entire SQL query clustering workflow to identify and analyze high CPU usage queries for optimization opportunities.' It provides a specific verb ('executes'), resource ('SQL query clustering workflow'), and distinguishes from siblings like sql_Analyze_Cluster_Stats and sql_Retrieve_Cluster_Queries by emphasizing it's the 'complete pipeline' versus their more focused analysis roles.
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 includes explicit guidance on when to use this tool versus alternatives: 'After running this tool, use: 1. sql_Analyze_Cluster_Stats to identify problematic clusters 2. sql_Retrieve_Cluster_Queries to get actual SQL from target clusters.' It also provides clear prerequisites and use cases, making it easy to determine when this tool is appropriate versus other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behaviors: it's a read-only analysis tool (implied by 'analyzes' and no mention of modifications), uses configurable thresholds from sql_opt_config.yml, categorizes clusters automatically, and returns detailed statistics for LLM analysis. However, it doesn't mention potential limitations like data freshness or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (ANALYSIS CAPABILITIES, AVAILABLE SORTING METRICS, etc.), but it's overly verbose at 400+ words. Some content like the 'OPTIMIZATION DECISION FRAMEWORK' could be condensed, and not every sentence earns its place for a tool with only 2 parameters. However, it remains readable and front-loaded with key purpose.
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 of SQL cluster analysis and no output schema, the description provides substantial context: capabilities, metrics, categorization, workflow, and output format. It compensates well for the lack of annotations and schema descriptions. However, without an output schema, it could benefit from more specific details about the return structure (e.g., fields in the statistics).
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?
Schema description coverage is 0%, so the description must fully compensate. It provides extensive parameter semantics: it explains that 'sort_by_metric' accepts specific metrics like 'avg_cpu' or 'avg_io' (listing 9 options with explanations), and 'limit_results' is used to 'focus on top problematic clusters' in the workflow section. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'analyzes pre-computed cluster statistics to identify optimization opportunities without re-running the clustering pipeline.' It specifies the verb 'analyzes' and resource 'pre-computed cluster statistics,' and clearly distinguishes from sibling tools like sql_Execute_Full_Pipeline (which runs the pipeline) and sql_Retrieve_Cluster_Queries (which retrieves queries).
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: 'Perfect for iterative analysis and decision-making on which query clusters to focus optimization efforts.' It includes a 'TYPICAL ANALYSIS WORKFLOW' section with step-by-step instructions and references alternatives like sql_Execute_Full_Pipeline implicitly by stating it works 'without re-running the clustering pipeline.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 does well by explaining the tool's capabilities (e.g., pattern recognition, performance correlation), output format ('Complete SQL query text for each query, all performance metrics...'), and workflow context. However, it doesn't explicitly mention potential side effects (e.g., read-only nature, performance impact on the database) or error conditions, which would be helpful for a tool interacting with production systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (e.g., DETAILED ANALYSIS CAPABILITIES, QUERY SELECTION STRATEGIES), but it's overly verbose at 500+ words. Some sections like 'AUTOMATIC PERFORMANCE CATEGORIZATION' and 'TYPICAL OPTIMIZATION WORKFLOW' contain implementation details that could be condensed. While informative, it's not front-loaded enough—the core purpose gets buried after bold headers.
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 complexity (3 parameters, no output schema, no annotations), the description provides substantial context about capabilities, metrics, categorization logic, and workflow integration. It explains what the tool returns and how to interpret results. However, it lacks explicit information about error handling, authentication requirements, or rate limits, which would be valuable for a database querying tool.
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?
The schema description coverage is 0%, so the description must compensate fully. It provides extensive context for the parameters: 'cluster_ids' is implied through references to 'selected clusters' and workflow steps; 'metric' is thoroughly explained with a dedicated 'AVAILABLE METRICS FOR SORTING' section listing all options and their meanings; 'limit_per_cluster' is addressed in 'QUERY LIMIT STRATEGY' with default behavior and user override capability. The description adds significant value beyond the bare schema.
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: 'extracts the actual SQL query text and performance metrics from selected clusters, enabling detailed pattern analysis and specific optimization recommendations.' It specifies the verb ('extracts'), resource ('SQL query text and performance metrics'), and scope ('from selected clusters'), and distinguishes it from sibling tools like sql_Analyze_Cluster_Stats by focusing on query-level details rather than cluster-level stats.
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: 'Start with clusters identified from sql_Analyze_Cluster_Stats' and 'Essential for moving from cluster-level analysis to actual query optimization.' It clearly positions this tool in a workflow with a specific sibling tool and explains its role in transitioning from high-level analysis to detailed optimization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly describes behavioral traits: it executes silently without showing tool calls, strips '/rag ' prefix, creates tables if missing, uses configurable embedding approaches, performs semantic search, and enforces strict answering rules (e.g., quoting directly, no external knowledge). This covers permissions, side effects, and output handling comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like WORKFLOW STEPS and TECHNICAL DETAILS, but it is overly verbose with repetitive instructions (e.g., multiple mentions of silent execution and direct quoting). Some sentences, such as 'Execute all RAG workflow steps silently without showing tool calls to users,' could be condensed without losing clarity, making it less front-loaded than ideal.
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?
Given the tool's complexity (multi-step RAG pipeline), no annotations, no output schema, and low schema coverage, the description is highly complete. It details workflow steps, configuration, technical implementations, answering rules, language restrictions, and behavioral requirements, providing all necessary context for an agent to invoke it correctly without external dependencies.
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 adds meaning for 'question' by explaining it's a user query with '/rag ' prefix stripping and context-based answering. For 'k', it mentions 'Default chunk retrieval count is configurable' and 'Returns the top-k matching chunks,' clarifying its role in retrieval. However, it doesn't specify default values or constraints for 'k' beyond configurable defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute complete RAG workflow to answer user questions based on document context.' It specifies the verb ('execute'), resource ('RAG workflow'), and distinguishes it from siblings by emphasizing it handles the entire pipeline in one step when queries are tagged with /rag, unlike other tools focused on database operations, SQL, or plotting.
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 explicitly states when to use this tool: 'when a user query is tagged with /rag.' It also provides clear exclusions: 'RAG mode only triggers with explicit /rag prefix - do not enter RAG mode implicitly,' and specifies no alternatives are needed as 'This is a complete end-to-end RAG workflow - no additional tools needed.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP MCP server](https://glama.ai/mcp/servers/blitzstermayank/MCP/badges/card.svg)](https://glama.ai/mcp/servers/blitzstermayank/MCP)

Score Badge

Copy to your README.md:

[![MCP MCP server](https://glama.ai/mcp/servers/blitzstermayank/MCP/badges/score.svg)](https://glama.ai/mcp/servers/blitzstermayank/MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blitzstermayank/MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server